A method for licensing, billing, and circulation supervision of data element transactions

Abstract

This invention discloses an authorization, billing, and circulation supervision method for data element transactions, applied to a data element trading platform. The method receives data product registration information submitted by a data provider, generates an authorization record based on the data user's data usage application, generates an authorization token based on the authorization record, and records the token's status. When a data user initiates a data access request, the access control module first reads the authorization token status table. If the token status is normal, it parses the authorization token to obtain the authorization record and compares the access subject, data product number, data product verification value, access fields, access time, request type, and number of accesses with the authorization record. After successful comparison, the access request is allowed, a usage record is generated, and the remaining number of calls is updated. Then, a billing record is generated based on the usage record and billing rules. A supervision record is generated based on the authorization record, usage record, and billing record, and written back to the authorization token status table.

Description

Technical Field

[0001] This invention belongs to the field of data element trading technology, and specifically relates to an authorization billing and circulation supervision method for data element trading. Background Technology

[0002] With the development of data element trading, data providers typically offer data interfaces, data queries, or data processing services to data demanders through trading platforms. Existing data element trading platforms can generally complete data product registration, contract management, fee settlement, and access log recording. However, in actual circulation, authorization, billing, and supervision are often handled separately, and there is a lack of continuous verification between data usage behavior and the scope of authorization.

[0003] Therefore, a Chinese patent (application number CN202110878288.2) discloses a data trading platform for protecting data privacy. This patented technology sets up user registration nodes, data registration nodes, storage nodes, data trading nodes, and data model nodes. This allows data requesters to complete a transaction at the data trading node and then, through authorization, have the data model node recover the data rows from the storage node and execute them in the data processing model. Simultaneously, the execution result is sent to the data requester, and the billing result is sent to the data trading node, thus achieving privacy protection and billing processing during the data trading process to a certain extent. However, this platform mainly focuses on data privacy protection, data storage and recovery, and model execution billing, making it difficult to promptly restrict subsequent access based on abnormal monitoring records. Therefore, those skilled in the art provide an authorization billing and circulation monitoring method for data element transactions to solve the problems mentioned in the background. Summary of the Invention

[0004] To address the aforementioned technical problems, this invention provides a method for authorization, billing, and circulation supervision of data element transactions. Specifically, the technical solution of this invention includes the following steps: Receive data product registration information submitted by data providers, generate data product numbers for data products, and record the data catalog, field range, data version, data level, interface address, and de-identification rules corresponding to the data product; The data product number, field range, data version, data level, and desensitization rule number are encoded in a preset order, and a data product verification value is generated based on the encoding results. The system receives data usage applications submitted by data users and generates authorization records based on the data user's identity, transaction contract information, authorization period, allowed access fields, allowed number of calls, allowed export types, billing rules, and regulatory rules. The authorization records correspond to the data product number and data product verification value. An authorization token is generated based on the authorization record, a correspondence is established between the authorization token and the authorization record, and the status of the authorization token is recorded in the authorization token status table; Receive a data access request initiated by a data demander, wherein the data access request carries the authorization token; The access control module reads the authorization token status table and rejects the data access request when the authorization token is in a suspended or abnormal state. When the authorization token is in a normal state, the access control module parses the authorization token to obtain the corresponding authorization record; The access subject, data product number, data product verification value, access fields, access time and request type in the data access request are compared with the authorization subject, data product number, data product verification value, authorization period, allowed access fields and allowed export types in the authorization record. The number of accesses is determined according to the request type of the data access request, and the number of accesses is compared with the remaining number of calls in the authorization record. When the comparison result meets the limiting conditions of the authorization record, the data access request is allowed, a usage record corresponding to the authorization record is generated, and the remaining call count in the authorization record is updated according to the number of accesses. A billing record is generated based on the billing rules in the usage record and the authorization record; A monitoring record is generated based on the authorization record, usage record, and billing record, and the authorization token status table is updated based on the monitoring record; When the comparison result does not meet the limiting conditions of the authorization record, the data access request is rejected, an abnormal supervision record is generated, and the abnormal status is recorded in the authorization token status table.

