Ledger-less blockchain systems and methods for data management

Abstract

Ledger-less blockchain systems for data management and tokenization comprising: a Data Token Generation Module (DTGM) to capture data that is to be tokenized into a data token (TKN), for a given data token (TKN) used by this invention, only one transaction per block being allowed, said generated token (TKN) being Source of Truth; a verification module (VFM) to, authentically, verify data (101) that is to be tokenized, before generating a correlative data token (TKN); a Data Token Verification Module (DTVM) to allow a second user with a user-correlative non-fungible token (NFT), to verify said user-correlative non-fungible token (NFT), said Data Token Verification Module (DTVM) comprising: an app-adapter system that queues user requests and transactions, in an asynchronous-await module, allowing said system to process only one request at a time and create or read one block per transaction; and enabling handshake between said Proof of Truth and said Source of Truth.

Description

[0001] LEDGER-LESS BLOCKCHAIN SYSTEMS AND METHODS FOR DATA MANAGEMENT

[0002] FIELD OF THE INVENTION:

[0003] The invention relates to the field of computer networks, particularly, using distributed ledgers and blockchain mechanisms.

[0004] Particularly, this invention relates to ledger-less blockchain systems and methods for tokenization.

[0005] BACKGROUND OF THE INVENTION:

[0006] A blockchain is a distributed database or ledger shared among a computer network's nodes. Blockchain is a type of shared database that differs from a typical database in the way it stores information; blockchains store data in blocks linked together via cryptography.

[0007] Different types of information can be stored on a blockchain, but the most common use for transactions has been as a ledger. The same can be used for identity management and tokenization; since, each identity is unique.

[0008] Decentralized or centralized blockchains are immutable, which means that the data entered is irreversible. Because there is no way to change a block, the only trust needed is at the point where a user or program enters data. This aspect reduces the need for trusted third parties.

[0009] There is a need for improving, and enhancing, systems and methods that manage tokenization in the current digital age and virtual worlds. In prior arts, such management of identities rely on centralized databases and conventional authentication mechanisms.

[0010] For the purposes of this invention, the term ‘identity’ is used to mean, and include, identity-associated data items, identity-associated documents, identity-associated files, identity-associated markers, identity-associated biomarkers, and the like.

[0011] In prior approaches, the management and protection of sensitive data rely heavily on centralized systems and traditional encryption methods.

[0012] For the purposes of this invention, the term ‘tokenization’ is used to mean, and include, the process of converting sensitive data, such as personally identifiable information (PII), financial details, medical records, and the like, into non-sensitive tokens, wherein these tokens retain no exploitable value outside the system, while maintaining the ability to map back to the original data when necessary. This also extends to the tokenization of physical assets, such as real estate, commodities, artwork, and other tangible assets, transforming them into digital tokens that can be securely exchanged, tracked, or stored in a decentralized manner, enabling fractional ownership, streamlined transactions, and enhanced liquidity.

[0013] FIGURE 1 illustrates a prior art block chain system.

[0014] In these prior art systems, users (101) contribute data items to a blockchain system (102). Here, transactions concerning the data items are bundled into a single block of data and a hash function data item is generated from that block. Each subsequent block (Block 1, Block 2, Block 3) stores transaction-related data items along previous block’s hash function data item and generates a new hash function data item with that specific block’s transaction-related data and the previous hash function data item. Thus, each subsequent block has a new hash function data item which is a function of transaction-related data items resident on that particular block along with previous block’ s hash function data item.

[0015] In such prior art systems, the number of transactions, at any given moment, is bundled into a single block; meaning, each block has multiple transactions in them. In FIGURE 1, transactions refer to actions committed by users (101). In other words, in prior art blockchain mechanisms, the system picks up total number of transactions, in a particular moment, and adds them to a block.

[0016] In this prior art method of managing and storing transactions, , transactions are not inherently linked to specific users, requiring a ledger or an additional mechanism to associate each transaction with the appropriate user for proper tracking and management.

[0017] Additionally, these prior art systems and methods use prior art blockchain structures that are primarily designed for cryptocurrency transactions and are not suited for identity management. Storing identity information directly on the blockchain would compromise security, as a ledger containing all required information could potentially expose sensitive identity data to hackers, defeating the purpose of secure identity management..

[0018] Therefore, there is a need to do away with a ledger. Thus, considering all these drawbacks or prior arts, there is a need for an improved ledger-less blockchain mechanism.

[0019] Additionally, prior art tokenization models and blockchain systems are primarily focused on decentralization through node-based consensus models, such as Proof of Work (PoW) or Proof of Stake (PoS), which often come with challenges like high energy consumption, slow transaction times, and security vulnerabilities related to network attacks and data corruption.

[0020] In sum,

[0021] 1. Centralized Vulnerability: Prior art identity management and tokenization systems store personal data in centralized databases, making them susceptible to data breaches and unauthorized access.

[0022] 2. Lack of Privacy Control: Prior art systems often grant third parties access to personal data without user consent, leading to privacy concerns and potential misuse.

[0023] 3. Inadequate Authentication: Prior art authentication methods can be circumvented, leading to identity fraud and security breaches.

[0024] 4. Limited User Autonomy: In prior art systems, users have limited control over their personal data and lack the ability to manage and share it securely as needed.

[0025] 5. Lack of Self-Sovereignty: In prior art systems, users are reliant on centralized authorities for identity verification, leading to potential dependence and reduced control.

[0026] 6. Fragmented Identity Solutions: In prior art systems, absence of a unified approach to identity management leads to confusion, inefficiencies, and complications during authentication processes. Slow and Inefficient Consensus Mechanisms: Prior art blockchains rely on consensus models like Proof of Work (PoW) or Proof of Stake (PoS), which are slow and resource-intensive. Security Vulnerabilities in Blockchain: Traditional blockchain systems and their consensus mechanisms are vulnerable to several security threats, including 51% attacks, where an attacker gains majority control of the network’ s computational power or stake. They are also susceptible to Sybil attacks, in which multiple fake nodes can disrupt consensus, and long-range attacks, where outdated validator keys in proof-of-stake systems can compromise the network. Additionally, selfish mining, front-running, and transaction reordering allow miners or validators to manipulate the system for personal gain. Consensus delays and network forking further weaken reliability, while validator collusion can undermine decentralization in PoS systems. Smart contract vulnerabilities, energy inefficiencies in proof-of- work models, and blockchain bloat also pose significant challenges to network security and scalability.. High Energy Consumption: Prior art blockchain systems, using PoW, require significant energy, contributing to environmental concerns. Lack of Real-Time Data Integrity Monitoring: Prior art blockchain systems face challenges in continuously monitoring and ensuring data integrity after block creation. Complex and Costly Implementation: Prior art blockchain platforms are complex and expensive to integrate. Inadequate Flexibility for Compliance and Regulatory Demands: Prior art blockchain solutions find it challenging to meet strict regulatory requirements in industries like healthcare. Therefore, there is a need for a solution for the aforementioned problems.

[0027] OBJECTS OF THE INVENTION:

[0028] An object of the invention is to improve and enhance systems and methods for securely managing and tokenizing sensitive data and physical assets in the current digital age, ensuring greater privacy, security, and efficiency in both digital and real- world transactions.

[0029] Another object of the invention is to provide systems and methods for data management, offering enhanced security, privacy, and user control

[0030] Yet another object of the invention is to provide systems and methods for data management, which systems and methods are more secure, decentralized, and usercentric.

[0031] SUMMARY OF THE INVENTION:

[0032] According to this invention, there is provided a ledger-less blockchain systems for data management and tokenization, said system comprising:

[0033] - a Data Token Generation Module configured to capture data that is to be tokenized in order to configure said data into a data token correlative to the captured data, in that, for a given data token used by this invention, only one transaction per block being allowed, said generated token being Source of Truth; o said Data Token Generation Module configured with a first encryption module to encrypt, using pre-defined encryption algorithms, each first user’s data token, in order to obtain correlative encrypted data per first user, and to store, said encrypted data, in a “single block” of said system, each block having a unique block-identity correlative to the data token, said first encryption module being configured to validate all incoming requests and forming a first protective layer for said system; o said Data Token Generation Module configured with a second encryption module to encrypt, using pre-defined encryption algorithms, said correlative encrypted data in order to obtain a user-correlative non-fungible token being provided to said first user requesting generation of said data token;

[0034] - a verification module configured to, authentically, verify data that is to be tokenized, before generating a correlative data token, in order to conform to it being said Source of Truth;

[0035] - a Data Token Verification Module configured to allow a second user with a user-correlative non-fungible token, to verify said user-correlative non-fungible token, said Data Token Verification Module comprising: o a decryption module configured to, in a first instance, retrieve data corresponding to said second user’s submitted token and configured to, in a second instance, decrypt the retrieved data in order to obtain data from its corresponding user-correlative data token, said decrypted retrieved data being Proof of Truth;

