System and method for encoding, pricing and trading of data assets
Patent Information
- Application Number
- CN202610783821.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2026-06-02
- Publication Date
- 2026-09-11
Smart Images
Figure CN122736704A_ABST
Abstract
Description
Technical Field This invention relates to the fields of big data asset management, standardized trading of data elements, and quantification of data asset value. Specifically, it relates to a data asset coding system and method suitable for automated pricing and simplified trading processes. It can be applied to various data exchanges, enterprise data asset management platforms, and third-party data service providers to achieve standardized identification, intelligent pricing, automated trading, and cross-platform circulation of data assets. Background Technology With the continued advancement of the marketization of data elements in China, data assets have been formally included in the market-traded commodity category, and the scale of data trading in various vertical industries is gradually expanding. Currently, the industry lacks a unified and universal standardized coding system for data assets, and existing data asset management and trading models have several technical shortcomings, hindering the large-scale circulation and commercialization of data assets. Specific technical deficiencies are as follows: First, there is a lack of standardization. Most existing data assets are distinguished by custom text names, manual tags, and document notes. The lack of uniformity in standards leads to low efficiency in matching data assets and some errors in the matching results.
[0001] Second, there is a lack of refined quantification capabilities for data asset value, leading to discrepancies between pricing results and the actual value of the assets. Traditional data asset pricing methods, such as fixed and uniform pricing or manual experience-based pricing, fail to differentiate core dimensions affecting asset value, including data modality type, data scarcity, privacy and security protection level, computing resource consumption, business processing difficulty, and the precision of manual annotation. The same set of raw data assets can have significantly different values in different use cases, such as scientific research trials, commercial applications, and model simulations. Traditional pricing models cannot distinguish between these differences in value across scenarios, easily resulting in value mismatches where high-value data is priced too low and low-value data is priced too high.
[0002] Third, the transaction process involves a significant amount of manual intervention, resulting in a relatively long overall cycle. Current data asset transactions require staff to complete operations such as qualification verification, parameter checking, price calculation, offline contract signing, permission activation, and data delivery. A single complete transaction typically takes 1 to 3 days. The manual operation process is cumbersome, has high labor costs, and is prone to data entry and verification errors, making it difficult to achieve standardized and rapid transactions.
[0003] Fourth, cross-platform circulation faces technical barriers, and the phenomenon of data silos within the industry is prominent. Different data trading platforms, enterprise data middleware, and third-party data service providers have built their own labeling systems and pricing rules, making it impossible to achieve simultaneous circulation and pricing across multiple platforms with a single registration.
[0004] Fifth, the existing data identifiers have fixed field structures, which cannot adapt to newly added data modalities, new business application scenarios, and new pricing and accounting dimensions. New types of data assets are difficult to quickly integrate into the existing transaction system, and the overall architecture has limitations in compatibility and long-term iteration capabilities.
[0005] In summary, the existing technology lacks a data asset coding system that takes into account multi-dimensional information, standardization, support for value accounting, traceability, and iterativeness. This problem is the main technical obstacle restricting the current data element market's data asset retrieval, pricing, trading, and cross-platform circulation. Therefore, it is necessary to design a brand-new automated coding, pricing, and trading technology solution.
[0006] The purpose of this invention is to address the problems of inconsistent data asset identification standards, high manual costs in transaction processes, and barriers to cross-platform circulation in existing technologies. It provides a data asset coding, pricing, and trading system and method, achieving the following technical effects: 1. Improved data retrieval efficiency: Relying on unified coding, purchasers can quickly locate target data assets, and asset providers can standardize the listing and display of their own data assets; 2. Optimized pricing accuracy: By differentiating data asset attributes through multi-dimensional coding, computers can automatically calculate based on coding parameters, improving the matching degree between pricing results and the actual value of the asset; 3. Simplified transaction operations. Process: 1. Uses codes as transaction identifiers for data assets. Purchasers can initiate transactions simply by entering the code, reducing manual steps. 2. Supports cross-platform asset circulation: Unified coding rules can be adapted to multiple trading platforms, enabling cross-platform identification and circulation of data assets. 3. Retains full-process asset records: Records coding information through version numbers, timestamps, and encrypted verification codes, allowing for traceability of code and corresponding asset modifications and transaction activities, reducing the risk of tampering. 4. Supports long-term iteration of the coding system: Codes reserve extended fields, combined with version differentiation rules, allowing for direct expansion when adding new business dimensions without reconstructing the overall coding architecture.
[0007] The core design concept of this invention is as follows: It relies on standardized coding to carry the multi-dimensional attributes of data assets, achieving automated pricing based on the coded information, and simplifying online transaction processes by using the code as a unique asset identifier. The code records the detailed attributes of the data asset, mapping the coded field information to internal coefficients in the pricing formula. The computer automatically calculates the asset price according to the formula. As a unique identifier for the data asset, the code directly serves as the basis for online transaction retrieval and order placement, achieving a standardized transaction identification logic similar to securities codes. Standardized coding is the foundation for automatic machine retrieval, automatic pricing, and rapid online trading; without unified coding, it is difficult to achieve the aforementioned automated business functions.
[0008] This invention employs a dual-layer coding architecture, consisting of a 12-bit unseparated pure numeric multi-dimensional category code and a 32-bit DAC (Data Access Code) complete data asset code. The 12-bit category code, with a character length of 12 bits, is used for online transaction identification. Its advantages include concise characters for easy input and compatibility with rapid database retrieval and online order placement. The 32-bit DAC code, with a character length of 32 bits, is used for asset lifecycle information verification and traceability, internally integrating version number, timestamp, and encrypted verification characters.
[0009] The 12-bit pure numeric encoding structure uses 12 consecutive pure numbers without separators, adapting to database prefix indexes and sharded database storage logic. Bits 1-3: Data modality category, occupying 3 digits; Bit 4: Data scarcity, occupying 1 digit; Bit 5: Security protection level, occupying 1 digit; Bits 6-7: Computing resource level, occupying 2 digits; Bits 8-9: Business function category, occupying 2 digits; Bits 10-11: Subdivided business tasks, occupying 2 digits; Bit 12: Extended reserved field, occupying 1 digit. The theoretical total number of combinations of this 12-bit encoding is approximately 97 billion, covering most existing data asset types and possessing good scalability.
[0010] Encoding Rules for Each Field (Example): The first 3 fields represent the data modality category. Encoding range 001-020 represents text data, measured in rows; encoding range 021-040 represents tabular / structured data, measured in rows; encoding range 041-070 represents image data, measured in images; encoding range 071-090 represents video data, measured in seconds / frames; encoding range 091-110 represents audio data, measured in hours / seconds; encoding range 111-130 represents 3D point cloud data, measured in frames; encoding range 171-200 represents medical imaging data, measured in images / cases; encoding range 201-220 represents financial statistics data, measured in rows; encoding range 221-240 represents legal text data, measured in copies; encoding range 301-999 is a reserved extended range, currently without a fixed unit of measurement.
[0011] The fourth digit represents the scarcity of data: Code 0 corresponds to regular stock data with a base price coefficient of 1.0; Code 1 corresponds to data with a relatively small market supply with a base price coefficient of 1.5; Code 2 corresponds to rare market data with a base price coefficient of 2.5; Code 3 corresponds to data with an extremely small market supply with a base price coefficient of 4.0; and Code 4 corresponds to unique, custom-made data with a base price coefficient of 6.0.
[0012] The 5th digit represents the privacy / data security protection level: Code 0 represents publicly available unprotected data, with a base price coefficient of 1.0; Code 1 represents anonymized data, with a base price coefficient of 1.2; Code 2 represents encrypted data storage, with a base price coefficient of 1.5; Code 3 represents highly secure managed data, with a base price coefficient of 2.0; Code 4 represents the highest level of confidential data, with a base price coefficient of 3.0.
[0013] The 6th and 7th digits represent the computing power consumption level: Code 01 corresponds to CPU computing scenarios with a computing power coefficient of 1.0; Code 02 corresponds to low-end GPU computing scenarios with a computing power coefficient of 1.2; Code 03 corresponds to mid-range GPU computing scenarios with a computing power coefficient of 1.5; Code 04 corresponds to high-end GPU computing scenarios with a computing power coefficient of 2.0; and Code 05 corresponds to ultra-high-end GPU computing scenarios with a computing power coefficient of 3.0.
[0014] The 8th and 9th digits represent the major business function categories: Code 01 is data annotation / classification; Code 02 is object detection / location; Code 03 is image segmentation / contour delineation; Code 04 is information extraction / entity recognition; Code 05 is content generation / text rewriting; Code 06 is speech transcription / text transcription; Code 07 is model performance evaluation / data validation.
[0015] The 10th and 11th digits represent the subdivided business tasks: Code 01 is a binary classification task, compatible with the 01 annotation / classification category; Code 02 is a multi-class classification task with 3 to 10 classes, compatible with the 01 category; Code 03 is a multi-class classification task with 10 to 50 classes, compatible with the 01 category; Code 04 is a multi-class classification task with more than 50 classes, compatible with the 01 category; Code 11 is a rectangular bounding box object detection task, compatible with the 02 detection / localization category; Code 12 is a rotated bounding box object detection task, compatible with the 02 category; Code 13 is an anomaly detection task, compatible with the 02 category; Code 14 is an image edge detection task, compatible with the 02 category; Code 21 is a semantic segmentation task, compatible with the 03 segmentation / delineation category; Code 22 is an instance segmentation task, compatible with the 03 category; Code 23 is a panoramic segmentation task, compatible with the 03 category; Code 24... The tasks are as follows: Task 31 is Keypoint Detection, which fits Category 03; Task 32 is Named Entity Recognition (NER), which fits Category 04 Extraction / Recognition; Task 33 is Text Relation Extraction, which fits Category 04; Task 34 is Event Information Extraction, which fits Category 04; Task 45 is Attribute Information Extraction, which fits Category 04; Task 46 is Automatic Text Summarization, which fits Category 05 Generation / Rewriting; Task 47 is Machine Text Translation, which fits Category 05; Task 48 is AI Image Generation, which fits Category 05; Task 49 is Text Style Rewriting, which fits Category 05; Task 50 is Standard Speech-to-Text, which fits Category 06 Transcription / Translation; and Task 51 is Dialect Speech-to-Text, which fits Category 06.
[0016] The 12th bit is a reserved extension bit: Code 0 is the default normal mode, with no additional extension functions enabled, and is used by default by the system; Code 1 is the version identifier mode, marking the current encoding rule version, and is enabled when the encoding rule is updated; Code 2 is the high-precision accounting mode, enabling refined pricing coefficients, and is enabled when processing sub-pixel images and ultra-high precision labeled data; Code 3 is the data encryption extension mode, with an additional data encryption process, and is enabled in high-security business scenarios; Code 4 is the expedited processing mode, with an expedited premium added during accounting, and is enabled when there are urgent delivery needs; Code 5 is the bulk purchase mode, with tiered discount pricing rules enabled, and is enabled when purchasing data assets in large quantities; Code 6 is the test-dedicated mode, with pricing accounting not charged, and is only used for platform function testing; Code 7 is the pilot discount mode, with a discount coefficient used during accounting, and is enabled when promoting to new users and new data categories; Code 8 is the customized coefficient mode, supporting user-defined accounting coefficients, and is enabled when signing special cooperation agreements; Code 9 is a reserved undefined mode, with functions to be added in subsequent business expansions, and there are currently no conditions for its activation.
[0017] Taking the commercial diagnostic scenario of medical imaging as an example, the 12th digit is 0, which is the default mode. The segmented numbers and their corresponding meanings are as follows: the 1st to 3rd digits are 171, representing medical imaging data; the 4th digit is 2, representing rare data in the market; the 5th digit is 1, representing data that has been anonymized; the 6th to 7th digits are 04, representing the computing power consumption of high-end A100 GPU; the 8th to 9th digits are 03, representing the major category of image segmentation business; the 10th to 11th digits are 21, representing the semantic segmentation sub-task; the 12th digit is 0, representing the default normal mode; combined, we get the complete 12-digit transaction code: 171210403210.
[0018] The 32-bit DAC (Data Asset Code) consists of four segments: a 2-digit version number, an 8-digit timestamp, a 12-digit category transaction code, and a 10-digit encrypted checksum. The first two digits are the encoding rule version number, used to distinguish different iterations and ensure compatibility between old and new codes. The third to tenth digits are an 8-digit timestamp in YYYYMMDD format, recording the time of data asset listing, transaction, and modification, supporting traceability throughout the asset's lifecycle. The eleventh to twentieth digits are the 12-digit category transaction code mentioned earlier, serving as the core identification character for the entire DAC code. The twentieth to thirtieth digits are a 10-digit checksum generated using the SHA-256 hash algorithm, used to verify whether the code has been manually modified, reducing the risk of code tampering.
[0019] The mapping from coding to pricing formula involves each segment of the coding corresponding to a calculation coefficient within the pricing formula, with the following correspondence: Coding bits 1-3 (data modality) correspond to coefficient C (basic data classification coefficient), used to calculate the basic cost of data assets; Coding bit 4 (scarcity) corresponds to the scarcity fine-tuning coefficient, used to calculate the value premium of rare data; Coding bit 5 (security level) corresponds to the security protection fine-tuning coefficient, used to calculate the processing costs incurred by data desensitization and encryption; Coding bits 6-7 (computing power level) correspond to coefficient S (computing power consumption coefficient), used to calculate the hardware resource costs corresponding to data computation; Coding bits 8-9 (business function) correspond to coefficient K (business difficulty coefficient), used to calculate the human and technical costs corresponding to professional business processing; Coding bits 10-11 (subdivided tasks) correspond to H (human time consumption coefficient) and F (fineness coefficient), respectively, used to calculate the human costs incurred by manual annotation and fine-tuning.
[0020] Pricing Calculation Formula: This invention uses the following formula to calculate the basic unit price of data assets: P_base = T × (C + S + K + H) × F × α × β × V in: P_base is the base unit price, in yuan / unit; T represents the total number of tokens for the data asset, expressed in units of tokens. C is the data classification coefficient, which is dimensionless and is obtained by mapping the first three bits of the 12-bit code. S is the computing power coefficient, which is dimensionless and is obtained by mapping the 6th and 7th bits of the 12-bit code. K is the knowledge difficulty coefficient, which is dimensionless and is obtained by mapping the 8th and 9th bits of the 12-bit code. H is the manual labor time coefficient, which is dimensionless and is obtained by mapping the 10th and 11th bits of the 12-bit code. F is the fineness coefficient, which is dimensionless and is obtained by mapping the 10th and 11th bits of the 12-bit code. α is a scarcity fine-tuning factor, which is dimensionless and is obtained by mapping the 4th bit of the 12-bit code; β is a privacy-preservation fine-tuning factor, which is dimensionless and is obtained by mapping the 5th bit of the 12-bit code; V represents the base value of a single token, expressed in yuan per token, and is dynamically adjusted based on market conditions.
[0021] The total price for bulk purchases is calculated using a tiered discount method: P_total = P_base × Q × δ(Q) in: P_total represents the total price of the bulk purchase, in yuan. P_base is the base unit price, in yuan / unit; Q represents the quantity to be purchased, in units of [number]. δ(Q) is the tiered discount factor, which is dimensionless and is determined based on the purchase quantity Q according to the following rules: When Q ≤ 1,000, δ(Q) = 1.00; When 1,000 < Q ≤ 10,000, δ(Q) = 0.95; When 10,000 < Q ≤ 100,000, δ(Q) = 0.90; when Q > 100,000, δ(Q) = 0.85.
[0022] [Coefficient Preset and Adjustment Mechanism] The initial values of each coefficient in this invention are not random or empirically estimated, but are predetermined based on the following practical criteria: Data classification coefficient C: Based on the actual annotation cost statistics of data modalities, it is mapped to the 1-500 level according to the cost ratio and generated using an arithmetic sequence (tolerance 1.2).
[0023] Computing power coefficient S: Converted into a coefficient level based on the market rental price of mainstream GPUs / CPUs and the time consumed per unit of computing power.
[0024] Knowledge difficulty coefficient K: is set in levels according to the professional level (education, training period, error rate) required for the labeled task.
[0025] The manual time consumption coefficient H is fitted using a piecewise power function based on the unit time cost of labeling different types of data.
[0026] Fineness coefficient F: Set according to the annotation accuracy requirements (coarse annotation, pixel level, sub-pixel level).
[0027] Scarcity fine-tuning factor α and security fine-tuning factor β are set based on the scarcity of data and the cost of privacy processing.
[0028] The benchmark value V of a single token is determined by comprehensively referencing mainstream API pricing models and market data transaction prices.
[0029] The initial values of the aforementioned coefficients were configured all at once before the system went live, ensuring that the pricing results closely matched the actual market transaction prices. The system provides a backend configuration interface, allowing platform operators to manually or through semi-automatic tools fine-tune individual coefficients based on subsequent market changes or cost fluctuations. After adjustment, the system recalculates prices and updates the cache. Future development can further integrate dynamic optimization algorithms based on historical transaction data to achieve adaptive optimization of the coefficients.
[0030] The overall system architecture of this invention consists of five core functional modules, each with the following business functions: Encoding Generation Module: Reads the basic attributes of data assets and automatically generates a 12-bit category transaction code and a 32-bit DAC verification code matching the attributes; Coefficient Mapping Module: Establishes a one-to-one correspondence between code segment fields and pricing calculation coefficients, and stores the coefficient values corresponding to various codes; Pricing Calculation Module: Reads the asset token quantity and encoding information, substitutes them into the pricing formula, and automatically calculates the unit price and total bulk purchase price of the data assets; Transaction Matching Module: Receives the asset code input by the purchaser, retrieves the corresponding data asset information, and completes the automatic matching process for online transactions; Cross-Platform Circulation Module: Unifies encoding parsing rules, enabling different trading platforms to recognize the same code, synchronize pricing parameters, and exchange transaction information.
[0031] The same set of lung CT medical imaging data can be adapted to both general scientific research scenarios and high-end commercial diagnostic scenarios by configuring different 12-bit category codes. Differences in the coding fields (such as scarcity, security level, computing power level, and subdivided tasks) will be automatically mapped to different combinations of coefficients in the pricing formula, thereby calculating differentiated unit prices and achieving the technical effect of scenario-based pricing.
[0032] The coded data retrieval and transaction process is optimized. The buyer inputs code 171212043210, with a purchase quantity of 1000 units. The system automatically performs the following operations: parsing the asset type, scarcity level, security handling method, computing power requirements, business functions, and subdivided tasks corresponding to the code; automatically substituting these into a formula to calculate the total purchase price; and automatically issuing data access authorization after the buyer confirms the order. Traditional manual transaction processes typically take 1 to 3 days. Using this coded transaction model, the overall time for a single online transaction can be reduced to 1 to 5 minutes, significantly improving transaction processing efficiency.
[0033] Beneficial effects are compared with existing technologies in six dimensions: 1. Data asset retrieval dimension: Existing technologies rely on manual communication and manual tagging, which is time-consuming; this invention uses one-click retrieval through code input, and the system quickly completes asset matching, effectively reducing the time cost of data search; 2. Asset value pricing dimension: Existing technologies use a uniform fixed price, resulting in a large deviation between the pricing result and the actual asset value; this invention relies on multi-dimensional coding to differentiate business scenarios and automatically calculates prices in layers, narrowing the deviation between the pricing result and the true asset value; 3. Online transaction process dimension: Existing technologies require a large amount of manual verification and offline document signing, with a complete transaction cycle of 1 to 3 days; this invention achieves fully online automated transactions, with a cycle of 1 to 5 days. The entire online process can be completed in minutes, reducing manual labor input; 4. Cross-platform asset circulation dimension: Existing platform coding and pricing rules are not interchangeable, and listing assets on multiple platforms requires repeated submission of materials and repeated review; This invention adopts unified coding rules, and asset information can be adapted to multiple cooperative platforms after one filing, reducing the workload of listing on multiple platforms; 5. Asset information traceability dimension: Existing technologies lack coding anti-tampering verification methods, and it is difficult to completely retain historical asset modifications and transaction records; This invention, with hash verification codes, timestamps, and version numbers, can completely trace asset lifecycle changes and transaction behaviors, reducing the risk of information tampering; 6. Coding system iteration dimension: Adding new data types and business scenarios requires a complete reconstruction of coding rules; This invention reserves extended fields and provides version differentiation rules, and subsequent additions of new business dimensions can directly extend field definitions without reconstructing the underlying coding architecture, resulting in lower iteration and upgrade costs. Attached Figure Description Figure 1: Overall system architecture diagram, showing the five major functional modules and the data interaction relationships between them; Figure 2: 12-bit encoding structure diagram, showing the field names and definitions corresponding to each segment of the 12-bit encoding; Figure 3: 32-bit DAC code structure diagram, showing the four character segments: version number, timestamp, category code, and check code; Figure 4: Automated pricing and transaction method flowchart, showing the complete process of data asset listing, retrieval and matching, automatic pricing, order placement and payment, and data delivery; Figure 5: Mapping relationship diagram between encoding fields and pricing coefficients, showing the one-to-one correspondence between encoding segments and pricing calculation coefficients. Detailed Implementation 6.1 Example Scheme for Encoding Generation: Medical lung CT image data assets are selected as the implementation case. The encoding and meanings of the two business scenarios are as follows: First set, ordinary scientific research scenario encoding 171-0-0-01-03-21-0, meaning: medical imaging category, regular existing data, publicly available unprotected data, CPU computing power consumption, image segmentation category, ordinary semantic segmentation task, default regular extension mode; Second set, commercial medical diagnosis scenario encoding 171-2-1-04-03-21-0, meaning: medical imaging category, market rare data, de-identified data, A100 high-end GPU computing power consumption, image segmentation category, high-precision semantic segmentation task, default regular extension mode.
[0034] 6.2 Example of Value Assessment Scheme: Taking lung CT image data as an example, the same raw data asset can be configured with different 12-digit category codes to adapt to both general annotation needs and high-end precision annotation needs, thereby achieving differentiated pricing: The standard annotation scenario (coded 171-0-0-01-03-21-0) has the following characteristics: data modality is medical images (171), scarcity is common (0), security level is public (0), computing power is CPU (01), business function is segmentation (03), and sub-task is ordinary semantic segmentation (21). This code corresponds to a relatively low coefficient combination (lower values for C, S, K, H, and F), and the calculated unit price is suitable for non-commercial scenarios such as scientific research previews and preliminary algorithm testing.
[0035] High-end annotation scenario (code 171-2-1-04-03-21-0): Data modality is medical images (171), scarcity is rare (2), security level is anonymized (1), computing power level is high-end GPU (04), business function is segmentation (03), and sub-task is high-precision semantic segmentation (21, corresponding to higher H and F coefficients). This code corresponds to a higher coefficient combination, and the calculated unit price is significantly higher than that of ordinary scenarios. It is suitable for scenarios with higher requirements for data quality and accuracy, such as commercial diagnosis in medical institutions and AI model training.
[0036] The differences between the two encoding methods mainly lie in the scarcity, security level, computing power tier, and H and F coefficients corresponding to specific tasks. The pricing formula automatically calculates differentiated unit prices based on these coefficients, thereby achieving the technical effect of "pricing by quality and pricing by scenario" on the same original data asset, avoiding the value distortion problem caused by uniform pricing.
[0037] 6.3 Complete Automated Transaction Implementation Process: The purchaser inputs the target data code 171210403210 and the purchase quantity of 1000 images. The system quickly retrieves and matches the corresponding medical imaging assets, automatically applies the pricing formula to calculate the total purchase amount. After the purchaser confirms the order and completes online payment, the system can automatically issue the corresponding CT image data access permissions and deliver the data files within 3 minutes. The entire transaction process requires no human customer service intervention.
[0038] 6.4 Specific Implementation of Encoding Retrieval and Matching This embodiment further refines the specific implementation of the encoding retrieval and precise supply-demand matching in step S4 of claim 5. Through dedicated database table structure design, prefix index optimization, hierarchical retrieval filtering, and qualification and permission verification mechanisms, it achieves high-speed retrieval, precise matching, and secure access control of data assets.
[0039] This system only provides time-limited access rights transactions for data assets: the original data is always stored locally by the data provider. The platform only stores metadata, encoding, pricing and ownership information, and does not store the original data content, nor does it transfer data ownership to the purchaser. The purchaser obtains data access and AI learning permissions within the agreed usage period (e.g., 15 days, 30 days or a custom duration). After the expiration of the period, the system automatically revokes the access token and completes the transaction loop (see step 5 of section (iii) and the end of section (iv) for specific implementation).
[0040] The system sets up a main asset table (asset_table) to store metadata, coding information, pricing information, and ownership information of listed assets, but does not store raw business data. It must contain at least the following fields: asset_id BIGINT, unique asset identifier, primary key; code_12 CHAR(12), a 12-bit category code; code_32 CHAR(32), the complete code for a 32-bit DAC; asset_name VARCHAR(255), the name of the asset; modality INT corresponds to the first 3 bits of the encoding (data modality category); rarity TINYINT, corresponding to the 4th bit of the encoding (data scarcity); security TINYINT corresponds to the 5th digit of the code (security protection level). compute TINYINT corresponds to the 6th and 7th bits of the encoding (computing power resource level); func_type TINYINT corresponds to the 8th and 9th digits of the encoding (business function category); sub_task TINYINT corresponds to the 10th-11th bits of the encoding (subdivided business tasks). reserve TINYINT, corresponding to the 12th bit of the encoding (reserved extension bit); token_count BIGINT, the total number of tokens in the data asset; base_price DECIMAL(10,6), the pre-calculated base unit price; owner_id VARCHAR(32), the identifier of the asset provider; status TINYINT, Asset status: 0 listed, 1 delisted, 2 sold; create_time DATETIME, the asset listing time.
[0041] To accelerate precise and fuzzy searches based on 12-digit category codes, a prefix index is created for the `code_12` field in the database. Since each segment of the 12-digit code corresponds to specific business semantics, purchasers can input the complete code for precise searching, or input the first few digits of the code (e.g., "171") to batch query all medical imaging assets. The index creation statement is: SQL CREATE INDEX idx_code_prefix ON asset_table (code_12(6)); This index indexes the first 6 digits, covering multiple dimensions of retrieval including modality, scarcity, security level, and computing power. It quickly locates unique assets when the complete 12-digit code is input; when a partial prefix of 1-6 digits is input, it batch-matches asset sets, which are then finely filtered by the application layer.
[0042] After receiving the search results entered by the buyer, the system processes them according to the following steps: Parameter analysis: If the input is a pure number with a length of 1 to 12 characters, it is determined to be a prefix retrieval; otherwise, it is a full-text fuzzy keyword matching.
[0043] Index queries: Encoded prefix searches use LIKE 'prefix%' in conjunction with prefix indexes; keyword searches use character matching or Elasticsearch full-text search.
[0044] Result set filtering: Based on buyer qualification information, invalid assets that are not authorized, have been delisted, or have already been sold are removed.
[0045] Real-time price calculation: If the asset's base_price is empty, the pricing calculation module is called to calculate the base unit price in real time. The pricing formula is: Pbase=T×(C+S+K+H)×F×α×β×VPbase=T×(C+S+K+H)×F×α×β×V Where: TT is the total number of tokens; C,S,K,H,F,α,β are the coefficients of the encoding mapping; VV is the base value of a single token (dynamically adjusted according to market conditions). The calculated value is cached in the database; if a pre-calculated unit price is already available, it is read directly.
[0046] The result returned is a standardized list containing the asset name, 12 / 32-bit code, real-time unit price, asset provider, usage period (determined according to the transaction agreement), and asset status, which is then pushed to the buyer's front end. After the buyer confirms the order, the system generates an access token with an expiration date based on the agreed usage period. The token automatically expires upon expiration (see the end of Section (iv) of this article for the implementation mechanism).
[0047] The system maintains the buyer qualification table (buyer_qualification), which includes the following fields: buyer_id VARCHAR(32), a unique identifier for the buyer; allowed_modality VARCHAR(100) represents the allowed data modality code (comma-separated). allowed_security TINYINT, the highest security level allowed for access; credit_score TINYINT, credit score (0-100 points).
[0048] During the search process, the system embeds qualification verification into the database query conditions to achieve pre-emptive interception: Modal permission verification: If the modal allowed by the buyer does not include the asset modal, filter it; Security level verification: If the asset's security level is higher than the highest level allowed by the buyer, filter it. Creditworthiness verification: If the buyer's credit score is lower than the preset threshold (default 50 points), the search request will be rejected and "insufficient creditworthiness" will be returned.
[0049] The mechanism for ensuring that time-limited usage rights and data ownership are not transferred is as follows: When an order is generated, the system records the asset ID, buyer ID, and usage period (start and end times) in the token table, and generates an access token with an embedded validity period. When processing data access requests, the API gateway first verifies whether the token is within its validity period; if it has expired, it is directly rejected. The original data is always stored locally on the data provider's site; the platform does not store the original data, nor does it transfer data ownership to the buyer. Through the above token validity period verification and API gateway interception, the permission automatically expires after the usage period, completing the closed loop of the time-limited usage right transaction.
Claims
1. A data asset encoding system for automated pricing and simplified transactions, characterized in that, It includes a code generation module, a coefficient mapping module, a pricing calculation module, a transaction matching module, and a cross-platform circulation module; The encoding generation module is used to generate a unique 12-digit pure numeric category code based on the data asset's modality, scarcity, privacy and security level, computing power requirements, business functions, and subdivided tasks. The fields of the 12-digit category code are allocated as follows: digits 1-3 represent the data modality category, digit 4 represent the data scarcity, digit 5 represent the privacy and security level, digits 6-7 represent the computing power level, digits 8-9 represent the business function category, digits 10-11 represent the subdivided tasks, and digit 12 represents the reserved extension space. Based on the 12-digit category code, a 2-digit version number, an 8-digit timestamp, and the first 10 bits of the checksum extracted by the SHA-256 hash algorithm are concatenated to generate a 32-digit DAC complete data asset code. The coefficient mapping module is used to establish a one-to-one mapping relationship between each field of the 12-bit category code and the corresponding pricing coefficient. The pricing coefficient includes data classification coefficient C, computing power coefficient S, knowledge difficulty coefficient K, manual time consumption coefficient H, precision coefficient F, scarcity fine-tuning factor α, and privacy and security fine-tuning factor β. The pricing calculation module stores a preset pricing calculation formula, retrieves all coefficients obtained from the mapping, the total number of data asset tokens T, and the dynamically updated single token base value V, automatically calculates the basic unit price of data assets P_base, and calculates the total bulk purchase price P_total based on the purchase quantity Q and the preset tiered discount coefficient δ(Q), where P_base = T × (C + S + K + H) × F × α × β × V, P_total = P_base × Q × δ(Q); The transaction matching module receives the 12-digit category code and purchase quantity input by the user, retrieves and matches the corresponding data assets based on the database prefix index, and automatically completes the transaction process of qualification verification, price calculation, order generation, settlement, permission issuance, and data delivery. The cross-platform circulation module uses a standardized interface based on a unified 12-bit category code parsing rule to identify 12-bit category codes and 32-bit DAC codes, enabling code mutual recognition, pricing parameter synchronization, and transaction record sharing between different data trading platforms.
2. The data asset encoding system for automated pricing and simplified transactions according to claim 1, characterized in that, The 12-digit pure numeric category code serves as a unique machine-readable carrier, using multiple fields to finely distinguish the multidimensional attributes of data assets, adapting to database prefix index retrieval, and enabling automatic machine identification, automatic value quantification, and online transactions.
3. The data asset encoding system for automated pricing and simplified transactions according to claim 1, characterized in that, For the same original data asset, multiple unique 12-digit category codes are generated by configuring different parameters in the coding fields such as scarcity, privacy and security level, computing power level, and subdivided task fields. Different codes correspond to different coefficient combinations and transaction prices, achieving differentiated pricing based on the data asset's usage scenario, privacy control level, computing power resources, and business operation difficulty.
4. The data asset encoding system for automated pricing and simplified transactions according to claim 1, characterized in that, The field length of the 32-bit DAC complete data asset code is: the 1st to 2nd digits are the version number, the 3rd to 10th digits are a timestamp in YYYYMMDD format, the 11th to 22nd digits are a 12-bit category code, and the 23rd to 32nd digits are the first 10 check digits intercepted based on the SHA-256 hash algorithm; the check digit is used to verify the integrity of the code, the version number is used to adapt to the iterative upgrade of the coding system, and the timestamp is used for the full life cycle traceability management of data assets.
5. A data asset encoding method for automated pricing and simplified transactions, characterized in that, Applied to the coding system according to any one of claims 1 to 4, comprising the following steps: S1, standardized filing for data asset warehousing: receiving the original data asset uploaded by the seller, automatically collecting information including the modality, scarcity, privacy security level, computing power requirement, business function and subdivision task of the data asset, automatically generating a unique 12-bit pure digital category code; generating the 32-bit DAC complete data asset code by combining the system version number, asset generation timestamp and SHA-256 hash check code, and storing the code in a database after completing the code repeatability check; S2, automatic mapping between codes and pricing coefficients: the system parses each field of the 12-bit category code, retrieves a preset mapping comparison table, binds the corresponding data classification coefficient C, computing power coefficient S, knowledge difficulty coefficient K, manual time consumption coefficient H, fineness coefficient F, scarcity adjustment factor α, and privacy security adjustment factor β, and generates an exclusive coefficient combination for the current data asset; S3, automatic pricing accounting of data assets: retrieving a preset pricing calculation formula, the total number of Tokens T of the data asset, and the real-time updated single Token benchmark value V, combining all coefficients obtained in step S2, automatically calculating the base unit price according to the formula P_base = T × (C + S + K + H) × F × α × β × V, and calculating the total price of bulk purchase P_total = P_base × Q × δ(Q) according to the purchase quantity Q and the preset stepped discount coefficient δ(Q), wherein the stepped discount coefficient δ(Q) is determined according to the interval where Q is located: δ(Q) = 1.00 when Q ≤ 1000, δ(Q) = 0.95 when 1000 < Q ≤ 10000, δ(Q) = 0.90 when 10000 < Q ≤ 100000, and δ(Q) = 0.85 when Q > 100000; S4, code retrieval and accurate matching between supply and demand: receiving the 12-bit category code or attribute keyword input by the buyer, completing retrieval and matching by using the prefix index of the database, displaying the complete attribute information of the data asset and calculating the price in real time; meanwhile, automatically verifying the transaction qualification of the buyer, filtering unauthorized assets and intercepting unauthorized access requests according to the allowable data modality, maximum security level and credit score accessible to the buyer; S5, full-process automatic transaction execution: after the buyer confirms the purchase quantity and transaction price, the system automatically completes capital expense settlement, electronic order archiving, data access authority distribution and encrypted data asset push delivery; S6. Cross-platform data asset circulation and mutual recognition: Each cooperating data trading platform uses a standardized interface based on a unified 12-digit category code parsing rule to parse and identify the 12-digit category code. This code serves as a unique index to achieve cross-platform synchronous mutual recognition of basic data asset information, pricing coefficients, and historical transaction records, supporting cross-platform listing and trading of data assets.
6. The encoding method according to claim 5, characterized in that, The range and threshold of the tiered discount coefficient δ(Q) can be dynamically configured according to the platform's operation strategy.
7. The encoding method according to claim 5, characterized in that, The 12th bit of the 12-bit category code is a reserved extension bit, and the 32-bit DAC code is configured with a 2-bit version number. When a new data asset modality, pricing dimension, or subdivided business task is added, the reserved extension bit is used to add a new coding range, and the version number is used to distinguish between the old and new coding rules. There is no need to reconstruct the underlying database architecture, so as to achieve a smooth iterative upgrade of the coding system and pricing model.