[0005] Preferably, the data product verification value is used to verify whether the data product corresponding to the data access request is consistent with the data product in the authorization record; when the field range, data version, data level or desensitization rule number of the data product changes, the data product verification value is regenerated, and the regenerated data product verification value is compared with the data product verification value in the original authorization record. When the two are inconsistent, the status of the original authorization token in the authorization token status table is recorded as paused.

[0006] Preferably, the authorization record includes at least the authorization record number, data product number, data product verification value, authorization subject, authorization period, allowed access fields, allowed number of calls, remaining number of calls, allowed export type, billing rule number, and regulatory rule number.

[0007] Preferably, the data access request is a data interface call request, a data query request, a data processing task request, or a result export request; when the data access request is a single access request, the number of accesses in this instance is one; when the data access request is a batch access request, the number of accesses in this instance is the number of data accesses included in the batch access request.

[0008] Preferably, the usage record includes at least the usage record number, authorization record number, data product number, data product verification value, access subject, access time, access fields, number of accesses, amount of returned data, de-identification rule number, and access result status.

[0009] Preferably, when generating a billing record, the billing quantity is determined based on the number of accesses, access fields, returned data volume, data level, and access result status in the usage record, and the billing item, billing quantity, unit price, fee amount, and settlement status are generated according to the billing rules in the authorization record; wherein, the access result status is used to determine whether the corresponding data access request is included in the billing quantity.

[0010] Preferably, the regulatory record includes at least a regulatory record number, an authorization record number, a usage record number, a billing record number, a data product number, a data product verification value, an authorization status, an access status, a settlement status, an anomaly type, and a recording time. The regulatory record does not save the original data content corresponding to the data access request.

[0011] Preferably, when a data access request exceeds the authorization period, exceeds the remaining number of calls, accesses an unauthorized field, requests to export an unauthorized result, or the access subject is inconsistent with the authorization subject, the access control module restricts the corresponding authorization token; the restriction processing includes suspending the authorization token, disabling the result export permission, blocking the unauthorized field, or suspending the specified interface call.

[0012] The present invention has the following beneficial effects: This invention generates a data product verification value for each data product and compares this value with authorization records, authorization tokens, and data access requests. This allows the system to determine whether the actually accessed data product matches the authorization record, preventing the reuse of the original authorization even after changes in data product version, field range, or de-identification rules. By setting up an authorization token status table, the access control module reads the authorization token status before each data access and performs authorization condition comparison only when the status is normal. This enables timely rejection of access requests in suspended or abnormal states, improving the real-time performance of access control.

[0013] This invention also verifies the number of accesses based on the remaining call count in the authorization record, and generates a usage record and deducts the remaining call count after the access is approved, enabling continuous recording and constraint of data usage. Billing records are generated directly from usage records and billing rules, reducing the workload of manually counting call volume and verifying costs; monitoring records are generated jointly from authorization records, usage records, and billing records, and are written back to the authorization token status table, allowing monitoring results to restrict subsequent access. Attached Figure Description

[0014] Other features, objects, and advantages of the present invention will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings: Figure 1 This is a flowchart of the method of the present invention. Detailed Implementation

[0015] The present invention will be further described below with reference to embodiments. It should be understood that the following embodiments are used to illustrate the specific implementation process of the present invention and are not intended to limit the scope of protection of the present invention. Conventional adjustments made by those skilled in the art to the order of some steps, field names, table names, or module names without departing from the concept of the present invention should all fall within the scope of protection of the present invention.

[0016] like Figure 1 As shown, this invention provides an authorization, billing, and circulation supervision method for data element transactions, applied to a data element trading platform. This data element trading platform may include a data product registration module, an authorization management module, an access control module, a usage record module, a billing module, a supervision module, and a database. The database may contain a data product table, an authorization record table, an authorization token status table, a usage record table, a billing record table, and a supervision record table. The data product registration module receives data product registration information submitted by data providers; the authorization management module generates authorization records and authorization tokens; the access control module reads the authorization token status and compares authorization conditions before data access; the usage record module records the data access process; the billing module generates billing records based on usage records; and the supervision module generates supervision records based on authorization records, usage records, and billing records, and updates the authorization token status table. Example 1