[0036] - an app-adapter system that queues user requests and transactions, from said Data Token Generation Module and from said Data Token Verification Module, in an asynchronous-await module, allowing said system to process only one request at a time and create or read one block per transaction; and

[0037] - a trigger-based smart contract module configured to issue triggers, for said first user, to act upon, in order to: o enable a smart contract between said first user and said system in relation to said stored data token upon successful verification by said verification module in response to request from said Data Token Verification Module, o display data to said second user, in response to submission and verification of said user-correlative non-fungible token based on privacy settings enabled by said first user basis said smart contract;

[0038] - thereby enabling handshake between said Proof of Truth and said Source of Truth before displaying data, or portion thereof, of said first user to said second user.

[0039] In at least an embodiment, said app-adapter system being configured to receive and process transactions asynchronously via a public API endpoint, said app-adapter system being managing tokenization requests and interacting with said blockchain system to initiate the validation and tokenization process.

[0040] In at least an embodiment, said app-adapter system being configured to engage after receiving a tokenization request, from said first user, from the app-adapter system, the system sends the request asynchronously to the Source of Truth in order to validate the request and issues a unique Digital Signature as a form of proof, confirming the transaction's validity to form Proof of Truth, said Proof of Truth being transmitted back to said ledgerless blockchain for inclusion in corresponding transaction block, said transmission done using asynchronous / await modules, with built-in queuing logic, in order to allow non-blocking execution. In at least an embodiment, said app-adapter system configured to send user information and data to Source of Truth for validation and upon confirmation, a unique Digital signature and validation evidence being transmitted to said system’ s ledgerless blockchain as Proof of Truth, said transmission done using asynchronous / await modules, with built-in queuing logic, in order to allow nonblocking execution..

[0041] In at least an embodiment, said Data Token Generation Module comprising an input module configured with at least a capturing module configured to capture data that is to be tokenized, in that, said input module being configured with a token generation module configured to generate a data token correlative to the captured data through said capturing module.

[0042] In at least an embodiment, the token generation module is configured such that, for a given data token used by this invention, only one transaction per block is allowed.

[0043] In at least an embodiment, said data tokens being user-correlative data tokens that employ double encryption mechanisms.

[0044] In at least an embodiment:

[0045] - said Identity Token Generation Module further comprises a mining engine programmed to process one request or transaction at a time, generating a new block for each transaction, thus prohibiting multiple transactions from being bundled into a single block.

[0046] In at least an embodiment said first encryption module creates a block identity correlated to the user’ s encrypted data token, which functions as an identity for each block.

[0047] In at least an embodiment

[0048] - said second encryption module that encrypts the encrypted data to generate a user-correlative non-fungible token, which is provided to the user for future verification.

[0049] In at least an embodiment, said Data Token Verification Module comprising:

[0050] - a service request module configured to allow a second user, with a usercorrelative non-fungible token, to input their own user-correlative non- fungible token; and

[0051] - a communicably coupled non-fungible token verification module configured to relay said second user’ s submitted token to said system.

[0052] In at least an embodiment, said Data Token Verification Module being communicably coupled to a display module configured to check said first user’s pre-defmed privacy settings, and correlative to these privacy settings, data, per submitted token, is displayed, through said display module to the extent of settings determined by said privacy settings.

[0053] According to this invention, there is provided a ledger-less blockchain methods for data management and tokenization, said method comprising the steps of:

[0054] - receiving a tokenization request, from a first user, concerning data, via a capturing module;

[0055] - capturing said data to be tokenized; - storing said data, in a blockchain, such that there is only one transaction per block of said blockchain;

[0056] - generating a user-correlative data token through a token generation module, using a first encryption module and a second encryption module, for encrypting said captured data, said generated token being Source of Truth;

[0057] - storing the encrypted data in a single block of the blockchain system, wherein each block contains only one transaction;

[0058] - validating said request using an external Proof of Truth system by a verification module configured to, authentically, verify data that is to be tokenized, before generating a correlative data token, in order to conform to it being said Source of Truth;

[0059] - decrypting said encrypted data, per block, based on request from a Data Token Verification Module, said decryption to, in a first instance, retrieving data corresponding to said second user’s submitted token and configured to, in a second instance, decrypting the retrieved data in order to obtain data from its corresponding user-correlative data token, from a block of said blockchain, said decrypted retrieved data being Proof of Truth;

[0060] - creating a blockchain block for the validated transaction, wherein the block is stored in a virtual memory and linked via cryptographic hashes;

[0061] - engaging asynchronously, via an app-adapter system configured with an asynchronous-await module;

[0062] - queuing user transactions using said asynchronous-await module, wherein each transaction is processed sequentially by the system's engine, and a new block, with decrypted data, is created for each transaction after traversing existing blocks to verify uniqueness and integrity;

[0063] - enabling a smart contract between said first user and said system in relation to said stored data token upon successful verification by said verification module in response to request from said Data Token Verification Module; and

[0064] - displaying data to said second user, in response to submission and verification of said user-correlative non-fungible token based on privacy settings enabled by said first user basis said smart contract; thereby enabling handshake between said Proof of Truth and said Source of Truth before displaying data, or portion thereof, of said first user to said second user.

[0065] In at least an embodiment, wherein said method processes one transaction per block in a synchronous manner.

[0066] In at least an embodiment, wherein a method for generating a token, comprising:

[0067] - hashing a blockchain block using the encryption mechanisms;

[0068] - encrypting the block's hash using encryption mechanisms; and

[0069] - issuing the encrypted hash as the token.

[0070] In at least an embodiment,

[0071] - issuing a smart contract via a smart contract module upon successful verification of the user’ s identity, enabling transactions related to the user-correlative identity token.

[0072] In at least an embodiment, generating a user-correlative non-fungible token by encrypting the encrypted identity using a second encryption module, wherein the NFT is provided to the first user for future identity validation.

[0073] According to this invention, there is provided a method for validating an identity token in a ledger-less blockchain system, comprising the steps of:

[0074] - receiving a user-correlative non-fungible token through a service request module;

[0075] - decrypting the NFT via a decryption module to retrieve identity data stored in the corresponding block; and a. displaying the decrypted identity data according to the user's predefined privacy settings via a display module.

[0076] In at least an embodiment, said step of verification, being configured to:

[0077] - receive a user-correlative non-fungible token submitted by said second user;

[0078] - decrypt the token via a decryption module to obtain identity data stored in a corresponding block of the blockchain system; and

[0079] - traverse blocks of the system to retrieve and verify the decrypted identity data.

[0080] In at least an embodiment, each block’s hash identity being transmitted to said app- adapter system, in that, said app-adapter system being configured to encrypt said hash identity per block to generate said token with its encryption key being maintained by said app-adapter system and configured to be transmitted to said first user upon generation of said token. BRIEF DESCRIPTION OF THE ACCOMPANYING DRAWINGS:

[0081] FIGURE 1 illustrates a prior art block chain system.

[0082] The invention will now be described in relation to the accompanying drawings, in which:

[0083] FIGURE 2 illustrates a schematic block diagram of how the current invention’s system and method works;

[0084] FIGURE 3 illustrates a schematic flow diagram of how the current invention’s system and method works;

[0085] FIGURE 4 illustrates how the system and method, of this invention, processes one transaction at a time and creates one block per transaction in accordance with this invention;

[0086] FIGURE 5 illustrates how an app-adapter system feeds the engine of this invention; and

[0087] FIGURE 6 illustrates how a block is formed using proof of truth and source of truth.

[0088] DETAILED DESCRIPTION OF THE ACCOMPANYING DRAWINGS:

[0089] According to this invention, there are provided ledger-less blockchain systems and methods for identity management and tokenization. Due to the system and method, of this invention, by avoiding a ledger which is generally used for identifying and linking any token with its user, the system and method, of this invention, prohibits ability to track owner of a token as the system itself is used to provide an identity token and to secure sensitive data, physical assets in digital form. FIGURE 2 illustrates a schematic block diagram of how the current invention’s system and method works.

[0090] FIGURE 3 illustrates a schematic flow diagram of how the current invention’s system and method works.

[0091] In at least an embodiment, the system and method, of this invention is configured with at least two modules:

[0092] 1) Data Token Generation Module (DTGM);

[0093] 2) Data Token Verification Module (DTVM).

