Electronic document generation based on distributed ledger
By creating a single copy of a general template on a distributed ledger and using a machine learning model to extract user-specific information, the problems of storage efficiency and computational complexity in distributed ledgers are solved, enabling the generation of electronic documents with low memory usage and fast processing.
Patent Information
- Application Number
- CN202080039178.0
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Priority Date
- 2019-10-15
- Filing Date
- 2020-10-05
- Publication Date
- 2025-09-30
- Estimated Expiration
- 2040-10-05
AI Technical Summary
In distributed ledgers, as the number of data records increases, the efficiency and computational complexity of accessing and processing transaction records increase. Existing technologies face challenges, especially in decentralized applications that require low memory usage and fast processing time.
By creating a single copy of a general template on a distributed ledger and abstracting user-specific content, combined with a machine learning model to identify and extract template information and user information, an electronic file is generated, reducing the storage of multiple copies of the general template and improving storage efficiency.
It enables electronic file generation with low memory usage and fast processing time, improves data retrieval efficiency and reduces storage requirements.
Smart Images

Figure CN113892094B_ABST
Abstract
Description
[0001] Cross-reference to related applications / incorporation by reference
[0002] none. Technical Field
[0003] Various embodiments of the present disclosure relate to data management for distributed databases. More specifically, various embodiments of the present disclosure relate to systems and methods for generating electronic files based on distributed ledgers. Background Art
[0004] Advances in data management technology have led to the development of distributed ledgers (such as blockchains) that provide transaction security and immutability. In a distributed ledger, copies of transaction data can be distributed across multiple nodes in the system, allowing every node to understand every transaction. The ledger can consist of multiple blocks, each representing data related to a transaction. Furthermore, each node can be capable of verifying each new transaction based on its understanding of the current state of the ledger. Generally, as the number of application-specific data records on a distributed ledger increases, the efficiency and computational complexity of accessing and processing these records decreases, especially in the case of decentralized applications that require low memory usage and fast processing times.
[0005] As explained in subsequent portions of this application and with reference to the accompanying figures, further limitations and disadvantages of conventional and traditional approaches will become apparent to those skilled in the art by comparing the described systems with certain aspects of the present disclosure. Summary of the Invention
[0006] As more fully set forth in the claims, as illustrated in at least one of the figures and / or described in conjunction with at least one of the figures, there is substantially provided a system and method for generating an electronic document based on a distributed ledger.
[0007] These and other features and advantages of the present disclosure may be understood by reading the following detailed description of the disclosure and the accompanying drawings, in which like reference numerals refer to like parts throughout. BRIEF DESCRIPTION OF THE DRAWINGS
[0008] Figure 1 is a diagram illustrating an exemplary network environment for generating an electronic file based on a distributed ledger according to an embodiment of the present disclosure.
[0009] Figure 2 is a block diagram illustrating a data management system for generating electronic files according to an embodiment of the present disclosure.
[0010] Figure 3 is a sequence diagram illustrating creation of a block on a distributed ledger according to an embodiment of the present disclosure.
[0011] Figure 4 is a sequence diagram illustrating the generation of an electronic file based on a distributed ledger according to an embodiment of the present disclosure.
[0012] Figure 5 is a sequence diagram illustrating domain configuration based on a user request according to an embodiment of the present disclosure.
[0013] Figure 6 This is an example of an embodiment according to the present disclosure. Figure 2 A sequence diagram of an exemplary implementation of a data management system in FIG.
[0014] Figure 7 is a flowchart illustrating an exemplary method for generating an electronic file based on a distributed ledger according to an embodiment of the present disclosure. DETAILED DESCRIPTION
[0015] The embodiments described below can be understood in the context of the disclosed system and method for generating electronic files based on a distributed ledger. Exemplary aspects of the present disclosure provide a data management system that can be communicatively coupled to a distributed ledger (e.g., a blockchain network). The distributed ledger can store file information for multiple users and a set of smart contracts that control access to the stored file information. The data management system can receive a user request for an electronic file from a user. The user request can include a user identifier (ID) of the user. Based on a domain (e.g., an education domain) identified from the received user request, one or more smart contracts can be selected from the set of smart contracts. The data management system can extract user-specific information from the stored file information based on the user ID and the selected smart contract. The data management system can then extract template information from the stored file information based on a content ID of the template information and the selected smart contract. An electronic file can be generated based on the extracted user-specific information and the extracted template information.
[0016] The disclosed system and method provide storage-efficient data management based on a data abstraction framework that abstracts domain-specific data that can be shared across users from user-specific data that may be private to the user. Also disclosed herein is a machine learning system for retrieving domain-specific template data for different domains to process data from various domains that can be stored on a distributed ledger. Generally, a database system creates multiple copies of a file containing a universal template for a specific domain. Common content in this universal template may be repeated across multiple files. The disclosed data management system creates a universal template for each domain and stores a single copy of the universal template in a node (e.g., a blockchain node). This avoids storing multiple copies of the universal template, thereby reducing memory usage. Furthermore, the disclosed data management system abstracts user-specific content from each scanned file. User-specific content is distinct from universal content and can be different for each user. Therefore, whenever a user's file is requested, universal and user-specific content can be instantly combined and securely provided to the user.
[0017] Figure 1 FIG is a diagram illustrating an exemplary network environment for generating electronic files based on a distributed ledger according to an embodiment of the present disclosure. Figure 1 , a network environment 100 is shown. The network environment 100 includes a data management system 102, a user device 104, and an authorizer device 106. The user device 104 can host a client 108, such as a web browser. The network environment 100 also includes a distributed ledger 110 and a communication network 112. The communication network 112 can be established between two or more computing devices in the network environment 100. For example, the communication network 112 can be between the data management system 102, the user device 104, the authorizer device 106, and the distributed ledger 110. The distributed ledger 110 can store a plurality of blocks 114 and can be associated with a set of smart contracts 116 that can control access to the plurality of blocks 114 of the distributed ledger 110. Also shown here is a user 118 associated with the user device 104.
[0018] The data management system 102 may include appropriate logic, circuitry, and interfaces that may be configured to perform operations associated with generating electronic files for a particular domain (e.g., an education domain). The electronic files may be specific to a user 118 and may be generated based on user-specific information and template information on the distributed ledger 110. Example implementations of the data management system 102 may include, but are not limited to, a server, a distributed network of servers, a computing device, a mainframe machine, a computer workstation, and / or a consumer electronics (CE) device.
[0019] According to an embodiment, the data management system 102 can host a decentralized application, which may include a client-side interface (front end), a server-side interface (back end), and distributed logic. The client-side interface (front end) may be configured to be loaded on the client 108, while the server-side interface may run on the data management system 102. The distributed logic of the decentralized application may be executable on the distributed ledger 110 and may include a smart contract group 116. Each smart contract in the smart contract group 116 may be a self-executable program or computer code that can be run on the distributed ledger 110 and may include a set of conditions under which the parties to the smart contract agree to interact with each other. A smart contract may be stored at a specific address on the distributed ledger 110 and may be a collection of computer code (i.e., functionality) and data (i.e., the state of an account).
[0020] The user device 104 may include appropriate logic, circuitry, and interfaces that may be configured to access a client-side interface of a decentralized application hosted on the distributed ledger 110 via a client 108. For example, the client 108 may be a web browser that loads the client-side interface of the decentralized application. The client 108 may be configured to generate a user request for an electronic file and then transmit the user request to the data management system 102. Based on the transmitted user request, the client 108 may receive the electronic file generated as a readable document from the data management system 102. The user device 104 may include appropriate input / output (I / O) functionality and network functionality to facilitate communication between the client 108 and the data management system 102. Examples of the user device 104 may include, but are not limited to, a computing device, a mobile phone, a smartphone, a computer workstation, and / or any CE device.
[0021] The authorizer device 106 may include appropriate logic, circuitry, and interfaces that may be configured to verify that an electronic file is a valid file once it is generated and digitally signed via a hash. Examples of the authorizer device 106 may include, but are not limited to, a computing device, a mobile phone, a smartphone, a server, a remote server, a mainframe machine, a computer workstation, and / or a CE device. In at least one embodiment, the overall functionality of the authorizer device 106 may be incorporated into the user device 104 without departing from the scope of this disclosure.
[0022] The client 108 may be a computer application, such as a web browser, on the user device 104. The client 108 may correspond to a platform on the user device 104 to access a client-side interface of a decentralized application associated with the data management system 102.
[0023] The distributed ledger 110 can be a decentralized and distributed database system that can maintain an immutable record of data operations or transactions. A collection of data operations can be grouped together as a block and can be further linked to the previous data operation block to form a chain of multiple blocks 114. All data operation blocks can be stored in a decentralized manner, so that all participants or nodes store all multiple blocks 114. In addition, the distributed ledger 110 can include an operating system that can allow the deployment of smart contract groups 116 between multiple parties (e.g., users 118 and data management system 102).
[0024] Distributed ledger 110 can be a blockchain, which uses accounts as state objects, and the state of each account can be tracked through the chain. Here, an account represents the identity of a user, mining node, or automated agent. All data operation blocks or smart contracts are associated with an account on the blockchain.
[0025] By way of example and not limitation, the distributed ledger 110 may be an Ethereum blockchain, which may use accounts as state objects and the state of each account may be tracked by the Ethereum blockchain. Here, an account represents the identity of a user, mining node, or automated agent. All data operation blocks or smart contracts are associated with an account on the Ethereum blockchain. The scope of the present disclosure may not be limited to implementing the distributed ledger 110 as an Ethereum blockchain, a Hyperledger blockchain, or a Corda blockchain. Other implementations of the distributed ledger 110 are also possible in the present disclosure without departing from the scope of the present disclosure.
[0026] The plurality of blocks 114 may store file information for multiple users and may include a set of template data blocks and a set of user data blocks. The set of template data blocks may correspond to a set of electronic file templates for one or more domains. Similarly, the set of user data blocks may include personal data of multiple users for the set of electronic file templates.
[0027] The communication network 112 may include a communication medium through which the data management system 102, the user device 104, the authorizer device 106, and the distributed ledger 110 can communicate with each other. Examples of the communication network 112 may include, but are not limited to, the Internet, a cloud network, a wireless fidelity (Wi-Fi) network, a personal area network (PAN), a local area network (LAN), or a metropolitan area network (MAN). Various devices in the network environment 100 may be configured to connect to the communication network 112 according to various wired and wireless communication protocols. Examples of such wired and wireless communication protocols may include, but are not limited to, at least one of the Transmission Control Protocol and Internet Protocol (TCP / IP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), ZigBee, EDGE, IEEE 802.11, Light Fiber (Li-Fi), 802.16, IEEE 802.11s, IEEE 802.11g, multi-hop communication, wireless access point (AP), inter-device communication, cellular communication protocol, and Bluetooth (BT) communication protocol.
[0028] In operation, the distributed ledger 110 may host decentralized applications ( Figure 1 104). On the user device 104, the client 108 may receive a first user input (e.g., a uniform resource locator (URL)) to access the client-side interface of the decentralized application. Once the client-side interface is loaded and displayed on the user interface of the user device 104, the client 108 may receive a second user input as a user request to generate an electronic file for a specific domain of interest to the user 118. The client 108 may transmit the user request to the data management system 102 via the client-side interface. As briefly described herein, the data management system 102 may initiate processing to generate the electronic file based on the second user input.
[0029] Data management system 102 may receive a user request from client 108 to generate an electronic file associated with user 118. For example, the user request may include a user ID. Data management system 102 may identify a domain associated with the received user request. Examples of domains may include, but are not limited to, an education domain, a medical domain, or a retail / e-commerce domain.
[0030] For example, in the case of an education domain, the electronic file may correspond to, but is not limited to, a secondary school file, a graduation file, a post-graduation file, or a transcript file. Furthermore, in the case of a medical domain, the electronic file may correspond to, but is not limited to, a medical prescription, a pathology report, or a medical diagnosis report. Furthermore, in the case of a retail / e-commerce domain, the electronic file may correspond to, but is not limited to, a sales invoice, a purchase order, or an inventory / stock list. Thereafter, the data management system 102 may select one or more smart contracts for the identified domain from the smart contract group 116 and then extract user-specific information for the electronic file from one of the multiple blocks 114 of file information stored on the distributed ledger 110. For example, the user-specific information may include private information (or personally identifiable information (PII)), such as name, address, job title, employment details, financial information, and medical records. The data management system 102 may rely on the user ID and the selected one or more smart contracts to extract the user-specific information from the distributed ledger 110.
[0031] The data management system 102 can determine the content ID associated with the template information of the electronic certificate. According to an embodiment, the content ID can correspond to a hash key, based on which the template information can be hashed and stored in multiple blocks 114 on the distributed ledger 110. The template information can include information common to electronic files in a domain. For example, the template information for a middle school file can include the name of the educational institution, the name of the education board, a watermark of the education board / educational institution, and the authorized signature of the education board / educational institution.
[0032] In one embodiment, the data management system 102 can extract template information from the plurality of blocks 114 of file information stored on the distributed ledger 110. This extraction of template information can be based on the determined content ID and the selected one or more smart contracts. The data management system 102 can query the selected one or more smart contracts using the content ID to search for template information from the plurality of blocks 114. For example, the content ID can be used as a hash key to search for template information hashed and stored on the plurality of blocks 114 of the distributed ledger 110.
[0033] The data management system 102 can be configured to generate an electronic file based on the extracted user-specific information and the extracted template information. The electronic file can be generated based on a combination of the extracted user-specific information and the extracted template information. For example, in the case of a secondary school file in the education domain, the user-specific information may include the student's name, date of birth, and selected subjects. The template information may include the name of the educational institution, the name of the education board, watermark information, an authorized signature for the file, and a placeholder for including user-specific information. The data management system 102 can generate an electronic file by filling an empty file with the user-specific information in the template information and the placeholders of the above-mentioned template information. Thereafter, the server interface of the data management system 102 can transmit the generated electronic file to the client interface loaded on the client 108. For example, in Figure 4 , further illustrating the generation of electronic files based on the distributed ledger 110.
[0034] Figure 2 1 is a block diagram illustrating a data management system for generating electronic files according to an embodiment of the present disclosure. Figure 1 To illustrate the elements Figure 2 . refer to Figure 2 , a block diagram 200 depicting a data management system 102 is shown. The data management system 102 includes a circuit system 202, a memory 204, an input / output (I / O) device 206, and a network interface 208. The I / O device 206 may include a display device 210 and a user interface (UI) 212. The circuit system 202 may be configured to communicate with the user device 104, the authority device 106, and the distributed ledger 110 via the communication network 112 using the network interface 208.
[0035] The circuit system 202 may include suitable logic, circuit systems, interfaces, and / or code that may be configured to execute instructions stored in the memory 204. Some of the instructions may be associated with processing user requests to generate electronic files for one or more domains. In addition, the instructions may be associated with user authentication, file processing operations, smart contract management, etc. Examples of implementations of the circuit system 202 may include a central processing unit (CPU), an x86-based processor, a reduced instruction set computing (RISC) processor, an application-specific integrated circuit (ASIC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a coprocessor, other processors, and / or combinations thereof.
[0036] The memory 204 may include suitable logic, circuitry, and / or interfaces that may be configured to store instructions that may be executed by the circuitry 202. Examples of implementations of the memory 204 may include, but are not limited to, random access memory (RAM), read only memory (ROM), a hard disk drive (HDD), and / or a secure digital (SD) card.
[0037] I / O device 206 may include appropriate logic, circuitry, and interfaces that may be configured to receive input and provide output based on the received input. I / O device 206 may include various input and output devices that may be configured to communicate with circuitry 202. Examples of I / O device 206 may include, but are not limited to, a touch screen, a keyboard, a mouse, a joystick, a display device (e.g., display device 210), a microphone ( Figure 2 Not shown) and speakers ( Figure 2 not shown).
[0038] The network interface 208 may comprise suitable logic, circuitry, interfaces, and / or code that may be configured to enable communication between the data management system 102, the user device 104, the authorizer device 106, and the distributed ledger 110 via the communication network 112. The network interface 208 may implement known techniques to support wired or wireless communication with the communication network 112.
[0039] The network interface 208 may include, but is not limited to, an antenna, a frequency modulation (FM) transceiver, a radio frequency (RF) transceiver, one or more amplifiers, a tuner, one or more oscillators, a digital signal processor, a coder / decoder (CODEC) chipset, a subscriber identity module (SIM) card, and / or a local buffer. The network interface 208 may communicate with a network such as the Internet, an intranet, and / or a wireless network such as a cellular telephone network, a wireless local area network (LAN), and / or a metropolitan area network (MAN) via wireless communication. Wireless communications may use any of a variety of communication standards, protocols, and technologies such as Long Term Evolution (LTE), Global System for Mobile Communications (GSM), Enhanced Data GSM Environment (EDGE), Wideband Code Division Multiple Access (W-CDMA), Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Bluetooth, Wireless Fidelity (Wi-Fi) (e.120g., IEEE802.11a, IEEE 802.11b, IEEE 802.11g, and / or IEEE 802.11n), Voice over Internet Protocol (VoIP), Wi-MAX, email protocols, instant messaging, and / or short message service (SMS).
[0040] The display device 210 may include appropriate logic, circuitry, and interfaces that may be configured to display output from the data management system 102. The display device 210 may be used to render the UI 212. In some embodiments, the display device 210 may be an external display device associated with the data management system 102. The display device 210 may be implemented using several known technologies, such as, but not limited to, at least one of a liquid crystal display (LCD) display, a light emitting diode (LED) display, a plasma display, or an organic LED (OLED) display technology, or other display devices. Depending on the embodiment, the display device 210 may refer to a smart glasses device, a see-through display, a projection-based display, an electrochromic display, a transparent display, or a display screen of a head-mounted device (HMD).
[0041] For example, Figure 3 The creation of multiple blocks 114 of the distributed ledger 110 is further described in FIG. Figure 4 The generation of electronic files based on the distributed ledger 110 is further described in Figure 4 The domain configuration is further described in .
[0042] Figure 3 is a sequence diagram illustrating the creation of a block on a distributed ledger according to an embodiment of the present disclosure. Figure 1 and Figure 2 To illustrate the elements Figure 3 . refer to Figure 3 , a sequence diagram 300 illustrating a method for creating a plurality of blocks 114 of certificate information on a distributed ledger 110 is shown. The sequence of operations may be from 302 to 324, which may be performed by various elements of the network environment 100, such as, but not limited to, the data management system 102, the client 108, and the distributed ledger 110. Also shown is an exemplary set of blocks 326, which may be part of the plurality of blocks 114 and may be created based on the methods described herein.
[0043] At 302, the electronic file can be uploaded to the data management system 102 via the client 108. Additionally, a user ID can be provided along with the uploaded file to the data management system 102. In some embodiments, before the electronic file is uploaded, the client 108 can receive user input and electronically scan a hard copy (i.e., a physical copy) of the file to generate the file for the user 118. Alternatively, the file may already be in an electronically scanned format.
[0044] For the user ID, the user 118 may provide his / her user credentials to access the data management system 102 through the client 108. The client 108 (or the data management system 102) may determine the user ID of the user 118 based on the user credentials. Once determined, the client 108 may upload a file (e.g., an electronic scan of a physical copy) and provide the user ID along with the uploaded file to the data management system 102. The data management system 102 receives the uploaded file.
[0045] At 304, the data management system 102 may check the authorization and authentication of the user 118 to upload the file. In other words, the data management system 102 may verify the user's identity and check the specific permissions of the user 118 to upload the file. For example, the user 118 may only be allowed to upload files of specific domains, and some domains may be restricted to the user 118. Based on the user credentials (or user ID), the data management system 102 may authenticate and authorize the user 118 to further provide the file so that it can be processed as the user's 118 file information and uploaded to the distributed ledger 110.
[0046] At 306 , the data management system 102 can transmit an authorization confirmation to the client 108 based on a determination that the user 118 is authenticated and authorized to upload files.
[0047] At 308, the data management system 102 may classify the uploaded files into domains and / or subdomains by using a first machine learning model. As part of a multi-class classification task of classifying files into specific domains and / or subdomains, the first machine learning model may be trained on templates of files from multiple domains / subdomains. Examples of the first machine learning model may include, but are not limited to, a linear regression model, a logistic regression model, a decision tree model, a support vector machine (SVM) model, a naive Bayes model, an artificial neural network (ANN) model, a deep neural network (DNN) model, a k-nearest neighbor (kNN) model, a k-means (k-Means) model, or a random forest model. For example, consider a scenario where the uploaded file is a graduation file for a specific subject. Based on applying a classifier based on the first machine learning model, the data management system 102 may classify the uploaded graduation file as belonging to the education domain and the graduation subdomain.
[0048] At 310, the data management system 102 can process the classified domains and / or subdomains. As part of this processing, the data management system 102 can extract information related to the classified domains and / or subdomains. This extracted information can include an indication of the classified domain (e.g., a domain name) and an identifier associated with the classified domain (e.g., a domain ID). Similarly, the extracted information related to the classified subdomains, if any, can include an indication of the classified subdomains and an identifier associated with the classified subdomains (e.g., a subdomain ID). For example, the domain ID can correspond to a hash of an indication of the classified domain, and similarly, the subdomain ID can also correspond to a hash of an indication of the classified subdomain.
[0049] At 312, the data management system 102 may separate the template information from the uploaded file based on a second machine learning model. The second machine learning model may be trained to identify template information from files classified into a specific domain or subdomain. Examples of the second machine learning model may include, but are not limited to, a linear regression model, a logistic regression model, a decision tree model, a SVM model, a naive Bayes model, an ANN model, a DNN model, a k-NN model, a k-Means model, or a random forest model.
[0050] For example, a second machine learning model can be trained based on a set of templates extracted from files that were previously used to classify into specific domains and / or subdomains. For example, for an uploaded file that is a graduation file from the education domain and the graduation subdomain, the data management system 102 can apply a second machine learning model to the uploaded file to identify template information such as a watermark, a university name, a statement of acknowledgement, or a signature authorized to sign. Such template information can be related to the domain / subdomain of the uploaded file. In addition, the second machine learning model can also detect a presentation style as part of the template information associated with the uploaded file. The presentation style can include, for example, font size, text / image orientation, and text / image transparency associated with the uploaded file. The data management system 102 can create a specific data structure to store the identified template information, including the presentation style of the uploaded file.
[0051] In one embodiment, when attempting to separate the template information from the uploaded file, the data management system 102 may be unable to match the information in the uploaded file to at least one of the set of templates associated with the identified domain and / or subdomain of the uploaded file. In such an embodiment, the data management system 102 may create a new template for the uploaded file. Alternatively, the data management system 102 may transmit a file processing failure indication to the client 108 and request the user 118 to verify the uploaded file.
[0052] In one embodiment, an uploaded electronic file may belong to a domain and a subdomain. The uploaded electronic file may include natural language text associated with the domain. The text may be arranged in the uploaded electronic file based on a specific file structure associated with the subdomain of the uploaded electronic file. The data management system 102 may include a cognitive engine (a process or server application) to perform data separation on the uploaded electronic file to determine the domain and subdomain of the uploaded electronic file. Therefore, based on the data separation, the cognitive engine may identify the domain and subdomain of the uploaded electronic file.
[0053] In certain embodiments, the data management system 102 may perform data segmentation on uploaded files based on natural language processing (NLP) techniques to automatically identify the domains / subdomains of the uploaded files. For example, the data management system 102 may use NLP techniques to perform pattern analysis on the text within the uploaded files to categorize the uploaded files into categories. The data management system 102 may perform semantic understanding of the structure of the uploaded files based on the categories of the uploaded files. Subsequently, the uploaded files may be classified into certain domains / subdomains based on the semantic understanding of the structure of the uploaded files.
[0054] For example, the data management system 102 can analyze the text in a file using NLP techniques to categorize the file into the medical category. Because files associated with the medical category may have different structures / content than files in other domains, it may be necessary to identify the domain / subdomain of the file. Based on a semantic understanding of the structure of files in the medical category, the data management system 102 can associate the file with the medical domain and the lab report subdomain.
[0055] In another embodiment, the data management system 102 can be configured to check the authenticity of the uploaded file based on the identified domain or subdomain and the extracted template information. For example, the data management system 102 can check the authenticity of the uploaded file from the authorized party device 106 and / or the file verifier to detect whether the uploaded file is fraudulent. In one embodiment, the authenticity check of the uploaded file can be performed against a list of domains and subdomains supported by the data management system 102. For example, a user may be allowed to upload a file related to the education domain, however, the user may upload a file related to the medical domain, which may not be supported by the data management system 102. In this case, the uploaded file may be rejected by the data management system 102 as an unsupported file type.
[0056] At 314, the data management system 102 may process the separated template information. As part of this processing, the data management system 102 may create an initial data block (e.g., Block_0 326A) on the distributed ledger 110. The data management system 102 may transmit the separated template information and the extracted information associated with the classified domains and / or subdomains to the distributed ledger 110. The distributed ledger 110 may include the separated template information and the extracted information in the initial data block.
[0057] Upon creation, the distributed ledger 110 can determine the content ID for the template information and insert the determined content ID into the initial data block. For example, the content ID can be a hash of the template information in the initial data block. For example, the initial data block can include the content ID, domain ID, subdomain ID (if any), and template information. Thereafter, a hash value of the content of the initial data block (e.g., Block_0 326A) can be determined and stored in the block itself (e.g., the hash value "Hash #0" of block Block_0 326A). The initial data block (e.g., Block_0 326A) can correspond to a template data block of the plurality of blocks 114.
[0058] An example of an initial data block is shown as Block_0 326A. It should be noted that Figure 3 The Block_0326A shown in FIG is presented only as an example and should not be construed as limiting the present disclosure. The present disclosure may also be applicable to initial data blocks for more than one file and / or for more than one domain / subdomain.
[0059] At 316 , the distributed ledger 110 may transmit the content ID associated with the template information to the data management system 102 .
[0060] At 318, the distributed ledger 110 may separate the user-specific information based on a third machine learning model. The third machine learning model may be trained to detect user-specific information from files classified into a specific domain or subdomain. Examples of the third machine learning model may include, but are not limited to, a linear regression model, a logistic regression model, a decision tree model, a SVM model, a naive Bayes model, an ANN model, a DNN model, a k-NN model, a k-Means model, or a random forest model.
[0061] For example, a third machine learning model can be trained based on a collection of templates extracted from electronic files previously classified into a specific domain or subdomain. The collection of templates can include information related to one or more users in a specific format. For example, in the case where the uploaded file is a graduation file (associated with the education domain and the graduation subdomain), the data management system 102 can apply the third machine learning model to the graduation file to detect user-specific information in the graduation file. For example, the data management system 102 can detect the user's name, discipline, college name, subject or major, and optionally the score or grade obtained by the user in the graduation course as user-specific information.
[0062] A person of ordinary skill in the art will understand that the overall functionality of the first machine learning model, the second machine learning model, and the third machine learning model can be combined into a single machine learning model for domain or subdomain identification, template information separation, and separation of user-specific information from uploaded files.
[0063] At 320, the data management system 102 may process the user-specific information. As part of the processing, the data management system 102 may create a first user data block (e.g., Block_1 326B) on the distributed ledger 110. Thereafter, the data management system 102 may transmit the user-specific information (at 318) to the distributed ledger 110 along with the user ID and the content ID associated with the separated template information. The distributed ledger 110 may include the user-specific information, the user ID, and the content ID in the first user data block. Thereafter, a hash value of the content of the first user data block (e.g., Block_1 326B) may be determined and stored in the first user data block (e.g., hash value "Hash #1" of Block_1 326B).
[0064] An example of a first user data block is shown as Block_1 326B. It should be noted that Figure 3 The Block_1 326B shown in FIG. 3 is presented only as an example and should not be construed as limiting the present disclosure. The present disclosure may also be applicable to user data blocks for more than one file and / or for more than one domain / subdomain.
[0065] At 322, the distributed ledger 110 may transmit a confirmation of the block formation to the data management system 102. For example, after forming the initial data blocks, namely the template data block (e.g., Block_0 326A) and the first user data block (e.g., Block_1 326B), the distributed ledger 110 may transmit a confirmation of the formation of the exemplary block set 326 indicating the plurality of blocks 114 to the data management system 102.
[0066] At 324, the data management system 102 may transmit a transaction ID associated with the creation of the first user data block (e.g., Block_1 326B) to the client 108. The client 108 may present an indication to the user 118 that the file has been successfully processed and that the file information associated with the file has been uploaded to the distributed ledger 110.
[0067] Here, a comparison of the traditional implementation of data storage in the blockchain and the implementation of the present disclosure is presented in Table 1 for performance evaluation, as shown below:
[0068]
[0069]
[0070] Table 1: Exemplary data storage in blockchain blocks of conventional and disclosed implementations
[0071] As shown in Table 1, in both conventional and disclosed implementations, block B1 may correspond to a data block with zero bytes (no data, i.e., 0 KB in size). For both implementations, block B2 may correspond to a provider block. For example, in both implementations, block B2 may have a size of 100 KB. Block B2 may include information related to the provider of the blockchain and a hash of block B2. Furthermore, blocks B3 and B4 may correspond to user data blocks for both blockchain implementations. In the case of conventional implementations, each user data block (i.e., B3 and B4) may include the data of the entire file (including template information and user-specific information) and a hash of the corresponding user data block. However, in the case of disclosed implementations, the user data blocks (i.e., B3 and B4) may only include user-specific information associated with the file and a hash of the corresponding user data block. Therefore, in the case of the implementation of the present disclosure, the size of such user data blocks (i.e., B3 and B4) can be smaller (e.g., 10KB each) compared to the size of user data blocks in traditional implementations (e.g., 100KB each). Therefore, the implementation of the present disclosure for data storage in the blockchain can have a lower memory footprint, which can lead to improved efficiency in data retrieval.
[0072] Figure 4 1 is a sequence diagram illustrating the generation of an electronic file based on a distributed ledger according to an embodiment of the present disclosure. Figure 1 、 Figure 2 and Figure 3 To illustrate the elements Figure 4 . refer to Figure 4, a sequence diagram 400 illustrating a method for generating an electronic file is shown. The sequence of operations may be from 402 to 422 and may be performed by various elements of the network environment 100, such as the client 108, the data management system 102, and the distributed ledger 110. Based on the method described herein, an exemplary electronic file 424 may be generated.
[0073] At 402, client 108 may transmit a user request with the user ID of user 118 to data management system 102. The user request may be generated based on user input received from user 118 by client 108. The user input may indicate a request to generate and / or share an electronic file of user 118 with a requesting entity. The user input may also include user credentials from which client 108 may extract the user ID.
[0074] At 404, the data management system 102 may authenticate the user 118 as a valid user with a valid identity and authorize the user 118 to request the electronic file based on the user ID. In some embodiments, the user request may also include an indication of a domain and / or subdomain associated with the user request. In such embodiments, the data management system 102 may further authorize the user 118 to request the electronic file based on the indication of the domain and / or subdomain associated with the user request.
[0075] In some embodiments, based on the user ID, the data management system 102 can verify the identity of the user 118 associated with the received user request. Additionally or alternatively, the data management system 102 can determine a set of user permissions associated with the received user request. For example, each user can have an associated set of permissions (e.g., the right to request electronic files in a specific domain / subdomain). For example, the data management system 102 can match the domain or subdomain indicated in the user request with the set of user permissions associated with the domain / subdomain for which the user 118 is permitted. Based on the verified identity and the determined set of user permissions, the data management system 102 can authenticate the received user request.
[0076] At 406 , the data management system 102 can transmit a confirmation to the client 108 based on the determination that the user 118 is authenticated and authorized to request the electronic file.
[0077] At 408, domain configuration may be performed. As part of the domain configuration process, the domain and / or subdomain associated with the received user request may be identified. Additionally, one or more smart contracts may be selected from the smart contract set 116 based on the identified domain and / or subdomain. For example, in Figure 5 The sequence of operations related to domain configuration is further described in .
[0078] At 410, the data management system 102 may extract user-specific information from the distributed ledger 110 based on the user ID received in the user request and one or more smart contracts selected from the smart contract set 116. The user-specific information may be extracted from file information in the distributed ledger 110. Here, file information may refer to a collection of user-specific information and template information for multiple users, and may be stored in multiple blocks 114 of the distributed ledger 110.
[0079] In one embodiment, to extract user-specific information, the data management system 102 may input the user ID into one or more selected smart contracts associated with the distributed ledger 110. For example, the user ID may be used by the selected one or more smart contracts to locate a user data block associated with the identified domain or subdomain of the user request. Based on the response of the one or more smart contracts, the data management system 102 may determine the user data block associated with the identified domain (or subdomain) of the user request. Thereafter, the user-specific information may be extracted from the determined user data block.
[0080] The user data block may correspond to one of the plurality of blocks 114 of file information and may store, for example, a hash of the electronic file, user-specific information, and a content ID. Figure 3 The first user data block (eg, Block_1 326B) is shown in FIG.
[0081] At 412 , the distributed ledger 110 may transmit the extracted user-specific information to the data management system 102 .
[0082] At 414, the data management system 102 may input a query for the content ID associated with the user request to the distributed ledger 110. Here, the content ID may be associated with the template information of the electronic file. The data management system 102 may receive a response to the query from the distributed ledger 110 and may determine the content ID based on the received response to the query. In some embodiments, because the content ID may be stored in the user data block, the distributed ledger 110 may extract user-specific information from the same user data block (e.g., Figure 3 The content ID is retrieved from Block_1 326B) shown in FIG.
[0083] At 416, the data management system 102 may extract template information from the distributed ledger 110 based on the content ID and one or more smart contracts selected from the smart contract group 116. The template information may be extracted from the file information stored on the distributed ledger 110. For example, to extract the template information, the data management system 102 may input the content ID into the selected one or more smart contracts. For example, the data management system 102 may execute the selected one or more smart contracts based on the content ID, and determine a template data block associated with the identified domain of the user request based on the response of the selected one or more smart contracts. Here, the template data block may correspond to one of the plurality of blocks 114 of file information on the distributed ledger 110, and may store, for example, a hash of the template data block, template information, content ID, domain information, and subdomain information. For example, the template data block may correspond to Figure 3 The template information may be extracted from the determined template data block.
[0084] In some embodiments, the identified domain of the user request may include a set of subdomains. Each subdomain in the subdomain set may have a different template for an electronic document. For example, the education domain may have different subdomains, such as secondary school certificates, diplomas, and graduation certificates. The template for a secondary school document may differ from the template for a graduation document. Therefore, in such an embodiment, the data management system 102 may determine a subdomain from the domain set based on the received user request, and further determine a subdomain ID associated with the template information for the electronic document based on the determined subdomain. The data management system 102 may further extract the template information from the distributed ledger 110 based on the determined subdomain ID. In this case, the template data block may also include the subdomain ID. For example, the subdomain ID may be passed as input to one or more selected smart contracts. These smart contracts may use the subdomain ID to search for a template data block on the distributed ledger 110. Thereafter, the template information may be extracted from the template data block that may store the template information associated with the identified subdomain.
[0085] At 418 , the distributed ledger 110 may transmit the template information extracted from the template data block to the data management system 102 .
[0086] At 420, the data management system 102 may generate an electronic file based on the extracted user-specific information and the extracted template information. For example, the data management system 102 may create an electronic document (e.g., in a portable document format (PDF)) using the extracted user-specific information and the extracted template information from a set of electronic file templates belonging to the identified domain, and populate the electronic document using the extracted user-specific information and the template information to generate the electronic file. When populating the electronic document, the data management system 102 may follow the presentation style (e.g., font, color, margin, and layout) of the electronic file template.
[0087] exist Figure 4 , an exemplary electronic file 424 is shown here. For example, the exemplary electronic file 424 may be a graduation document and may include template information 424A, such as the name of the institution / university, a statement of thanks, a watermark, and a signature authorized to sign. The template information 424A may also include presentation style information, which may control how the template information 424A and the user-specific information 424B may be incorporated into the exemplary electronic file 424. Examples of presentation style information may include, but are not limited to, font size, text / image orientation, text / image transparency, color, and text / image position. The user-specific information 424B of the exemplary electronic file 424 may include, for example, a user name, subject or major, course discipline, grades or scores obtained by the user 118, and the like.
[0088] In one embodiment, the data management system 102 may be configured to digitally sign the generated electronic file using the hash stored in the user data block. For example, the data management system 102 may use a hash value corresponding to the hash value stored in the user data block (e.g., Figure 3 The electronic file 424 is digitally signed by a hash 424C of the first user data block (“Hash #1”) Block_1 326B as shown.
[0089] At 422, the client 108 may retrieve the electronic file. Alternatively, the data management system 102 may share the electronic file with the client 108 as a readable document in a specific document format. Examples of specific document formats may include, but are not limited to, a PDF document, a postscript document, an image document, a web page, or a text document.
[0090] The electronic file shared with the client 108 can be digitally signed using the hash value associated with the user data block. In one embodiment, the data management system 102 can display an option on the client 108 to the user 118 for verifying the electronic file based on the hash value. Thereafter, the data management system 102 can receive user input through the client 108 selecting the displayed option. Based on the received user input indicating the selection of the displayed option, the data management system 102 can output the hash stored in the user data block of the client 108. The user device 104 can verify the electronic file based on a comparison of the hash value output from the data management system 102 and the hash associated with the electronic file.
[0091] Figure 5 FIG. 1 is a sequence diagram illustrating domain configuration based on user request according to an embodiment of the present disclosure. Figure 1 、 Figure 2 、 Figure 3 and Figure 4 To illustrate the elements Figure 5 . refer to Figure 5 , here is shown an example of a method for performing domain configuration based on a user request to generate an electronic file (in Figure 4 408 of the embodiment of the present invention). The sequence of operations may be from 502 to 512 and may be performed by various elements of the network environment 100, such as the client 108, the data management system 102, and the distributed ledger 110. Initially, the user 118 may provide user input through the client 108, which may be shared with the data management system 102 as a user request. The user input may be provided through certain fields or options displayed on the client 108. For example, such fields may allow the user 118 to select a domain or subdomain before submitting the user request. The user request may include a user ID, an indication of such fields, and the values entered by the user 118 through such fields. For example, the user request may be an electronic document associated with a particular domain and / or subdomain. The user 118 may enter a value indicating the domain and / or subdomain in one or more fields.
[0092] At 502, the data management system 102 may analyze the received user request using a machine learning model. For example, the user request may be analyzed by a cognitive engine of the data management system 102 based on a machine learning model and / or a natural language processing (NLP) model. In one embodiment, the machine learning model may be applied to information such as a user ID, an indication of a field, and a value entered by the user 118 through the field to analyze the received user request. Examples of machine learning models may include, but are not limited to, a linear regression model, a logistic regression model, a decision tree model, a SVM model, a naive Bayes model, an ANN model, a DNN model, a k-NN model, a k-Means model, or a random forest model.
[0093] At 504, the data management system 102 may identify a domain and / or subdomain associated with the user request based on the user ID and analysis of the user request (as described at 502). Examples of domains may include, but are not limited to, an education domain, a medical / healthcare domain, or a retail domain. Examples of subdomains may include, but are not limited to, a high school certificate or graduation for an education domain; a medical prescription or lab report for a medical / healthcare domain; and an invoice or purchase order for a retail domain.
[0094] For example, if the user request is for graduation documents, the user 118 may provide detailed information such as user name, document type (e.g., transcript), university name, and course name / subject. These user-provided details may be included in the user request. Based on analyzing these details in the user request, the data management system 102 may identify the domain of the user request as education and the subdomain as graduation.
[0095] At 506, the data management system 102 can transmit a request to the distributed ledger 110 to retrieve the domain-specific information. At 504, the request for domain-specific information can be transmitted based on the identification of the domain and / or sub-domain.
[0096] At 508, the distributed ledger 110 may transmit domain-specific information associated with the identified domain and / or subdomain to the data management system 102. The domain-specific information may include an indication of the domain and / or subdomain, and an identifier of the domain and / or subdomain (e.g., a domain ID for the identified domain and / or a subdomain ID for the identified subdomain). The identifiers of the domain and / or subdomain may correspond to a hash of the indication of the domain and / or subdomain, respectively. Additionally or alternatively, the domain-specific information may include an authorization configuration list associated with the user 118. The authorization configuration list may correspond to an authorization list for a smart contract for the domain and / or subdomain associated with the user request.
[0097] At 510, the data management system 102 can select one or more smart contracts from an authorized list of smart contracts specified in the domain-specific information (also referred to as the smart contract group 116). This selection can also be based on a determination that the received user request is authenticated. For example, the data management system 102 can use the domain ID and / or subdomain ID (determined at 508) to search for one or more smart contracts in the authorized list.
[0098] At 512, the data management system 102 may share the domain configuration confirmation with the client 108. Once the domain configuration confirmation is shared, the identified domains and / or subdomains may be determined to be configured for the user request. Figure 4The operations 410 to 422 may provide the user 118 with the electronic file requested by the user 118 through the user request.
[0099] Figure 6 This is an example of an embodiment according to the present disclosure. Figure 2 A sequence diagram of an exemplary implementation of a data management system in FIG. Figure 1 、 Figure 2 、 Figure 3 、 Figure 4 and Figure 5 To illustrate the elements Figure 6 . refer to Figure 6 , an example is shown here Figure 2 6. Sequence diagram 600 of an exemplary implementation of the data management system 102 in FIG. The sequence of operations may be from 608 to 626 and may be performed by various elements such as the data management system 102, the electronic device 602, the provider system 604, and the file authorizer system 606.
[0100] The electronic device 602 may correspond to the user device 104 and may include a client associated with the electronic device 602 ( Figure 6 ). Similarly, provider system 604 may correspond to an application server of a provider, which may host at least one web application to allow a user to request products or services offered by a provider (e.g., a university) based on the user's electronic file (e.g., an educational certificate). File authorizer system 606 may correspond to authorizer device 106, which may be configured to authenticate the user's electronic file.
[0101] At 608, the electronic device 602 may transmit a request to the provider system 604 via the client for a product or service offered by the provider system 604. The client may access a web application that allows the user to request a product or service. For example, the product or service may correspond to a health insurance product offered by an insurance company or a banking company.
[0102] At 610, the provider system 604 may transmit the user's request for relevant electronic files to the electronic device 602. For example, where the product or service is a health insurance product, the provider system 604 may request electronic files associated with the user's medical reports.
[0103] At 612, the electronic device 602 may transmit a user request for retrieving an electronic file with a user ID to the data management system 102 (in a manner similar to Figure 4 Based on the transmitted user request, Figure 4 The operations from 402 to 422 are performed as described in .
[0104] At 614, the data management system 102 may be configured to perform a Figure 4 The electronic file is shared with the electronic device 602 in the manner described in .
[0105] At 616, the electronic device 602 may transmit the user's electronic file to the provider system 604. Alternatively, instead of the operations 610, 612, 614, and 616, the following operations from 618 to 620 may be performed to obtain the electronic file.
[0106] At 618, the provider system 604 can transmit a request for an electronic file directly to the data management system 102. In this case, the provider system 604 can receive the user ID of the user and the request for a product or service from the electronic device 602. The request for an electronic file can include the user ID.
[0107] At 620 , the data management system 102 may share the user's electronic file with the provider system 604 .
[0108] At 622, the provider system 604 may transmit a request to verify the electronic file to the file authority system 606. Such a request to verify may include the electronic file, which may be digitally signed using a hash value.
[0109] The file authority system 606 may extract the hash value from the electronic file and request the data management system 102 to share the hash associated with the user data block of the user on the distributed ledger 110. Based on the request, the file authority system 606 may receive the requested hash associated with the user data block and may compare the hash from the electronic file to the requested hash to verify the electronic file.
[0110] At 624, the file authority system 606 can transmit a verification confirmation based on the verification of the electronic file to the provider system 604. As such, the verification confirmation can be transmitted when the hash value from the electronic file matches the hash value of the output stored on the user data block associated with the user.
[0111] At 626, the provider system 604 may transmit a validation response based on the validation confirmation to the electronic device 602. If the validation confirmation indicates that the electronic file is valid, the validation response may correspond to validation of the user's request to accept the provider's offer of the product / service to the user.
[0112] Figure 7 is a flowchart illustrating an exemplary method for generating an electronic file based on a distributed ledger according to an embodiment of the present disclosure. Figure 1 、 Figure 2 、 Figure 3 、 Figure 4 、 Figure 5 and Figure 6 To illustrate the elements Figure 7 . refer to Figure 7 , a flowchart 700 is shown herein. The exemplary method of flowchart 700 may be performed by any computing system (e.g., by Figure 2 The exemplary method of flowchart 700 may begin at 702 and proceed to 704.
[0113] At 704, a user request for an electronic file can be received. In one or more embodiments, data management system 102 can be configured to receive a user request for an electronic file from client 108 of user device 104. The user request can include a user ID of user 118.
[0114] At 706, the domain associated with the received user request may be identified. In one or more embodiments, the data management system 102 may be configured to identify the domain associated with the received user request based on the user ID. For example, Figure 5 , further illustrating the identification of a domain associated with a received user request.
[0115] At 708, one or more smart contracts for the identified domain may be selected from the smart contract set 116. In one or more embodiments, the data management system 102 may be configured to select one or more smart contracts from the smart contract set 116. For example, Figure 5 The selection of one or more smart contracts is further described in [1].
[0116] At 710, user-specific information for the electronic file may be extracted from the file information stored on the distributed ledger 110. In one or more embodiments, the data management system 102 may be configured to extract user-specific information for the electronic file from the text information stored on the distributed ledger 110 based on the user ID and the selected one or more smart contracts. In one embodiment, the data management system 102 may use the user ID as input to execute one or more smart contracts to determine a user data block associated with the identified domain from the distributed ledger 110. Thereafter, the data management system 102 may extract the user-specific information from the determined user data block on the distributed ledger 110. For example, Figure 4 The extraction of user-specific information is further explained in .
[0117] At 712, a content ID associated with the template information for the electronic file may be determined. In one or more embodiments, the data management system 102 may be configured to determine the content ID associated with the template information for the electronic file. In one embodiment, the data management system 102 may input a query for the content ID to the distributed ledger 110 and determine the content ID based on a received response to the query. For example, Figure 4 The determination of the content ID is further explained in FIG.
[0118] At 714, template information for the stored file information may be determined. In one or more embodiments, the data management system 102 may be configured to determine template information from the distributed ledger 110 based on the determined content ID and the selected one or more smart contracts. In one embodiment, the data management system 102 may input the content ID into the selected one or more smart contracts and determine a template data block associated with the identified domain from the distributed ledger 110 based on the response to the selected one or more smart contracts. Thereafter, the circuit system 202 may extract the template information from the determined template data block. For example, in Figure 4 The determination of template information is further explained in FIG.
[0119] At 716, an electronic file may be generated. In one or more embodiments, the data management system 102 may be configured to generate an electronic file based on the extracted user-specific information and the extracted template information. In one embodiment, the generated electronic file may be digitally signed using a hash value corresponding to the hash of the user data block. The data management system 102 may then share the digitally signed electronic file with the client 108 of the user device 104. For example, Figure 4 The generation of electronic files and examples of electronic files are further described in
[0066] ,
[0067] ,
[0068] ,
[0069] ,
[0070] ,
[0071] ,
[0072] ,
[0073] ,
[0074] ,
[0075] ,
[0076] ,
[0077] ,
[0078] ,
[0079] ,
[0080] ,
[0081] , [
[0120] Various embodiments of the present disclosure may provide a non-transitory computer-readable medium and / or storage medium, and / or a non-transitory machine-readable medium and / or storage medium, storing instructions executable by a machine and / or computer (such as a data management system) for generating an electronic file based on a distributed ledger. At least one code portion may cause the machine and / or computer to perform operations including receiving a user request for an electronic file. The user request may include a user ID. The data management system may be communicatively coupled to a distributed ledger that stores file information for multiple users and a set of smart contracts that control access to the stored file information. The operations may also include identifying a domain associated with the received user request. The operations may also include selecting at least one smart contract from the set of smart contracts for the identified domain. Furthermore, the operations may include extracting user-specific information for the electronic file from the stored file information based on the user ID and the selected at least one smart contract. Furthermore, the operations may include determining a content ID associated with template information for the electronic file based on the determined content ID and the selected at least one smart contract, and extracting the template information from the stored file information. The operations may also include generating the electronic file based on the extracted user-specific information and the extracted template information.
[0121] Example aspects of the present disclosure may include a data management system 102 comprising circuitry 202 communicatively coupled to a distributed ledger 110 that stores file information for multiple users and a set of smart contracts 116 that controls access to the stored file information. Circuitry 202 may be configured to receive a user request for an electronic file. The user request may include a user ID. Circuitry 202 may also be configured to identify a domain associated with the received user request. Furthermore, circuitry 202 may be configured to select at least one smart contract from the set of smart contracts 116 for the identified domain. Circuitry 202 may also be configured to extract user-specific information for the electronic file from the stored file information based on the user ID and the selected at least one smart contract. Furthermore, circuitry 202 may also be configured to determine a content ID associated with template information for the electronic file and extract the template information from the stored file information based on the determined content ID and the selected at least one smart contract. Circuitry 202 may also be configured to generate an electronic file based on the extracted user-specific information and the extracted template information.
[0122] According to an embodiment, the circuit system 202 may be configured to authenticate the received user request based on the identified domain and user ID associated with the received user request. The circuit system 202 may also be configured to verify the identity of a user from among the multiple users associated with the received user request. Thereafter, the circuit system 202 may determine a set of user permissions associated with the received user request. Furthermore, the circuit system 202 may authenticate the received user request based on the verified identity and the determined set of user permissions.
[0123] According to an embodiment, the circuit system 202 may be configured to perform domain configuration on the domain and / or subdomain associated with the received user request. To perform domain configuration, the circuit system 202 may be configured to analyze the received user request using a machine learning model. Thereafter, the circuit system 202 may identify the domain associated with the received user request based on the analysis of the received user request and the user ID. Furthermore, the circuit system 202 may retrieve domain-specific information for the identified domain from the distributed ledger 110. The circuit system 202 may also be configured to select at least one smart contract based on the retrieved domain-specific information for the identified domain and a determination that the received user request is authenticated.
[0124] According to an embodiment, the distributed ledger 110 stores a plurality of blocks 114, which may include a set of template data blocks and a set of user data blocks. The set of template data blocks may correspond to a set of templates for electronic documents of one or more domains. The set of user data blocks may include personal data of multiple users of the one or more domains. In one embodiment, the extracted user-specific information and the extracted template information may belong to one of the sets of templates for electronic documents of an identified domain in the one or more domains.
[0125] According to an embodiment, the circuit system 202 may be configured to input a query for a content ID to the distributed ledger 110. The circuit system 202 may receive a response to the input query from the distributed ledger 110 and further determine the content ID of the template information based on the received response to the input query.
[0126] According to an embodiment, circuit system 202 may be configured to input the user ID into at least one smart contract. Circuit system 202 may then determine a user data block associated with the identified domain from distributed ledger 110 based on a response from the at least one smart contract. The user data block may be one of multiple blocks 114 of file information stored on distributed ledger 110. Furthermore, circuit system 202 may extract user-specific information from the user data block determined on distributed ledger 110. In one embodiment, the user data block may store a hash of the electronic file, user-specific information, and a content ID.
[0127] According to an embodiment, circuit system 202 may be configured to input the content ID into at least one smart contract. Thereafter, circuit system 202 may determine a template data block associated with the identified domain from distributed ledger 110 based on a response from the at least one smart contract. The template data block may be one of multiple blocks 114 of file information stored on distributed ledger 110. Furthermore, circuit system 202 may extract template information from the determined template data block. In one embodiment, the template data block may store a hash of the template data block, template information, content ID, domain information, and subdomain information.
[0128] According to an embodiment, the identified domain may include a set of subdomains, each subdomain having a different template for the electronic document. The circuit system 202 may also be configured to determine a subdomain from the set of subdomains associated with the identified domain based on a received user request. Thereafter, the circuit system 202 may determine a subdomain ID associated with the template information of the electronic document based on the determined subdomain. The circuit system 202 may further be configured to extract template information based on the determined subdomain ID.
[0129] According to an embodiment, the circuit system 202 may be configured to transmit the generated electronic file as a readable file to the client 108 of the user device 104. According to an embodiment, the circuit system 202 may also be configured to digitally sign the generated electronic file using the hash stored in the user data block. Thereafter, the circuit system 202 may display an option on the client 108 of the user device 104 to verify the electronic file signed using the hash stored in the user data block. The circuit system 202 may receive user input selecting the displayed option. Thereafter, the circuit system 202 may output the hash stored in the user data block on the client 108. According to an embodiment, the electronic file may be verified on the user device 104 based on a comparison of the output hash with a hash associated with the electronic file.
[0130] The present disclosure may be implemented in hardware or a combination of hardware and software. The present disclosure may be implemented in a centralized or distributed manner in at least one computer system, wherein different components may be distributed across several interconnected computer systems. A computer system or other device suitable for performing the methods described herein may be suitable. The combination of hardware and software may be a general-purpose computer system with a computer program that, when loaded and executed, can control the computer system to cause it to perform the methods described herein. The present disclosure may be implemented in hardware that includes a portion of an integrated circuit that also performs other functions.
[0131] The present disclosure may also be embedded in a computer program product comprising all the features enabling the implementation of the methods described herein and, when loaded into a computer system, being able to carry out these methods. In this context, a computer program is any expression of a set of instructions in any language, code or notation, intended to cause a system with information processing capabilities to perform certain functions either directly or after either or both of the following: a) conversion into another language, code or notation; b) reproduction in a different material form.
[0132] Although the present disclosure has been described with reference to certain embodiments, it will be understood by those skilled in the art that various changes may be made and equivalents may be substituted without departing from the scope of the present disclosure. Furthermore, many modifications may be made to adapt a particular situation or material to the teachings of the present disclosure without departing from the scope of the present disclosure. Therefore, it is intended that the present disclosure not be limited to the particular embodiments disclosed, but that the present disclosure will include all embodiments falling within the scope of the appended claims.
Claims
1. A data management system comprising: Circuitry communicatively coupled to a distributed ledger that stores file information for a plurality of users and a set of smart contracts that control access to the stored file information, wherein the circuitry is configured to: receiving a user request for an electronic file, the user request including a user identifier (ID); Analyze received user requests using machine learning models; identifying a domain associated with the received user request based on the user ID and analysis of the received user request; retrieving domain-specific information for the identified domain from the distributed ledger; determining that the domain-specific information includes an authorization list for the smart contract for the identified domain; Based on determining that the domain-specific information includes an authorization list for the smart contract for the identified domain, determining that the received user request is authorized, wherein The smart contract group corresponds to an authorization list of smart contracts; selecting at least one smart contract for the identified domain from an authorized list of smart contracts based on the domain-specific information and determining that the user request is authorized; extracting user-specific information for the electronic file from the stored file information based on the user ID and the selected at least one smart contract; determining a content ID associated with template information for the electronic document, wherein The data management system is configured to create a common template for each domain and store a single copy of the common template in the node, and The content ID corresponds to a hash key, based on which the template information can be hashed and stored in multiple blocks on a distributed ledger; extracting template information from the stored file information based on the determined content ID and the selected at least one smart contract; as well as The electronic document is generated based on the extracted user-specific information and the extracted template information. 2 . The data management system of claim 1 , wherein the circuitry is further configured to authenticate the received user request based on the identified domain and user ID associated with the received user request.
3. The data management system of claim 1 , wherein the circuit system is further configured to: verifying an identity of a user from the plurality of users associated with the received user request; determining a set of user rights associated with the received user request; and The received user request is authenticated based on the verification of identity and the determined set of user permissions.
4. The data management system of claim 1 , wherein the circuit system is further configured to: Input a query for the content ID into the distributed ledger; receiving a response to the input query from the distributed ledger; and A content ID for the template information is determined based on a received response to the input query.
5. The data management system of claim 1 , wherein the circuit system is further configured to: inputting a user ID into the at least one smart contract; determining, based on a response from the at least one smart contract, a user data block associated with the identified domain from a distributed ledger, in, The user data block is one of the multiple blocks of file information stored on the distributed ledger; as well as Extract user-specific information from the identified user data block on the distributed ledger.
6. The data management system of claim 5, wherein the user data block stores a hash, user-specific information, and a content ID for the electronic file.
7. The data management system of claim 6, wherein the circuit system is further configured to digitally sign the generated electronic file using the hash stored in the user data block.
8. The data management system of claim 7, wherein the circuit system is further configured to: displaying an option on a client of the user device to verify the electronic document signed using the hash stored in the user data block; receiving user input selecting a displayed option; and Output the hash stored in the user data block on the client, in, The electronic file is verified on the user device based on a comparison between the output hash and a hash associated with the electronic file.
9. The data management system of claim 1 , wherein the circuit system is further configured to: inputting the content ID into the at least one smart contract; determining, based on a response from the at least one smart contract, a template data block associated with the identified domain from a distributed ledger, in, The template data block is one of the multiple blocks of file information stored on the distributed ledger; as well as The template information is extracted from the determined template data block.
10. The data management system according to claim 9, wherein the template data block stores a hash of the template data block, template information, content ID, domain information, and subdomain information.
11. The data management system of claim 1 , wherein the distributed ledger stores a plurality of blocks, the plurality of blocks comprising a set of template data blocks and a set of user data blocks, wherein: The set of template data blocks corresponds to a set of templates of the electronic document for one or more domains, The set of user data chunks contains personal data of the plurality of users for the one or more domains, and The extracted user-specific information and the extracted template information belong to one of a set of templates for the electronic document for the identified domain of the one or more domains.
12. The data management system according to claim 1, wherein The identified domain includes a set of subdomains, and Each subdomain in the subdomain set has a different template for electronic documents.
13. The data management system of claim 12, wherein the circuit system is further configured to: determining, based on the received user request, a subdomain from the set of subdomains associated with the identified domain; determining a subdomain ID associated with template information for the electronic document based on the determined subdomain; and Template information is also extracted based on the determined subdomain ID.
14. The data management system of claim 1, wherein the circuit system is further configured to transmit the generated electronic file as a readable document to a client of a user device.
15. A method for a data management system, comprising: In a data management system communicatively coupled to a distributed ledger, the distributed ledger storing file information for a plurality of users and a set of smart contracts controlling access to the stored file information: receiving a user request for an electronic file, the user request including a user identifier (ID); Analyze received user requests through machine learning models; identifying a domain associated with the received user request based on the user ID and analysis of the received user request; retrieving domain-specific information for the identified domain from the distributed ledger; determining that the domain-specific information includes an authorization list for the smart contract for the identified domain; Based on determining that the domain-specific information includes an authorization list for the smart contract for the identified domain, determining that the received user request is authorized, wherein The smart contract group corresponds to an authorization list of smart contracts; selecting at least one smart contract for the identified domain from an authorized list of smart contracts based on the domain-specific information and determining that the user request is authorized; extracting user-specific information for the electronic file from the stored file information based on the user ID and the selected at least one smart contract; determining a content ID associated with template information for the electronic document, wherein The data management system is configured to create a common template for each domain and store a single copy of the common template in the node, and The content ID corresponds to a hash key, based on which the template information can be hashed and stored in multiple blocks on a distributed ledger; extracting template information from the stored file information based on the determined content ID and the selected at least one smart contract; as well as The electronic document is generated based on the extracted user-specific information and the extracted template information.
16. The method according to claim 15, further comprising: inputting a user ID into the at least one smart contract; determining, based on a response from the at least one smart contract, a user data block associated with the identified domain from a distributed ledger, wherein the user data block is one of the multiple blocks of file information stored on the distributed ledger; as well as Extract user-specific information from the identified user data block on the distributed ledger.
17. The method of claim 16, wherein the user data block stores a hash for the electronic file, user-specific information, and a content ID.
18. The method of claim 17, further comprising digitally signing the generated electronic file using a hash stored in a user data block.
19. The method according to claim 15, further comprising: inputting the content ID into the at least one smart contract; determining, based on a response from the at least one smart contract, a template data block associated with the identified domain from a distributed ledger, The template data block is one of the multiple blocks of file information stored on the distributed ledger; as well as The template information is extracted from the determined template data block.
20. The method of claim 16, wherein The user-specific information is extracted from the same user data block from which the distributed ledger retrieved the content ID.