[0017] This embodiment illustrates the process of normal registration, authorized access, billing, and supervision of data products. Data providers submit data product registration information through a data element trading platform. This registration information includes a data catalog, field ranges, data version, data level, interface address, and anonymization rules. For example, a data product registered by a data provider might be a business operation status data product. The data catalog for this product would be a business operation data catalog, with field ranges including company name, industry type, business status, registration time, and region code. The data version would be V1, the data level would be level two, the interface address would be the data access interface assigned by the platform, and the anonymization rules would involve partially hiding the company's identification information.

[0018] After receiving the above information, the data product registration module generates a data product number for the data product and saves the data product number, data directory, field range, data version, data level, interface address, and anonymization rules to the data product table. Then, the data product registration module encodes the data product number, field range, data version, data level, and anonymization rule number in a preset order and generates a data product verification value based on the encoding result. Specifically, the field ranges can be first organized according to field name order, then the data product number, the organized field ranges, data version, data level, and anonymization rule number can be concatenated to form an encoded string, and then a data product verification value can be generated based on this encoded string. This data product verification value is used to subsequently determine whether the data product corresponding to the data access request is consistent with the data product in the authorization record.

[0019] When a data user needs to use a data product, they submit a data usage application to the data element trading platform. The application includes the data user's identity, the data product number to be used, the usage period, the fields to be accessed, the expected number of calls, the type of result exported, and a description of the purpose. The authorization management module generates an authorization record based on the data user's identity, transaction contract information, authorization period, allowed access fields, allowed number of calls, allowed export types, billing rules, and regulatory rules. This authorization record includes at least the authorization record number, data product number, data product verification value, authorizing entity, authorization period, allowed access fields, allowed number of calls, remaining number of calls, allowed export types, billing rule number, and regulatory rule number.

[0020] In this embodiment, the authorized fields in the authorization record are company name, industry type, and business status. The allowed number of calls is 1000, with an initial remaining call count of 1000. The allowed export type is statistical results, but detailed data export is not allowed. The authorization management module generates an authorization token based on this authorization record and establishes a correspondence between the authorization token and the authorization record. Simultaneously, it records the status of the authorization token as normal in the authorization token status table.

[0021] When a data requester initiates a data access request, it includes an authorization token. Upon receiving the request, the access control module first reads the authorization token status table. If the authorization token is in a normal state, the access control module parses the token to obtain the corresponding authorization record. Subsequently, the access control module compares the access subject, data product number, data product verification value, access fields, access time, and request type from the data access request with the authorization subject, data product number, data product verification value, authorization period, allowed access fields, and allowed export types from the authorization record.

[0022] The data product verification value can be carried in the data access request, or it can be retrieved from the data product table by the access control module based on the data product number in the data access request and added to the comparison. Therefore, even if the data requester only submits the data product number in the data access request, the access control module can still obtain the corresponding data product verification value from the data product table stored on the platform and compare it with the data product verification value in the authorization record.

[0023] When this data access request is a single data interface call request, the access control module determines that this access count is one and compares it with the remaining call count in the authorization record. If the access subject is the same as the authorization subject, the data product number and the data product verification value are the same, the accessed field is a permitted access field, the access time is within the authorization period, the request type conforms to the permitted export type, and the number of this access does not exceed the remaining call count, then the access control module allows the data access request.

[0024] After a data access request is granted, the usage record module generates a usage record corresponding to the authorization record. The usage record includes at least the usage record number, authorization record number, data product number, data product verification value, access subject, access time, access fields, number of accesses, amount of returned data, de-identification rule number, and access result status. Simultaneously, the authorization management module updates the remaining call count in the authorization record according to the number of accesses. For example, if the number of accesses is one, the remaining call count will be updated from 1000 to 999.