[0094] In at least an embodiment of the Data Token Generation Module (DTGM), an input module (IPM) is configured with at least a capturing module (CPM) configured to capture data (e.g. an identity of users) (101) using this system and method. Further, the input module (IPM) is configured with at least a token generation module (TGM) configured to generate a data token (TKN) correlative to the captured data (this data, in some embodiments, could be captured identity of users) (101) through the capturing module (CPM). The token generation module (TGM) is configured such that, for a given token (TKN) used by this invention, only one transaction per block is allowed. These tokens (TKN) are user-correlative data tokens that employ double encryption mechanisms to ensure highest level of security and privacy in data management within a ledgerless blockchain system. Double encryption is configured in a two-stage manner.

[0095] The following shows an exemplary embodiment as to how Encryption and Block creation takes place using this invention:

[0096] CreateNewBlock var block = new Block {

[0097] Index = _chain. Count,

[0098] Timestamp = DateTime.UtcNow,

[0099] Transactions = _currentTransactions.ToList(),

[0100] Proof = proof,

[0101] PreviousHash = previousHash ?? GetHash(_chain.Last())

[0102] }; computing the SHA-256 hash

[0103] SH A256Managed :

[0104] • var sha256 = new SHA256Managed();

[0105] • This initializes a new instance of the SHA256Managed class, which provides the implementation for computing a SHA-256 cryptographic hash.

[0106] StringBuilder:

[0107] • var hashBuilder = new StringBuilderQ;

[0108] • A StringBuilder object is created, which will be used to efficiently build the resulting hexadecimal string representation of the hash.

[0109] Encoding the Data:

[0110] • byte[] bytes = Encoding.Unicode.GetBytes(data);

[0111] • The input data (which is assumed to be a string) is encoded into a byte array using Unicode encoding.

[0112] Computing the Hash:

[0113] • byte[] hash = sha256.ComputeHash(bytes);

[0114] • The ComputeHash method is called on the sha256 object to compute the hash of the bytes array. The result is a 32-byte array (hash) that represents the SHA-256 hash. Building the Hexadecimal String:

[0115] • foreach (byte x in hash) hashBuilder.Append($"{x:x2}");

[0116] • The foreach loop iterates over each byte in the hash array, converting each byte into its hexadecimal representation using the string interpolation "{x:x2}". This ensures that each byte is formatted as a two-character hexadecimal string, with leading zeros if necessary.

[0117] • The formatted hexadecimal string is appended to the hashBuilder.

[0118] Returning the Final Hash String:

[0119] • return hashBuilder.ToString();

[0120] • The complete hexadecimal string representation of the hash is returned as the final output.

[0121] As shown above SHA256 Encryption model is used for Block Hashing.

[0122] Typically, the input module (IPM) with the token generation module (TGM) is the Source of Truth. The Source of Truth is an external system responsible for validating tokenization requests. The system confirms the ownership or authorization of the user to tokenize the submitted data. Based on the nature of the tokenized asset (e.g., identity, property, commodity), the Source of Truth ensures the user holds valid credentials or authorizations. The data is subjected to validation along with all other transactions that happened at that instantaneous moment via an automated consensus mechanism called Source of Truth.

[0123] Typically, Source of Truth is a source system which can validate user’s request to Tokenize Data vide its token generation module (TGM). Source of Truth confirms that the data sent for Tokenization belongs to the user (in case of Identity Tokenization) or the user is Authorized to Tokenize (in case of Property or Commodity Tokenization) or the user holds valid certifications (in case of Diploma or Degree Tokenization) and so on.

[0124] In at least an embodiment of the Data Token Generation Module (DTGM), the token generation module (TGM) is configured with a verification module (VFM) configured to, authentically, verify data (101) accessing the input module (IPM). This is done at source of truth or source of origin of data submitted by a user. Upon successful verification, by the verification module (VFM), a usercorrelative data token (TKN) is generated by the token generation module (TGM). According to non-limiting exemplary embodiment, data is validated by means of MFA authentication on government systems or any other source systems and identity document is retrieved from government systems or source systems or any other known authentication system. This ensures that correct data is associated with correct user-correlative data token (TKN).

[0125] In at least an embodiment of the Data Token Generation Module (DTGM), a trigger-based smart contract module (SCM) is configured to issue triggers, for a user, to act upon, in order to enable a smart contract between the user and the system in relation to user-correlative data token (TKN) stored, and used, by this system and method. This is done upon successful verification by verification module (VFM). Smart contracts and their configuration and deployment are known in the art.

[0126] In at least an embodiment of the Data Token Generation Module (DTGM), a first encryption module (ECPI) is configured to encrypt, using pre-defmed encryption algorithms, each user’s user-correlative data token (TKN), in order to obtain correlative encrypted data (El) per user, and to store, the encrypted data (El), in a “single block” (Block 301, Block 302, Block 303) of the ledger-less blockchain system and method of this invention. Unlike prior arts, in this system and method, each block has only one transaction. That is, only one user’s data, vide user-correlative data token (TKN), is stored in each block. This mechanism ensures that the need for a ledger is obviated; since, each block, now, a blockidentity (BI) correlative to the user-correlative data token (TKN). Typically, the first encryption module (ECPI) is configured to validate all incoming requests and form a first protective layer for this system and method.

[0127] This Data Token Generation Module (DTGM) is also the “engine” of this invention. Here, the engine receives details, validates against the blocks and data on the blocks, of this system and method, checks for duplicates, by traversing through each block and by parsing data on each block; once validated / verified that the request is not a duplicate request, the “engine” begins its mining process. The mining process is programmed to handle requests or transactions in a synchronous way; thus, preventing multiple requests / transactions being bundled in to a single block as in regular distributed ledger mechanisms. The “engine”, then, creates a block with details (such as actual image of identity document, and the like) of a single user alone as only one request or transaction is processed at any given point of time. This “engine”, vide its mining process, generates an encrypted value that is used in generation of user-correlative non-fungible token (NFT) in next step.

[0128] In at least an embodiment of the Data Token Generation Module (DTGM), a second encryption module (ECP2) is configured to encrypt, using pre-defined encryption algorithms, the encrypted data (El) in order to obtain a usercorrelative non-fungible token (NFT). This user-correlative non-fungible token (NFT) is provided to the user who made the request to use this system and method. A Non-Fungible Token (NFT) is a unique, cryptographic digital token that represents ownership or proof of authenticity of a specific asset or data. These are non-interchangeable and individually distinct. These implemented using blockchain technology to ensure decentralization, immutability, and verifiability of ownership.

[0129] Based on the data being requested to be tokenize, via the Data Token Generation Module (DTGM), a data structure is to be configured on this invention’s Legderless Blockchain.

[0130] Sample Data Structure:

[0131] • Data Point 1

[0132] • Data Point 2

[0133] • Data Point 3

[0134] • Data Point 4 & more based on use case. . . .

[0135] • ProofOfTruth - Digital signature sent from Source of Truth.

[0136] • Proof - Initial Genesis block will start at 0000 (Can increase complexity by adding more number of leading zeros) and following blocks will generate it’s own Proof value based on the following combination:

[0137] Previous Block’s Proof & Previous Block’s Hash

[0138] This will establish and be an additional point where the Block’ s linking with previous block is established and evaluated in addition to the previous Hash value.

[0139] • Previous Hash - Used to link to previous block.

[0140] Date & Time Stamp. • Transaction ID - Transaction Identifier.

[0141] Data Structure of a Block

[0142] Each block in the ledgerless blockchain consists of:

[0143] • Data Points: Specific to the type of tokenization request (e.g., identity, property)

[0144] • Proof of Truth: The digital signature received from the Source of Truth.

[0145] • Previous Hash: A link to the previous block’s cryptographic hash

[0146] • Proof: A cryptographic value used for additional verification, based on the combination of the previous block's proof and hash

[0147] • Timestamp: The date and time when the transaction was processed

[0148] • Transaction ID: A unique identifier for the transaction

[0149] Block Hashing Algorithm (SHA-256)

[0150] The system uses the SHA-256 cryptographic hash function to generate secure hashes for each block. The process involves:

[0151] • Encoding data into bytes using Unicode

[0152] • Computing a 256-bit hash using the SHA-256 algorithm

[0153] • Converting the hash into a hexadecimal string for storage and reference

[0154] AES Encryption Algorithm

[0155] The App Adapter employs the AES encryption algorithm to encrypt the block's hash before generating the token. The encrypted hash serves as the user's token, and the App Adapter manages the encryption keys for future decryption.

[0156] In at least an embodiment, the following discloses process steps for identity generation using the Data Token Generation Module (DTGM):

[0157] 1. User initiates data verification process;

[0158] 2. User enters token ; 3. Data that is to be tokenized is validated by means of any known authentication systems (this step ensures that an unauthorized person cannot get user-correlative non-fungible token (NFT) from user-correlative data token (TKN));