[0025] The billing module reads the usage record and generates a billing record based on the billing rules in the usage and authorization records. The billing rules can be based on the number of accesses or on a combination of access fields, returned data volume, and data level to determine the cost. In this embodiment, the billing module determines the billing quantity based on the number of accesses, access fields, returned data volume, data level, and access result status, and generates the billing item, billing quantity, unit price, cost amount, and settlement status. If the access result status is successful, the access is included in the billing quantity; if the access result status is data service execution failure, it is not included in the billing quantity; if the access result status is partially successful, the billing quantity is based on the amount of successfully returned data.

[0026] The monitoring module generates monitoring records based on authorization records, usage records, and billing records. A monitoring record includes at least the monitoring record number, authorization record number, usage record number, billing record number, data product number, data product verification value, authorization status, access status, settlement status, anomaly type, and recording time. The monitoring record does not save the original data content corresponding to this data access request; it only saves the number, status, and anomaly information used for traceability.

[0027] The monitoring module updates the authorization token status table based on monitoring records. When no exception type is recorded in the monitoring record, the monitoring module keeps the status in the authorization token status table as normal and records the most recent monitoring record number. When an exception type is recorded in the monitoring record, the monitoring module updates the authorization token status to an exception status, a suspended status, or a restricted status based on the exception type. Therefore, the authorization token status table is not only used to record the current status of the authorization token, but also to determine the status before subsequent data access requests enter the platform.

[0028] Through the above process, the data element trading platform can complete authorization verification before data access, generate usage records after access is approved, and generate billing and regulatory records based on the usage records, so that authorization, billing and supervision form a continuous processing relationship. Example 2

[0029] This embodiment illustrates the process of suspending the original authorization token after changes to the data product.

[0030] After a data product has been authorized, the data provider may update it. For example, the data provider may update the version of the enterprise operation status data product from V1 to V2, add new fields to the existing field range, or adjust the existing de-identification rules to new ones. In this case, the data product registration module will detect the changes in the field range, data version, data level, or de-identification rule number.

[0031] The data product registration module re-encodes the updated data product number, field range, data version, data level, and de-identification rule number according to a preset order, and generates a new data product verification value based on the new encoding results. The platform then compares the regenerated data product verification value with the data product verification value in the original authorization record.

[0032] If the regenerated data product verification value matches the data product verification value in the original authorization record, the access control module can continue to perform verification according to the original authorization record. If the regenerated data product verification value does not match the data product verification value in the original authorization record, it indicates that the scope, version, level, or de-identification rules of the data product corresponding to the original authorization record have changed. Continuing to use the original authorization token may cause the data requester to access data content not covered by the original authorization record. Therefore, the authorization management module records the status of the original authorization token in the authorization token status table as suspended.

[0033] When a data requester continues to initiate a data access request with the original authorization token, the access control module first reads the authorization token status table. Since the authorization token has been recorded as suspended, the access control module directly rejects the data access request and generates an exception monitoring record. This exception monitoring record can record the authorization record number, data product number, original data product verification value, new data product verification value, exception type, and recording time. The exception type can be recorded as inconsistent data product verification values.

[0034] Through the above process, the present invention can promptly suspend the original authorization token after changes in the content of data products or desensitization rules, preventing data users from continuing to access data products that have changed based on the old authorization, thereby improving the consistency and controllability of authorized objects in the data element transaction process. Example 3

[0035] This embodiment illustrates the implementation process of batch access requests and remaining call count verification.

[0036] Within the authorized period, data requesters can initiate batch data query requests to the data element trading platform. These requests carry an authorization token and include multiple query conditions or multiple data access objects. Upon receiving the batch data query request, the access control module first reads the authorization token status table to confirm that the authorization token is in a normal state, then parses the authorization token to obtain the corresponding authorization record.

[0037] The access control module determines the number of accesses based on the request type of the data access request. When the data access request is a single access request, the number of accesses is one; when the data access request is a batch access request, the number of accesses is the number of data accesses contained in the batch access request. For example, if a batch query request contains 20 query tasks, the number of accesses is determined to be 20.

[0038] The access control module reads the remaining call count from the authorization record and compares the current access count with the remaining call count. If the remaining call count in the authorization record is 50 and the current access count is 20, then the current access count does not exceed the remaining call count. The access control module continues to compare the access subject, data product number, data product verification value, access fields, access time, and request type. After the comparison is successful, the access control module allows the batch access request, uses the recording module to generate one or more usage records, and updates the remaining call count in the authorization record from 50 to 30.

[0039] If the remaining number of calls in the authorization record is 10, and the number of accesses corresponding to this batch access request is 20, the access control module determines that the number of accesses exceeds the remaining number of calls and rejects the batch access request. The monitoring module generates an abnormal monitoring record based on the rejection result and records the abnormal status in the authorization token status table. The abnormal monitoring record may include the authorization record number, authorization token, remaining number of calls, number of accesses in this instance, abnormal type, and recording time. The abnormal type can be recorded as "exceeding the remaining number of calls." For cases where the remaining number of calls is exceeded, the platform can record the corresponding authorization token as suspended, or suspend the authorization token from initiating further data access requests.

[0040] Through the above process, the present invention can not only handle single access requests, but also batch access requests, and can control the number of calls before data access, thereby preventing data demanders from bypassing the call limit through batch requests. Example 4

[0041] This example illustrates the implementation process of abnormal access and token restrictions.

[0042] Data users may encounter various abnormal access scenarios during data access. For example, a data user may continue to access data products after the authorization period has expired; or access fields that are not allowed in the authorization record; or request to export detailed results that are not allowed; or the actual accessing entity may be inconsistent with the authorizing entity in the authorization record.

[0043] Taking accessing prohibited fields as an example, the authorized record allows access to fields such as company name, industry type, and business status. However, the data access request includes contact information and tax classification. After parsing the authorization token, the access control module compares the access fields in the data access request with the allowed access fields in the authorized record. It finds that contact information and tax classification are not allowed access fields, and therefore determines that the data access request does not meet the restrictions of the authorized record.

[0044] The access control module rejects the data access request, and the monitoring module generates an abnormal monitoring record. The abnormal monitoring record includes the authorization record number, data product number, data product verification value, access subject, access time, requested access fields, allowed access fields, abnormal type, and recording time. The abnormal type can be recorded as "access not allowed fields." Subsequently, the monitoring module updates the authorization token status table based on the abnormal monitoring record and restricts the authorization token accordingly.

[0045] Restriction handling can be determined based on the type of exception. For access requests exceeding the authorization period, the authorization token can be suspended; for access requests accessing prohibited fields, the prohibited fields can be blocked; for access requests requesting the export of prohibited results, the result export permission can be disabled; for access requests where a specified interface call occurs abnormally, the specified interface call can be suspended. When the access control module subsequently receives a data access request carrying the same authorization token, it first reads the authorization token status table and processes it according to the restrictions recorded in the status table.

[0046] For example, when the authorization token status table records that the permission to export results is closed, the data demander can still perform data queries within the authorized scope, but cannot initiate a request to export results; when the authorization token status table records that a specified interface call is suspended, the data demander cannot continue to call the interface, but it does not affect its access to other data services that are still within the authorized scope; when the authorization token status table records a suspended status, the access control module directly rejects all data access requests carrying the authorization token.

[0047] Through the above process, the present invention can generate a monitoring record in a timely manner after abnormal access is detected, and the monitoring result can be used in reverse to control subsequent access. It can not only record abnormalities, but also restrict abnormal access from continuing to occur. Example 5

[0048] This example illustrates the process of generating billing and regulatory records.

[0049] After the data requester completes one or more authorized data accesses that pass verification, the usage record module generates the corresponding usage record. The billing module reads the usage records under the same authorization record and determines the billing amount based on the number of accesses, access fields, returned data volume, data level, and access result status in the usage record.

[0050] For example, a usage record might show that the accessed fields were company name, industry type, and business status, the access frequency was one, the returned data volume was 500 records, and the access result status was successful. The billing module, based on the billing rules in the authorization record, determines the amount of data to be billed for this access and generates a billing record according to the billing price for ordinary fields and the returned data volume. If another usage record shows the access result status as data service execution failure, the billing module can record this access as a non-billing item; if the access result status is partially successful, the billing quantity is determined based on the successfully returned data volume.