[0159] 4. A smart contract is issued to the user which, once accepted, is stored and the transaction for blockchain begins — Proof of Truth is requested from Source of truth. Once Proof of Truth is received that is when the Block creation process begins.;

[0160] 5. User’s data is encrypted and stored in blockchain;

[0161] 6. Unlike regular blockchains, each block only has one transaction only - i.e. only one data item is stored in each block. — this mechanism ensures that the system does not need a ledger to track the data and its owner;

[0162] 7. Blockchain and corresponding data is stored in Virtual Memory i.e memorymapped file for efficient data storage and retrieval — this file is managed through virtual memory mapping, leveraging an Operating System’s capabilities to optimize resource usage;

[0163] 8. The blockchain also has an additional layer of Artificial Intelligence models and Machine Learning models incorporated which monitors and validates the hashes frequently to detect any anomaly or attempts to break into the system;

[0164] 9. A block’s Hash is then taken and encrypted further with encryption to generate a user-correlative non-fungible token (NFT), this user-correlative non-fungible token (NFT) is provided to the user who made the request as their user-correlative data token (TKN).

[0165] In at least an embodiment of the Data Token Verification Module (DTVM), a service request module (SRM) is configured to allow a user, with their corresponding user-correlative non-fungible token (NFT), to input their own user-correlative non-fungible token (NFT). Further, a communicably coupled non-fungible token verification module (NFTVM) is configured to relay this submitted token (NFT) to this invention’s further modules for verification.

[0166] In at least an embodiment, the Data Token Generation Module (DTGM) stores signed, verified, smart contacts per user and per user identity, validated all incoming requests by verifying digital signatures and JWT in request header and, upon determination of being a valid request, passes on the user-correlative non- fungible token (NFT) in response to request from the service request module (SRM).

[0167] In at least an embodiment of the Data Token Verification Module (DTVM), a decryption module (DCP) is configured to, in a first instance, retrieve data corresponding to the submitted token (NFT) and is configured to, in a second instance, decrypt the retrieved data in order to obtain data from its corresponding user-correlative data token (TKN). When a user provides the user-correlative non-fungible token (NFT) to this system and method, the request once again goes to decryption module (DCP) which validates whether the request is valid or not and valid request move forward. The user-correlative non-fungible token (NFT), in the request, is then decrypted with a stored decryption key to get the encryption value and this encryption value is passed into this system’s blocks / nodes.

[0168] In at least an embodiment of the Data Token Verification Module (DTVM), a display module (DPM) is configured to check the submitting user’s pre-defmed privacy settings, and correlative to these privacy settings, data, per submitted token (NFT), is displayed to the extent of the settings determined in / by the privacy settings - either redacted data is displayed or full data is displayed. The “Engine” then traverses through this system blocks and parses data of each traversed block in order to identify the block with corresponding encryption data and gets the identity image from the respective block and then passes the image to the “engine” which then provides a response to a user via a display mechanism.

[0169] In at least an embodiment, the following discloses process steps for data verification using the Data Token Verification Module (DTVM):

[0170] 1. User provides the user-correlative non-fungible token (NFT) to a requesting service / application;

[0171] 2. Requesting service / application submits the user-correlative non-fungible token (NFT) to the blockchain system, of this invention, for verification;

[0172] 3. Blockchain nodes retrieve BlockID or Hash from the user-correlative non- fungible token (NFT) by decrypting;

[0173] 4. From the BlockID, Image, Data Item, or Identity Document stored inside is retrieved and based on the level of authorization of the service / application requesting, the user-correlative data token (TKN) data is redacted and displayed or data is fully displayed.

[0174] This ensures that each user's data resides in its own isolated entity, immune to mingling with other data and impervious to cross-referencing. Consequently, the risk of unintended data exposure and unintended correlations between identities is virtually eradicated.

[0175] FIGURE 4 illustrates how the system and method, of this invention, processes one transaction at a time and creates one block per transaction in accordance with this invention. In the current invention, users (101) contribute data items to a blockchain system. Here, in each block (401, 402, 403), an encrypted data item (El) acts as an identity for that block. The system and method, of this invention, takes this encrypted data item (El) to another encryption mechanism, the output of which is provided to the user / s as their data token (NFT).

[0176] The user-correlative non-fungible token (NFT) which is given to a user can be used by the user to submit to this invention’s service request module (SRM). Then, the decryption module (DCP) is configured to decrypt and identify the block where corresponding encrypted data (El) is stored correlative to the usercorrelative data token (TKN). This is, further, decrypted and corresponding data is displayed, through the display module (DPM), as per pre-defined privacy settings. Since the system and method, of this invention, uses block identity of encryption, itself, to obtain user data, there is no need for a ledger; this is achievable only of the block chain system allows one transaction per block.

[0177] FIGURE 5 illustrates how an app-adapter system feeds the engine of this invention.

[0178] Typically, users (101), with their requests / transactions, engage with an app- adapter system of this invention. This app-adapter system is configured with an asynchronous-await module which queues each user’s each request / transaction until it receives a response from the “engine” of this invention. Once a single request / transaction is complete, only then, the app-adapter system, of this invention, pushes another request / transaction. This app-adapter system is configured to receive and process transactions asynchronously via a public API endpoint. The adapter manages tokenization requests and interacts with the blockchain system to initiate the validation and tokenization process. The API receives multiple requests simultaneously, and each request can be processed independently of the others; allowing multiple tokenization transactions to occur simultaneously. Proof of Truth Consensus Mechanism. After receiving a tokenization request (Tl) from the app-adapter system, the system sends the request asynchronously to the Source of Truth. The Source of Truth validates the request and issues a unique Digital Signature as a form of proof, confirming the transaction's validity. This Proof of Truth is then returned to the ledgerless blockchain for inclusion in the transaction block.

[0179] App-adapter system sends user information and data to Source of Truth for validation; once the confirmation is done, a unique Digital signature with additional information that provides evidence towards the validation being complete is sent to this system’s Ledgerless Blockchain as Proof of Truth.

[0180] The transaction is sent to this system’ s Ledgerless Blockchain system using asynchronous / await modules, with built-in queuing logic, in order to allow nonblocking execution. While the Blockchain system processes a transaction, the API Gateway remains free to handle other incoming requests. Although transactions are received asynchronously, the queuing logic ensures that Blockchain systems only handle one transaction at a time.

[0181] This is how the system enables Proof of Truth from Source of Truth.

[0182] FIGURE 6 illustrates how a block is formed using proof of truth and source of truth. The blockchain system processes transactions, one at a time, ensuring synchronous processing on a per-block basis. Each block contains one transaction, and the transaction data is held temporarily in virtual memory rather than being permanently stored on a ledger. The blocks are linked via cryptographic hashes, ensuring data integrity.

[0183] This is how single transaction per block is employed: The requests with Proof of Truth from app-adapter systen sent using asynchronous-await module are received by a Tiny Webserver or REST at the nodes (depending on use case), that handles the requests Synchronously - Synchronous transaction is a type of operation or interaction in a system where the requesting party (e.g., a client or application) waits for a complete response before proceeding with any further actions. In this model, the transaction follows a strict request-response cycle, where the processing of the transaction must finish and return a result before the next step can begin.

[0184] This mechanism makes sure that each time a transaction is processed, unless and until it is processed and response is sent the next transaction is not processed, this makes sure that when a transaction is received our Blockchain creates a new block and only once that process is completed and the block’s hashing is sent as response to App Adapter will the next transaction be picked up for processing.

[0185] Further, the “engine” being a blockchain-enabled engine, processes these incoming requests / transactions, sequentially, in a loop, such that it traverses through each block and through each transaction within each block; in order to check for duplicates and other data integrity parameters - through the Data Token Verification Module (DTVM), If all conditions are met, then a new block gets created, by the “engine” with one transaction only. The “one transaction per block” is achieved here as well with the synchronous method whereas other transactions wait, on account of the app-adapter system, while checks are being performed.

[0186] The following shows an exemplary embodiment as to how block data storage takes place, without a ledger, using this invention:

[0187] While, in prior arts, all data is physically stored on drives with multiple ledgers hosted across public networks across multiple nodes, this current invention being a Ledgerless Blockchain system, does not use any kind of a permanent store. The block created holds the transactional data which would be tokenized next, and this block is not held on a physical file, but on a virtual memory, in this context, the data is mapped into the process’s virtual address space, but instead of being backed by a physical file on disk, it is backed by RAM.

[0188] The following is an overview of how data is stored:

[0189] • Memory Mapping: Instead of reading / writing to disk directly, a memorymapped file maps the file's data into the virtual memory address space. With in-memory storage, you can map a portion of the file or the entire file into memory.