[0051] For data access requests that fail authorization verification and are rejected by the access control module, no billing record can be generated; only an abnormal monitoring record. This avoids incurring charges for unauthorized access requests while still retaining evidence for monitoring abnormal access.

[0052] Billing records can include billing record number, authorization record number, usage record number, billing item, billing quantity, unit price, fee amount, and settlement status. Settlement status can include unsettled, in settlement, and settled. After generating billing records, the billing module saves them to the billing record table.

[0053] The monitoring module reads authorization records, usage records, and billing records, and generates a monitoring record. The monitoring record may include a monitoring record number, authorization record number, usage record number, billing record number, data product number, data product verification value, authorization status, access status, settlement status, exception type, and recording time. For normal access, the exception type can be empty or recorded as "no exception"; for abnormal access, the exception type can be recorded as exceeding the authorization period, exceeding the remaining call count, accessing a disallowed field, requesting to export a disallowed result, or the access subject not matching the authorization subject.

[0054] The regulatory records do not store the original data content corresponding to the data access request, nor do they store the original data results returned. The regulatory records achieve traceability through authorization record number, usage record number, billing record number, data product number, and data product verification value. This satisfies the regulatory needs of data element transactions while avoiding the duplication of original data content in the regulatory records.

[0055] Through the above process, the present invention enables billing records to correspond with actual usage records, and enables regulatory records to be associated with authorization, usage and billing status simultaneously, reducing the workload of manually verifying call volume, fees and abnormal access behavior, and improving the traceability of the data flow process. Example 6

[0056] This embodiment illustrates the applicability of the present invention in data interface calls, data queries, data processing tasks, and result export requests.

[0057] When a data access request is a data interface call request, the access control module mainly compares the access subject, data product number, data product verification value, access fields, access time, and remaining call count. After the comparison is successful, the platform calls the corresponding interface and returns the data result processed according to the anonymization rules, while generating a usage record.

[0058] When the data access request is a data query request, in addition to the above comparison, the access control module can also determine the number of accesses based on the query conditions. If the query request is a single query, the number of accesses is one; if the query request is a batch query, the number of accesses is determined based on the number of query objects included in the batch query.

[0059] When a data access request is for a data processing task, the access control module compares the processing task with the authorized data usage scope recorded in the authorization log. After the processing task is completed, the usage log can record the accessed fields, number of accesses, amount of returned data, anonymization rule number, and access result status. The billing module can generate billing records based on the number of accesses, accessed fields, amount of returned data, data level, and access result status.

[0060] When a data access request is a result export request, the access control module focuses on comparing whether the request export type belongs to the allowed export types in the authorization record. If the authorization record only allows exporting statistical results, but the data access request requests to export detailed data, the access control module rejects the request, the monitoring module generates an abnormal monitoring record, and can revoke the result export permission of the authorization token. If the request export type matches the authorization record, the access control module allows the request and generates the corresponding usage record and billing record.

[0061] Through the above methods, the present invention can be applied to common data interface calls, data queries, data processing tasks and result export scenarios in data element trading platforms, and can maintain a unified authorization verification, usage record, billing record and regulatory record generation process in different types of data access requests.

[0062] In summary, this invention, through the coordination of data product verification values, authorization records, authorization tokens, authorization token status tables, usage records, billing records, and regulatory records, ensures that data access requests are constrained by authorization conditions and token status before entering the data service; after successful access, usage and billing records are generated; and in the event of anomalies, an anomaly regulatory record is generated, restricting subsequent access. Therefore, this invention solves the problems in existing data element trading platforms, such as the difficulty in continuously verifying the scope of authorization, accurately billing usage behavior, and promptly restricting abnormal circulation behavior.

Claims

1. A method for authorization, billing, and circulation supervision of data element transactions, characterized in that, Applied to a data element trading platform, the method includes the following steps: Receive data product registration information submitted by data providers, generate data product numbers for data products, and record the data catalog, field range, data version, data level, interface address, and de-identification rules corresponding to the data product; The data product number, field range, data version, data level, and desensitization rule number are encoded in a preset order, and a data product verification value is generated based on the encoding results. The system receives data usage applications submitted by data users and generates authorization records based on the data user's identity, transaction contract information, authorization period, allowed access fields, allowed number of calls, allowed export types, billing rules, and regulatory rules. The authorization records correspond to the data product number and data product verification value. An authorization token is generated based on the authorization record, a correspondence is established between the authorization token and the authorization record, and the status of the authorization token is recorded in the authorization token status table; Receive a data access request initiated by a data demander, wherein the data access request carries the authorization token; The access control module reads the authorization token status table and rejects the data access request when the authorization token is in a suspended or abnormal state. When the authorization token is in a normal state, the access control module parses the authorization token to obtain the corresponding authorization record; The access subject, data product number, data product verification value, access fields, access time and request type in the data access request are compared with the authorization subject, data product number, data product verification value, authorization period, allowed access fields and allowed export types in the authorization record. The number of accesses is determined according to the request type of the data access request, and the number of accesses is compared with the remaining number of calls in the authorization record. When the comparison result meets the limiting conditions of the authorization record, the data access request is allowed, a usage record corresponding to the authorization record is generated, and the remaining call count in the authorization record is updated according to the number of accesses. A billing record is generated based on the billing rules in the usage record and the authorization record; A monitoring record is generated based on the authorization record, usage record, and billing record, and the authorization token status table is updated based on the monitoring record; When the comparison result does not meet the limiting conditions of the authorization record, the data access request is rejected, an abnormal supervision record is generated, and the abnormal status is recorded in the authorization token status table.

2. The authorization, billing, and circulation supervision method for data element transactions according to claim 1, characterized in that, The data product verification value is used to verify whether the data product corresponding to the data access request is consistent with the data product in the authorization record. When the field range, data version, data level, or desensitization rule number of the data product changes, the data product verification value is regenerated, and the regenerated data product verification value is compared with the data product verification value in the original authorization record. When the two are inconsistent, the status of the original authorization token in the authorization token status table is recorded as paused.

3. The authorization, billing, and circulation supervision method for data element transactions according to claim 1, characterized in that, The authorization record includes at least the authorization record number, data product number, data product verification value, authorization subject, authorization period, allowed access fields, allowed number of calls, remaining number of calls, allowed export type, billing rule number, and regulatory rule number.

4. The authorization, billing, and circulation supervision method for data element transactions according to claim 1, characterized in that, The data access request can be a data interface call request, a data query request, a data processing task request, or a result export request. When the data access request is a single access request, the number of accesses in this instance is one. When the data access request is a batch access request, the number of accesses in this instance is the number of data accesses included in the batch access request.

5. The authorization, billing, and circulation supervision method for data element transactions according to claim 1, characterized in that, The usage record includes at least the usage record number, authorization record number, data product number, data product verification value, access subject, access time, access fields, number of accesses, amount of returned data, de-identification rule number, and access result status.

6. The authorization, billing, and circulation supervision method for data element transactions according to claim 1, characterized in that, When generating a billing record, the billing quantity is determined based on the number of accesses, access fields, returned data volume, data level, and access result status in the usage record, and the billing item, billing quantity, unit price, fee amount, and settlement status are generated according to the billing rules in the authorization record; wherein, the access result status is used to determine whether the corresponding data access request is included in the billing quantity.

7. The authorization, billing, and circulation supervision method for data element transactions according to claim 1, characterized in that, The regulatory record includes at least the regulatory record number, authorization record number, usage record number, billing record number, data product number, data product verification value, authorization status, access status, settlement status, anomaly type, and recording time. The regulatory record does not save the original data content corresponding to the data access request.

8. The authorization, billing, and circulation supervision method for data element transactions according to claim 1, characterized in that, When a data access request exceeds the authorization period, exceeds the remaining number of calls, accesses an unauthorized field, requests to export an unauthorized result, or the access subject is inconsistent with the authorized subject, the access control module restricts the corresponding authorization token. The restriction processing includes suspending the authorization token, disabling the result export permission, blocking the unauthorized field, or suspending the specified interface call.

Images