[0190] • File Handle and Accessor: The memory-mapped file creates an accessor that enables the application to read and write data to the memory-mapped space as though it’s dealing with standard memory arrays (e.g., byte[] or int[]).

[0191] • In-Memory: When one configures the Memory MappedFile to operate in memory (not backed by disk), the file resides in the system’s RAM. This is significantly faster than disk storage because it avoids the latency associated with disk I / O operations.

[0192] The advantages of the same are as follows:

[0193] Faster Transactions: Data access and storage are much faster than traditional disk storage, as data resides in RAM, eliminating the overhead of disk I / O.

[0194] Concurrent Processing: MMFs allow for more efficient access by multiple processes or threads, reducing the need for complex locking mechanisms. Increased Security: In-memory storage is transient and more secure from manipulation or corruption, and the OS provides additional memory access protections.

[0195] Less Data Corruption Risk: Atomic memory operations and OS safeguards reduce the risk of partial writes or corrupted data.

[0196] This ensures a true ledgerless blockchain system, where no data is stored; thereby, physically eliminating ledger in any form.

[0197] Token generation:

[0198] Once the block is created, its specific hashing (Hash acts as the identity of the Block) is shared with app-adapter system.

[0199] Since the system has only one transaction in a block there is no need for a ledger to keep a track of transaction and the system can use the block’ s hashing to identify the block and retrieve data that is inside the block. App-adapter system then does another layer of encryption using AES encryption algorithm to generate a token.

[0200] Following steps are followed:

[0201] Block hash is received by app-adapter system. AES Encryption is applied to the hashing received and the AES Encrypted Hashing is the Token.

[0202] AES key is maintained within the app-adapter system to decrypt the Token that is generated.

[0203] This Token is then shared with the user in return for the data submitted by the user.

[0204] The following steps disclose:

[0205] Step 1: Initiating Tokenization

[0206] When a user submits data for tokenization through the app-adapter module, a new transaction (Tl) is created. The transaction is sent to the Source of Truth for validation using asynchronous communication. The app-adapter system remains available to process other tokenization requests during this process.

[0207] Step 2: Proof of Truth Validation

[0208] Upon receiving (Tl), the Source of Truth validates the data based on the tokenization type (e.g., identity, property). Once validated, the Source of Truth issues a unique digital signature that serves as Proof of Truth. This proof ensures that the user is authorized to tokenize the submitted data.

[0209] Step 3: Block Creation and Hashing

[0210] The validated transaction, along with the Proof of Truth, is forwarded to the ledgerless blockchain system. A new block is created for each transaction. The block includes:

[0211] • Data Points (e.g., user data, tokenization details)

[0212] • Proof of Truth (digital signature from Source of Truth)

[0213] • Previous block’s hash

[0214] • Block's own hash (computed using SHA-256)

[0215] • Timestamp and Transaction ID The blockchain system computes a cryptographic hash using the SHA-256 algorithm to ensure data integrity. The hash is built by combining the previous block’s proof and hash, linking blocks in a secure chain.

[0216] Step 4: Block Data Storage

[0217] Unlike traditional blockchains, the tokens system does not store blocks permanently on a ledger. Instead, the block is stored in virtual memory (RAM). This memory-mapped storage model ensures fast data access while eliminating the need for disk I / O and persistent storage. Once a transaction block is processed, its hash is sent to the app-adapter system.

[0218] Step 5: Token Generation

[0219] The app-adapter system uses the block's hash to generate a token. The hash is encrypted using the AES encryption algorithm. The encrypted hash becomes the Token, which is then returned to the user as proof of the data's tokenization.

[0220] Step 6: Token Management

[0221] The app-adapter system maintains the AES key used to encrypt and decrypt tokens. The token serves as a reference to the block, allowing users to retrieve the tokenized data without requiring a ledger.

[0222] All problems related to centralized vulnerability, lack of privacy control, inadequate authentication, limited user autonomy, lack of self-sovereignty, fragmented identity solutions - as explained in the ‘Background of the Invention’ section - are all solved by the current invention.

[0223] This invention’s system can be tweaked to provide SSI as well with a dedicated user interface with which users can authorize sharing of information and also limit the amount of information that is shared. TECHNICAL ADVANTAGES:

[0224] These systems and methods provide enhanced security, user privacy, data control, and decentralized data management, addressing the shortcomings of prior art systems and transforming the way personal data is managed and verified in the digital age.

[0225] 1. Decentralization: Unlike prior art that relies on centralized databases, the tokens, of this invention, leverages blockchain and distributed nodes, ensuring data is decentralized and secure, mitigating the risks of data breaches.

[0226] 2. Cryptography and Security: Tokens, of this invention, employ advanced cryptographic techniques for data protection. This ensures data remains confidential and accessible only by authorized entities, addressing prior art's vulnerabilities.

[0227] 3. Self-Sovereign Identity: Through NFT-based authentication, tokens, of this invention, offer users full control over their data, a novel approach that counteracts the lack of user autonomy in traditional systems.

[0228] 4. Privacy Enhancement: Innovative design, of the tokens, of this invention, empowers users to share specific data dattributes only when necessary, significantly lowering the risk of undue exposure and data misuse.

[0229] 5. Unified Authentication: The amalgamation of these pioneering technologies presents a unified authentication solution that bridges gaps in prior art's fragmented processes.

[0230] Moreover, the versatile nature of the tokens, of this invention, extends beyond personal data management. Its underlying technologies provide a framework that can be adapted to a multitude of industries such as financial services, healthcare, supply chain management, and more. This capacity to revolutionize multiple sectors amplifies its potential impact. This invention’s system and method offers a range of substantial advantages when compared to prior art in the field of personal data management:

[0231] 1. Enhanced Security: Tokens, of this invention, integrate blockchain technology and advanced cryptography, creating an immutable and tamperproof record of data. This establishes an unprecedented level of security compared to the vulnerabilities associated with centralized databases.

[0232] 2. Decentralization: By incorporating distributed nodes, tokens, of this invention, ensure that data is not concentrated in a single location, thereby minimizing the risk of data breaches and enhancing overall system robustness.

[0233] 3. User Control: Tokens, of this invention, introduce the innovative concept of self- sovereign data, empowering users with complete control over their personal data. This stands in contrast to prior art, where users often lack control over their own information.

[0234] 4. Privacy by Design: With tokens, of this invention, users can judiciously share specific data attributes, fostering a privacy-centric approach. This counters prior art where over-sharing of personal data is a common occurrence.

[0235] 5. Unified Authentication: Tokens, of this invention streamline authentication across diverse applications through a unified methodology, simplifying user interactions and obviating the fragmented processes inherent in prior art.

[0236] 6. Innovation: The distinctiveness of a ledgerless blockchain system, intrinsic to tokens, of this invention, attests to the innovative nature of this technology. This novel feature remains unparalleled in prior art. 7. Future-Ready Architecture: Tokens, of this invention foundation on cutting-edge technologies positions it as a future-proof solution, amenable to evolving challenges and advancements.

[0237] 8. Mitigated Identity Fraud: The robustness of tokens, of this invention, reduces the susceptibility to identity fraud, as the amalgamation of blockchain, cryptography, and NFT-based authentication establishes an environment where malicious actors face considerable hurdles in compromising identities.

[0238] 9. Market Disruption: Distinctive approach, using tokens, of this invention, bears the potential to disrupt the personal identity management landscape, providing a safer, user-centric, and more streamlined alternative to prevailing methods.

[0239] 10. Compliance: Blockchain technology can help organizations comply with regulatory requirements, such as GDPR and CCPA, by providing a secure and transparent platform for managing user data. The distributed nature of blockchain ensures that data is stored in compliance with regulatory requirements, while the transparency of the blockchain allows for easy auditing and reporting.

[0240] To sum up, tokens, of this invention, transcends prior art by introducing a comprehensive solution that harmonizes security, privacy, innovation, and user empowerment. These advantages unequivocally position the tokens, of this invention, as a pioneering paradigm in the realm of personal data management, propelling it as a transformative force within the industry.

[0241] The current invention achieves the following TECHNICAL ADVANTAGES:

[0242] Privacy Enhancement: The user-correlative data token (TKN), of this invention, in conjunction with the user-correlative non-fungible token (NFT) introduces a privacy-first approach to managing user data, where individuals or entities can selectively disclose, through privacy settings, only the necessary information needed for specific transactions or interactions. This contrasts with prior art systems where users often have to share excessive / unnecessary amounts of personal data, leading to potential risks of exposure and misuse. Selective Attribute Disclosure: With user-correlative data token (TKN), of this invention, in conjunction with the user-correlative non- fungible token (NFT), users retain control over what data attributes they share. For example, in a healthcare scenario, a user might only need to disclose their medical history for a specific treatment, while keeping other personal details like contact information or financial data private. This granular control over data sharing ensures that only relevant information is revealed in a transaction. Reduced Data Exposure: By allowing users to share minimal information, the user-correlative data token (TKN), of this invention, in conjunction with the user-correlative non-fungible token (NFT) lowers the risk of data breaches or misuse. Even if a transaction is intercepted or compromised, the sensitive personal data is not fully exposed because unnecessary attributes are kept private. This privacy enhancement addresses a key flaw in traditional systems where excessive data sharing increases vulnerability. User-Centric Data Control: Unlike centralized prior art systems where organizations manage and control user data, the usercorrelative data token (TKN), of this invention, in conjunction with the user-correlative non-fungible token (NFT) empowers users with full autonomy over their information. The self-sovereignty model ensures that users can make decisions about what is shared, significantly enhancing privacy and reducing the risk of data theft, fraud, or data manipulation.

[0243] Unified Authentication:

[0244] 1. The unified authentication model embedded in the user-correlative data token (TKN), of this invention, in conjunction with the usercorrelative non-fungible token (NFT), of this invention, combines multiple technological advancements to create a seamless and cohesive solution, addressing the fragmented and siloed nature of traditional authentication methods.

[0245] 2. Bridging Fragmented Processes: In many prior art systems, authentication is often disjointed across different platforms, leading to inefficiencies and security vulnerabilities. Users may need to authenticate separately for different services or applications, increasing complexity and risk. DUB Tokens simplifies this by offering a unified, cross-platform authentication solution, where a single verification process ensures access across multiple services.

[0246] 3. Streamlined User Experience: This single-point authentication reduces the need for repeated logins, password management, or multiple data checks, enhancing both user convenience and security. The unified system also eliminates the need for users to store and manage multiple credentials, reducing the likelihood of credentialbased attacks. 4. Enhanced Security through Tokenization: Instead of relying on passwords or traditional credentials, the user-correlative data token (TKN), of this invention, in conjunction with the user-correlative non- fungible token (NFT), of this invention, uses a token-based approach for authentication. Each transaction or access request generates a unique token, validated through the external Proof of Truth mechanism. This process ensures that each authentication is secure, tamper-proof, and limited in scope, reducing the risk of phishing attacks or unauthorized access.

[0247] This invention’s user-correlative data token (TKN), of this invention, in conjunction with the user-correlative non-fungible token (NFT) which forms the foundation of a ledgerless technology, privacy enhancements, unified authentication, and Al-driven security make it a groundbreaking platform with the potential to revolutionize multiple industries. Its adaptability extends across healthcare, pharmaceuticals, financial services, supply chain management, personal identity management, government services, real estate, education, and logistics. By addressing the limitations of prior art technologies and introducing novel solutions like selective data sharing, streamlined authentication, and high scalability, this invention positions itself as a versatile and transformative platform for secure, user-centric applications across a wide range of sectors.

[0248] The integration of this invention’s user-correlative data token (TKN), of this invention, in conjunction with the user-correlative non-fungible token (NFT) into these industries could redefine processes, enhance security, and foster new opportunities for streamlined operations. Furthermore, the ledger-less architecture bolsters security by minimizing the surface area for potential attacks. In a ledger-based blockchain, a compromised block could potentially impact a multitude of transactions. In contrast, isolated blocks, proffered by the tokens of this invention, offer inherent containment — any security breach is confined to a single data block, preventing cascading effects and safeguarding the overall system integrity.

[0249] In terms of efficiency, the ledger-less system optimizes data retrieval and verification processes. Since each data block contains only one user's data, retrieval and verification become highly streamlined. This not only accelerates access to data information but also minimizes computational overhead, making the tokens, of this invention a nimble and responsive solution.

[0250] Ultimately, the ledger-less blockchain system using tokens, of this invention decisively addresses the problems inherent in prior art's centralized, ledger-based models. By providing a decentralized, secure, and efficient way to manage personal data, the tokens, of this invention eliminates the risks of data mingling, enhances privacy, fortifies security, and introduces a paradigm shift in how data is managed. This distinct architecture stands as a hallmark of tokens, of this invention, and sets it apart as a truly groundbreaking solution in the landscape of data management.

[0251] 1. Ledger-less Blockchain Architecture

[0252] • Problem Solved: Prior art blockchain systems rely on ledgers to link tokens or transactions to their owners, which can compromise user privacy by enabling tracking across the blockchain. • Inventive Step: The current invention eliminates the need for a ledger by associating only one transaction per block. Each block contains a user’s encrypted data (ED), which is further processed to generate a usercorrelative non-fungible token (NFT). By doing so, the system avoids the centralized nature of ledgers and the risk of tracking or correlating tokens to specific users. ne-Transaction-Per-Block Mechanism

[0253] • Problem Solved: Prior art blockchain systems often bundle multiple transactions in a single block, making it difficult to ensure privacy, as multiple identities and transactions are processed together.

[0254] • Inventive Step: This invention’s one-transaction-per-block mechanism ensures that each user's data is isolated in a unique block, eliminating any overlap with other users and providing a higher level of privacy and security. This single-transaction block structure also obviates the need for tracking transactions through a ledger. mart Contract-Based Identity Verification and Tokenization

[0255] • Problem Solved: Prior art identity verification systems can be vulnerable to centralized failures, fragmented identities, and a lack of user control over their data.

[0256] • Inventive Step: The current invention^ system incorporates a smart contract module (SCM) that issues triggers and creates smart contracts when user identities are verified. This allows for automated, secure identity verification and tokenization, ensuring that only verified, userspecific identity tokens are generated and stored. The use of trigger-based smart contracts tied to specific users further enhances security and ensures that privacy is maintained. equential, Asynchronous Processing for Privacy and Integrity • Problem Solved: In prior art blockchain systems, transactions are often processed in parallel, making it difficult to ensure uniqueness and prevent duplicate transactions.

[0257] • Inventive Step: The current invention’s system processes each request in a sequential manner, queuing transactions and processing them one at a time. This guarantees data integrity and prevents duplicates. This is made possible through an app-adapter system that waits for the completion of a transaction before processing the next one, ensuring that each transaction is handled securely and with full integrity. nhanced User Privacy with Multi-Layered Encryption

[0258] • Problem Solved: In prior art blockchain systems, the public ledger reveals data that can be traced back to users, even if it is encrypted.

[0259] • Inventive Step: The current invention’s system introduces multi-layered encryption where the user’ s identity is encrypted twice — first to create an encrypted identity (El) and then to generate a user-correlative non- fungible token (NFT). This double encryption, combined with the one- transaction-per-block mechanism, ensures complete privacy for users, as each identity is only accessible by decrypting the corresponding block. ecentralized Identity with Self-Sovereign Identity (SSI) Potential

[0260] • Problem Solved: Many identity management systems, in prior arts, provide limited user control over their identity and data, with no clear mechanism for enforcing privacy preferences.

[0261] • Inventive Step: The current invention’s system allows users to define their own privacy settings, which dictate what data is displayed when their identity token is validated. Additionally, this current invention’s system is adaptable to support self-sovereign identity (SSI), empowering users to control and share their data as they see fit. This decentralized approach to identity gives users autonomy over their data, enhancing both privacy and control.

[0262] 7. Security Vulnerabilities in Blockchain

[0263] • Problem Solved: Prior art blockchain systems are vulnerable to common security threats, including man-in-the-middle attacks, denial-of-service (DoS), and data tampering.

[0264] • Inventive Step: The current invention’s ledgerless architecture of usercorrelative data token (TKN), of this invention, in conjunction with the usercorrelative non-fungible token (NFT) enhances security by focusing on security through request validation and preventing vulnerabilities that arise from storing data in traditional blockchains. By validating requests externally integrating real-time threat detection, it ensures higher security standards.

[0265] 8. Decentralisation problems associated with Proof of Work (PoW) or Proof of Stake (PoS)

[0266] • Problem Solved: Prior art tokenization models and blockchain systems are primarily focused on decentralization through node-based consensus models, such as Proof of Work (PoW) or Proof of Stake (PoS), which often come with challenges like high energy consumption, slow transaction times, and security vulnerabilities related to network attacks and data corruption.

[0267] • Inventive Step: The current invention’s ledgerless architecture of usercorrelative data token (TKN), of this invention, in conjunction with the usercorrelative non-fungible token (NFT) introduces a unique blockchain implementation with a Proof of Truth consensus model, where validation is done outside of the blockchain by an external Source of Truth. This enhances security, reduces processing time, and allows for the seamless integration of Al for API security. The process focuses more on API security rather than node evaluation, making it more adaptable for industries like healthcare and pharmaceuticals, where accuracy and real-time data validation are crucial. Moreover, this invention’ s -and-play model simplifies implementation across various platforms, offering cost efficiency, enhanced compliance, and advanced security features. igh Energy Consumption

[0268] • Problem Solved: Prior art blockchain models and blockchain systems using PoW require significant energy, contributing to environmental concerns.

[0269] • Inventive Step: The current invention’s ledgerless architecture of usercorrelative data token (TKN), of this invention, in conjunction with the usercorrelative non-fungible token (NFT) eliminates the need for energy- intensive mining. Instead, the consensus is achieved through external validation, significantly reducing energy consumption and making it more sustainable and cost-efficient. Slow and Inefficient Consensus Mechanisms

[0270] • Problem Solved: Prior art blockchain systems rely on consensus models like Proof of Work (PoW) or Proof of Stake (PoS), which are slow and resource-intensive.

[0271] • Inventive Step: The current invention’s ledgerless architecture of usercorrelative data token (TKN), of this invention, in conjunction with the usercorrelative non-fungible token (NFT) uses an external Proof of Truth validation, making transactions much faster and reducing computational overhead. This innovation ensures real-time processing, minimizing delays typically associated with blockchain validation. The current invention’ s Proof of Truth model validates transactions externally, significantly reducing processing time and energy consumption while maintaining high security and accuracy. Data Integrity Monitoring

[0272] • Problem Solved: Prior art blockchain systems face challenges in continuously monitoring and ensuring data integrity after block creation.

[0273] • Inventive Step: The current invention’s ledgerless architecture of usercorrelative data token (TKN), of this invention, in conjunction with the usercorrelative non-fungible token (NFT)solves this through its ledgerless model, where Al-driven anomaly detection continuously monitors transaction integrity, ensuring that no unauthorized changes are made to the data once validated. Complex and Costly Implementation

[0274] • Problem Solved: Prior art blockchain platforms are complex and expensive to integrate.

[0275] • Inventive Step: The current invention’s ledgerless architecture of usercorrelative data token (TKN), of this invention, in conjunction with the usercorrelative non-fungible token (NFT) offers a simpler, plug-and-play solution, making it easier for businesses to adopt without extensive customizations. This reduces costs and implementation time across industries like healthcare, pharmaceuticals, and finance. Inadequate Flexibility for Compliance and Regulatory Demands

[0276] • Problem Solved: Prior art blockchain solutions find it challenging to meet strict regulatory requirements in industries like healthcare.

[0277] • Inventive Step: The current invention’s ledgerless architecture of usercorrelative data token (TKN), of this invention, in conjunction with the usercorrelative non-fungible token (NFT) with its ledgerless approach and private Blockchain, is highly adaptable and designed to meet compliance standards, ensuring transparency and data immutability, while adhering to regulations like HIPAA and GxP. User Autonomy and Self-Sovereignty

[0278] • Inventive Step: The current invention’s ledgerless architecture of usercorrelative data token (TKN), of this invention, in conjunction with the usercorrelative non-fungible token (NFT) empowers users with full autonomy over their data and transactions. By decentralizing control and providing tokenized solutions without relying on centralized ledgers, users can manage their assets and data securely, maintaining full sovereignty in scenarios like healthcare or finance where autonomy is critical. Cross-Industry Applicability

[0279] • Inventive Step: The current invention’s ledgerless architecture of usercorrelative data token (TKN), of this invention, in conjunction with the usercorrelative non-fungible token (NFT) is built with ledgerless technology, making it adaptable across multiple industries, from supply chain management to finance, healthcare, and more. This flexibility allows businesses to adopt the platform in different domains while benefiting from faster, secure, and cost-efficient tokenization processes. The current invention’ s tokens solve these technical problems by introducing blockchain technology, distributed nodes, cryptography, and NFT-based authentication. These innovations provide enhanced security, user privacy, data control, and decentralized data management, addressing the shortcomings of existing systems and transforming the way personal data is managed and verified in the digital age. Security Risks and Data Integrity

[0280] Problem Solved: Prior art blockchains store data on distributed ledgers, which can be vulnerable to attacks like double-spending, data tampering, or even consensus-related vulnerabilities. • Inventive Step: By moving the validation process outside the blockchain and using Al-driven API security, the current invention’s ledgerless architecture of user-correlative data token (TKN), of this invention, in conjunction with the user-correlative non-fungible token (NFT) mitigates security risks like man-in-the-middle attacks, denial-of-service (DoS) attacks, and other OWASP Top 10 threats. It also continuously monitors data integrity, ensuring no unauthorized changes occur. Lack of Real-Time Transaction Validation

[0281] • Problem Solved: Prior art blockchain systems can be slow to validate transactions due to their reliance on distributed ledgers.

[0282] • Inventive Step: The current invention’s ledgerless architecture of usercorrelative data token (TKN), of this invention, in conjunction with the usercorrelative non-fungible token (NFT) solves this by offering real-time validation through external sources, allowing faster transaction processing while still ensuring the accuracy and security of each transaction. Limited Scalability

[0283] • Problem Solved: Prior art Blockchains relying on node-based consensus models often face scalability challenges as transaction volume increases.

[0284] • Inventive Step: The current invention’s ledgerless architecture of usercorrelative data token (TKN), of this invention, in conjunction with the usercorrelative non-fungible token (NFT) ledgerless architecture enables greater scalability, as the validation process is handled externally, reducing the need for additional nodes or computing power, allowing it to scale seamlessly with transaction volume. User Autonomy and Self-Sovereignty

[0285] • Problem Solved: Prior art systems often centralize control, limiting user autonomy over their data and assets. • Inventive Step: The current invention’s ledgerless architecture of usercorrelative data token (TKN), of this invention, in conjunction with the usercorrelative non-fungible token (NFT) with its ledgerless, decentralized framework, allows users to retain full control over their data and transactions, ensuring self- sovereignty and independence from centralized authorities, which is particularly crucial in industries like healthcare and finance.

[0286] 20. Industry- Agnostic Design

[0287] • Problem Solved: Prior art blockchain solutions are designed for specific use cases, limiting their flexibility.

[0288] • Inventive Step: The current invention’s platform-agnostic ledgerless system makes it applicable across various industries, from pharmaceuticals and healthcare to finance and supply chain management, solving problems unique to each sector while providing a unified tokenization platform.

[0289] The TECHNICAL ADVANCEMENT, of this invention, lies in the following:

[0290] - implementation of a ledger-less blockchain system is a pivotal differentiator that underscores this invention and its superiority over existing solutions in personal data management. Unlike prior art blockchains that compile multiple transactions into a single block, the current invention introduces a unique approach by dedicating an entire block to each user's data — a design that fundamentally departs from the traditional notion of a shared ledger;

[0291] - harness the power of blockchain technology, distributed nodes, cryptography, and NFT-based authentication;

[0292] - this departure from ledger-based architectures carries profound implications for privacy, security, and efficiency in data management. The ledger-less system enhances privacy by segregating individual identities into discrete, standalone blocks. This means that each user's data resides in its own isolated entity, immune to mingling with other data and impervious to crossreferencing. Consequently, the risk of unintended data exposure and unintended correlations between identities is virtually eradicated.

[0293] The TECHNICAL ADVANCEMENT, of this invention, lies in the following:

[0294] - providing a blockchain-based system for data management, distinctively avoiding a ledger while using a one-transaction-per-block mechanism to secure and manage data tokens. By eliminating the ledger, it addresses key concerns around privacy, centralization, and data sovereignty, as it prevents the tracking of token owners. The modules — Data Token Generation (DTGM) and Validation (DTVM) — efficiently handle data capture, encryption, token issuance, and validation, while ensuring that user privacy and data integrity are maintained;

[0295] - creation of a ledger-less, one-transaction-per-block blockchain system that provides a privacy-focused data management solution. By eliminating the ledger, using smart contract-based verification, employing sequential processing, and incorporating multi-layered encryption, the current invention’s system offers an inventive way to ensure both privacy and security in data tokenization, which prior art blockchain systems cannot achieve.

[0296] While this detailed description has disclosed certain specific embodiments for illustrative purposes, various modifications will be apparent to those skilled in the art which do not constitute departures from the spirit and scope of the invention as defined in the following claims, and it is to be distinctly understood that the foregoing descriptive matter is to be interpreted merely as illustrative of the invention and not as a limitation.

Claims

CLAIMS,1. Ledger-less blockchain systems for data management and tokenization, said system comprising:- a Data Token Generation Module (DTGM) configured to capture data that is to be tokenized in order to configure said data into a data token (TKN) correlative to the captured data, in that, for a given data token (TKN) used by this invention, only one transaction per block being allowed, said generated token (TKN) being Source of Truth; o said Data Token Generation Module (DTGM) configured with a first encryption module (ECPI) to encrypt, using pre-defmed encryption algorithms, each first user’ s data token (TKN), in order to obtain correlative encrypted data (El) per first user, and to store, said encrypted data (El), in a “single block” (Block 301, Block 302, Block 303) of said system, each block having a unique block-identity (BI) correlative to the data token (TKN), said first encryption module (ECPI) being configured to validate all incoming requests and forming a first protective layer for said system; o said Data Token Generation Module (DTGM) configured with a second encryption module (ECP2) to encrypt, using pre-defmed encryption algorithms, said correlative encrypted data (ED) in order to obtain a user-correlative non-fungible token (NFT) being provided to said first user requesting generation of said data token (TKN);- a verification module (VFM) configured to, authentically, verify data (101) that is to be tokenized, before generating a correlative data token (TKN), in order to conform to it being said Source of Truth;- a Data Token Verification Module (DTVM) configured to allow a second user with a user-correlative non-fungible token (NFT), to verify said user-correlative non-fungible token (NFT), said Data Token Verification Module (DTVM) comprising: o a decryption module (DCP) configured to, in a first instance, retrieve data corresponding to said second user’s submitted token (NFT) and configured to, in a second instance, decrypt the retrieved data in order to obtain data from its corresponding usercorrelative data token (TKN), said decrypted retrieved data being Proof of Truth;- an app-adapter system that queues user requests and transactions, from said Data Token Generation Module (DTGM) and from said Data Token Verification Module (DTVM), in an asynchronous-await module, allowing said system to process only one request at a time and create or read one block per transaction; and- a trigger-based smart contract module (SCM) configured to issue triggers, for said first user, to act upon, in order to: o enable a smart contract between said first user and said system in relation to said stored data token (TKN) upon successful verification by said verification module (VFM) in response to request from said Data Token Verification Module (DTVM), o display data to said second user, in response to submission and verification of said user-correlative non-fungible token (NFT)based on privacy settings enabled by said first user basis said smart contract;- thereby enabling handshake between said Proof of Truth and said Source of Truth before displaying data, or portion thereof, of said first user to said second user.

2. The system as claimed in claim 1 wherein, said app-adapter system being configured to receive and process transactions asynchronously via a public API endpoint, said app-adapter system being managing tokenization requests and interacting with said blockchain system to initiate the validation and tokenization process.

3. The system as claimed in claim 1 wherein, said app-adapter system being configured to engage after receiving a tokenization request, from said first user, from the app-adapter system, the system sends the request asynchronously to the Source of Truth in order to validate the request and issues a unique Digital Signature as a form of proof, confirming the transaction's validity to form Proof of Truth, said Proof of Truth being transmitted back to said ledgerless blockchain for inclusion in corresponding transaction block, said transmission done using asynchronous / await modules, with built-in queuing logic, in order to allow non-blocking execution.

4. The system as claimed in claim 1 wherein, said app-adapter system configured to send user information and data to Source of Truth for validation and upon confirmation, a unique Digital signature and validation evidence being transmitted to said system’s ledgerless blockchain as Proofof Truth, said transmission done using asynchronous / await modules, with built-in queuing logic, in order to allow non-blocking execution..

5. The system as claimed in claim 1 wherein, said Data Token Generation Module (DTGM) comprising an input module (IPM) configured with at least a capturing module (CPM) configured to capture data that is to be tokenized, in that, said input module (IPM) being configured with a token generation module (TGM) configured to generate a data token (TKN) correlative to the captured data (101) through said capturing module (CPM).

6. The system as claimed in claim 1 wherein, said token generation module (TGM) being configured such that, for a given data token (TKN) used by this invention, only one transaction per block is allowed.

7. The system as claimed in claim 1 wherein, said data tokens (TKN) being user-correlative data tokens that employ double encryption mechanisms.

8. The system of claim 1, wherein:- said Identity Token Generation Module (ITGM) further comprises a mining engine programmed to process one request or transaction at a time, generating a new block for each transaction, thus prohibiting multiple transactions from being bundled into a single block.

9. The system of claim 1, wherein:- said first encryption module (ECPI) creates a block identity (BI) correlated to the user’s encrypted data token (TKN), which functions as an identity for each block.

10. The system of claim 1, further comprising:- said second encryption module (ECP2) that encrypts the encrypted data (ED) to generate a user-correlative non-fungible token (NFT), which is provided to the user for future verification.

11. The system as claimed in claim 1 wherein, said Data Token Verification Module (DTVM) comprising:- a service request module (SRM) configured to allow a second user, with a user-correlative non-fungible token (NFT), to input their own user-correlative non-fungible token (NFT); and- a communicably coupled non-fungible token verification module (NFTVM) configured to relay said second user’s submitted token (NFT) to said system.

12. The system as claimed in claim 1 wherein, said Data Token Verification Module (DTVM) being communicably coupled to a display module (DPM) configured to check said first user’ s pre-defined privacy settings, and correlative to these privacy settings, data, per submitted token (NFT), is displayed, through said display module (DPM) to the extent of settings determined by said privacy settings.

13. Ledger-less blockchain methods for data management and tokenization, said method comprising the steps of:- receiving a tokenization request, from a first user, concerning data, via a capturing module (CPM);- capturing said data to be tokenized;- storing said data, in a blockchain, such that there is only one transaction per block of said blockchain;- generating a user-correlative data token (TKN) through a token generation module (TGM), using a first encryption module (ECPI) and a second encryption module (ECP2), for encrypting said captured data, said generated token (TKN) being Source of Truth;- storing the encrypted data in a single block of the blockchain system, wherein each block contains only one transaction;- validating said request using an external Proof of Truth system by a verification module (VFM) configured to, authentically, verify data (101) that is to be tokenized, before generating a correlative data token (TKN), in order to conform to it being said Source of Truth;- decrypting said encrypted data, per block, based on request from a Data Token Verification Module (DTVM), said decryption to, in a first instance, retrieving data corresponding to said second user’s submitted token (NFT) and configured to, in a second instance, decrypting the retrieved data in order to obtain data from its corresponding usercorrelative data token (TKN), from a block of said blockchain, said decrypted retrieved data being Proof of Truth;- creating a blockchain block for the validated transaction, wherein the block is stored in a virtual memory and linked via cryptographic hashes;- engaging asynchronously, via an app-adapter system configured with an asynchronous-await module;- queuing user transactions using said asynchronous-await module, wherein each transaction is processed sequentially by the system's engine, and a new block, with decrypted data, is created for eachtransaction after traversing existing blocks to verify uniqueness and integrity;- enabling a smart contract between said first user and said system in relation to said stored data token (TKN) upon successful verification by said verification module (VFM) in response to request from said Data Token Verification Module (DTVM); and- displaying data to said second user, in response to submission and verification of said user-correlative non-fungible token (NFT) based on privacy settings enabled by said first user basis said smart contract; thereby enabling handshake between said Proof of Truth and said Source of Truth before displaying data, or portion thereof, of said first user to said second user.

14. The method as claimed in claim 1, wherein said method processes one transaction per block in a synchronous manner.

15. The method as claimed in claim 1, wherein a method for generating a token, comprising:- hashing a blockchain block using the encryption mechanisms;- encrypting the block's hash using encryption mechanisms; and- issuing the encrypted hash as the token (TKN).

16. The method of claim 1, further comprising:- issuing a smart contract via a smart contract module (SCM) upon successful verification of the user’ s identity, enabling transactions related to the user-correlative identity token (TKN).

17. The method of claim 1, further comprising:- generating a user-correlative non-fungible token (NFT) by encrypting the encrypted identity (El) using a second encryption module (ECP2), wherein the NFT is provided to the first user for future identity validation.

18. A method for validating an identity token in a ledger-less blockchain system, comprising the steps of:- receiving a user-correlative non-fungible token (NFT) through a service request module (SRM);- decrypting the NFT via a decryption module (DCP) to retrieve identity data stored in the corresponding block; and a. displaying the decrypted identity data according to the user's predefined privacy settings via a display module (DPM).

19. The method as claimed in claim 1, wherein, said step of verification, being configured to:- receive a user-correlative non-fungible token (NFT) submitted by said second user;- decrypt the token via a decryption module (DCP) to obtain identity data stored in a corresponding block of the blockchain system; and- traverse blocks of the system to retrieve and verify the decrypted identity data.

20. The method as claimed in claim 1 wherein, each block’s hash identity being transmitted to said app-adapter system, in that, said app-adapter system being configured to encrypt said hash identity per block to generate saidtoken (TKN) with its encryption key being maintained by said app-adapter system and configured to be transmitted to said first user upon generation of said token (TKN).

Images