IL318438B2 - System and method for creating digital asset transactions with encoded details about the purpose of the transfer - Google Patents

Description

SYSTEM AND METHOD FOR CREATING DIGITAL ASSET TRANSACTIONS WITH ENCODED DETAILS ABOUT THE PURPOSE OF THE TRANSFER FIELD OF THE INVENTION

[0001] The invention relates generally to the field of digital assets, and more specifically, to methods and systems for creating digital asset transaction with data encoded therein.

BACKGROUND

[0002] Digital asset or digital information associated with value (e.g., monetary) have increasingly permeated various business domains. In some cases, digital assets serve as a form of virtual currency within loyalty programs were used with Loyalty Points such as airlines, hotels, and retailers often issue points to customers that can be redeemed for discounts, upgrades, or free products and services.

[0003] Digital assets, are intrinsically tied to the protocols governing their exchange and usage. This close coupling makes it challenging to separate the asset itself from the mechanisms and methods used to trade or transact with it. For example: Bitcoin is not just a digital coin but also a decentralized protocol that governs its creation, transfer, and storage. The Bitcoin blockchain, a peer-to-peer network, uses cryptographic algorithms and consensus mechanisms (like Proof of Work) to validate transactions and secure the network. Also, Ether (ETH) is the native cryptocurrency of the Ethereum blockchain, which serves as both a digital coin and "gas" for executing transactions on the network. The Ethereum protocol governs how ETH is used to pay for computational resources required for decentralized applications.

SUMMARY

[0004] The following embodiments and aspects thereof are described and illustrated in conjunction with systems, tools and methods which are meant to be exemplary and illustrative, not limiting in scope.

[0005] There is provided, in an embodiment a system comprising a non-transitory computer-readable storage medium having stored thereon program instructions executable for creating a digital asset transaction, the program instructions executable by at least one hardware processor to: obtain one or more details related to a transfer purpose of the transaction, encode at least part of the obtained details according to a data structure of the transaction and integrate said encoded details into one or more fields of the transaction data as part of the transaction creation, wherein the encoding and integration processes are configured to preserve the original transaction data structure, and wherein said encoded details are interpretable by a receiving entity to execute a corresponding action related to the transfer purpose of the digital asset, transfer the created transaction to the receiving entity.

[0006] In one aspect of the present disclosure, the program instructions are further executable to select the details related to the transfer purpose from the group consisting of: timestamp, device identifier, transaction-specific information, confirmation code, authentication information, and verification code.

[0007] In one aspect of the present disclosure, the action is selected from the group consisting of: activating or unlocking a service, executing a smart contract function, initiating a cryptographic verification or compliance check, triggering an automated device operation, dispensing, or providing a product, a gate, recording transaction-related data for audit or logging, and performing an operation aligned with the intended purpose of the digital asset.

[0008] In one aspect of the present disclosure, the program instructions are further executable to integrate the encoded details in a manner that ensures compatibility with a communication protocol that supports the original asset data structure.

[0009] In one aspect of the present disclosure, the program instructions are further executable to integrate the encoded details into one or more decimal places of the monetary amount of the digital asset.

[0010] In one aspect of the present disclosure, the program instructions are further executable to integrate the encoded details into one or more places of the payload of a valueless Token.

[0011] In one aspect of the present disclosure, the program instructions are further executable to integrate the encoded details while maintaining the lengths, and expected data types of the digital asset payment value.

[0012] In one aspect of the present disclosure, the program instructions are further executable to encode the details in an agreed-upon format, thereby the encoded details are interpretable the receiving entities.

[0013] In one aspect of the present disclosure, the program instructions are further executable to encode the details such that the receiving entity interprets the encoded details and executes the corresponding actions prior to any additional approval of the transaction.

[0014] In one aspect of the present disclosure, the program instructions are further executable to transfer said created transaction through sending a notification to pull said created transaction, which comprises both data and code, to the receiving entity.

[0015] In one aspect of the present disclosure, the program instructions are further executable to encode and integrate a cryptographic proof into one or more decimal places of the monetary amount of the digital asset.

[0016] There is provided, in an embodiment, a method for creating a digital asset transaction, the method comprising: obtaining one or more details related to a transfer purpose of the transaction, encoding at least part of the obtained details according to a data structure of the transaction, and integrating the encoded details into one or more fields of the transaction data as part of the transaction creation, wherein the encoding and integration are configured to preserve the original transaction data structure, wherein the encoded details are interpretable by a receiving entity for executing a corresponding action related to the transfer purpose of the digital asset, and transferring the created transaction to the receiving entity.

[0017] There is provided, in an embodiment, a method for creating a digital asset transaction using a received designated code, the method comprising, receiving a designated code associated with the transaction, encoding the received designated code within transaction data, encoding the designated code within the transaction data, creating the transaction with the designated code integrated into one or more fields of the transaction data, wherein the encoded designated code is interpretable by a receiving entity for executing one or more corresponding actions related to the transfer purpose of the digital asset transaction, transferring the digital asset transaction to the receiving entity, and receiving, from the receiving entity, a response containing the encoded designated code and performing the corresponding action.

BRIEF DESCRIPTION OF THE FIGURES

[0018] Exemplary embodiments are illustrated in referenced figures. Dimensions of components and features shown in the figures are generally chosen for convenience and clarity of presentation and are not necessarily shown to scale. The figures are listed below.

[0019] Fig. 1 depicts a method for encoding and integrating details into a digital asset transaction data, according to an exemplary embodiment of the present disclosure;

[0020] Fig. 2 is a schematic depiction of a system, in accordance with some exemplary embodiments of the present disclosure;

[0021] Fig. 3 depicts a method for integrating a designated code encoded according to the digital asset transaction data structure, according to exemplary embodiment of the present disclosure;

[0022] Fig. 4 a diagram illustrating the interaction of several devices involved in the digital asset transfer, according to exemplary embodiment of the present disclosure; and

[0023] Fig. 5 illustrates a method for executing a payment process involving digital assets, according to exemplary embodiments of the present disclosure.

DETAILED DESCRIPTION

[0024] The present disclosure, in some embodiments thereof, provides a system and method for creating a digital asset transaction integrated with encoded details related to the transfer purpose of the digital asset, while preserving the original transaction data structure format.

[0025] In some embodiments, the encoded details are, at least in part, related to the specific intended purpose, objectives or conditions of the transaction involving the digital asset.

[0026] The term “digital asset” as used herein, refers to any form of payment instruments existing in a digital format, stored, transferred, and managed electronically. A digital asset may comprise a digital representation of value that can be digitally traded, transferred, or used for payment or investment purposes, as well as non-monetary representations such as access rights, or access to product or service. A digital asset can include, but is not limited to, digital coins, digital money, electronic money, electronic currency, cryptocurrency, stablecoins, Central Bank Digital Coins (CBDCs), virtual currencies, fiat currency, a digital representation of monetary value, and Tokens (with or without monetary amount). A digital asset has an associated value and is subject to rules or protocols governing their use, ownership, and transfer.

[0027] The expression "original transaction data structure" as used in the present disclosure, refers to the native configuration and schema that define the organization of transaction data in its state prior to any alterations. This native configuration and schema include the specific arrangement of data fields, metadata, payload fields, and fields of the monetary amount that dictate how the asset is stored, accessed, managed, and utilized within the respective digital environment thereof.

[0028] In some embodiments, the present disclosure provides a system and method for encoding details related to the transfer purpose or use of the digital asset according to the data structure of the transaction and integrating the encoded details into the transaction's data while preserving the fidelity of its original format.

[0029] Thus, in some embodiments, such integration and encoding processes preserve the compatibility with industry-standard communication protocols and enable seamless integration into business functions such as transferring, storing, or managing digital assets, without disrupting the transparency or usability of the transfer.

[0030] The terms “encoding” or “encode” as used in the present disclosure, refer to the process of converting data or details into a specific format using a predefined scheme, facilitating efficient transmission or storage. The converting process typically involves transforming a sequence of characters such as letters, numbers, punctuation, and symbols, into a format that is recognizable and interpretable by both the transmitting and receiving entities.

[0031] The terms “decoding” or “decode” refer to the reverse process, wherein the encoded data or details are converted back into their original form or a meaningful representation that the receiving entity can interpret, utilize, or act upon.

[0032] In some embodiments, the encoded details are in an agreed-upon format, ensuring interpretability by both, the transmitting and receiving entities. In some embodiments, the agreed-upon format is configured to enable a receiving entity to execute a corresponding action related to the intended purpose of the transfer, while preserving the integrity of the entire data structure of the transaction. Additionally, in some embodiments, the agreed-upon format ensures that the encoded details remain transparent to other parties involved in the transfer.

[0033] In some embodiments, the encoded details comprise the transaction monetary amount, verification details, and in some cases, at least some of the encoded details are related to the specific purpose of the transfer of the digital asset transaction. For example, in case wherein a digital asset is related to the purchase of goods, services, or the execution of a smart contract, the encoded details integrated into the transaction data may vary depending on the purpose of the digital asset transfer, or in some cases, the specific method of transfer.

[0034] Smart contracts are self-executing agreements with the terms directly written into code, and they can be used in a wide range of applications. Smart contracts are widely used in blockchain ecosystems, such as, but not limited to, facilitating transactions in cryptocurrencies, managing NFTs, or handling the issuance and transfer of Tokens, and the like.

[0035] In some embodiments, the encoding process of the transaction data modifies the monetary amount (value associated with a digital asset) of the digital asset, without altering field names, lengths, or the internal structure of the field content. In some embodiments, the encoding process of the transaction data modifies other fields in the transaction data structure without altering field names, lengths, or internal structure of the field content.

[0036] In some embodiments, the integration of the encoded details is part of the transaction creation step, in the transfer process. In some embodiments, creating a transaction with the encoded details by the transferring entity (e.g., payee), enables the incorporation of information about additional processes, such as verification or the execution of specific actions, without requiring additional communication channels between the transferring and receiving entities.

[0037] The term “transfer” as used in the present disclosure refers to the act of moving a digital asset from a transferring entity (also called a sender or a payer) to a receiving entity (also called a recipient or a payee). The transfer can involve the initiation of the transfer by the transferring entity (e.g., a Request to Pay also known as RTP), followed by the encoding of details related to the transfer purpose and which may include asset type, quantity, and identifiers, transferor (payer), transferee (payee), conditions, timestamps, and the like, for one or both transferring and receiving entities. The details can then be integrated into the transaction data, and a digital asset transaction is created, based on the encoded details. In some embodiments, based on the transfer purpose, the transfer can comprise the subsequent validation, confirmation, and recording of the asset's movement to the receiving entity. The transfer is concluded when the receiving entity either receives a notification to pull the transaction, which includes both data and code, or when the receiving entity receives, possesses, and gains control of the digital asset.

[0038] In some embodiments, the purpose of a transfer is to enable the seamless execution of various actions tied to the transfer purpose of the digital asset. In some embodiments, such purpose comprises one or more of, activating or unlocking a service (such as in IoT - Internet of Things), executing a smart contract function, initiating a cryptographic verification or compliance check, triggering an automated device operation, dispensing, or providing a product (e.g., in a vending machine), opening a gate, and recording transaction-related data for audit or logging.

[0039] In some embodiments, the details related to the purpose of a transfer can comprise one or more of the following: verification codes, a timestamp, an authentication key, device identifiers, transaction-specific data or information, a confirmation code, and the like.

[0040] In some embodiments, a verification code supports a verification process that employs a technique to confirm the authenticity, validity, or legitimacy of a transaction, the identity of the user or recipient, and/or the ownership of a specific digital asset. For example, this process may verify both the authenticity of the transaction and the identities of the parties involved.

[0041] In some embodiments, the transaction-specific information comprising instructions related to the digital asset transfer purpose, or to the intended purpose of the digital asset transfer which, by way of example, can involve dispensing a product in a vending machine, activating a service or IoT device, calculating and finalizing a toll payment, configuring, and executing smart contracts, dispensing cash at an automatic teller machine (ATM) upon validation, and the like.

[0042] In some embodiments, the encoded details integrated into the transaction data can be used for ensuring security and/or anonymity, depending on the desired configuration. In some cases, the encoded details can be utilized for triggering predefined actions or verifying transactions (see Fig. 1 steps 110 and 115 further below).

[0043] In some embodiments, the encoded details integrated into the transaction data further comprise transaction instructions, related to the purpose of the transfer of the digital asset transaction (see Fig. 1 and Fig. 3 further below).

[0044] In some embodiments, the present disclosure provides for encoding and/or integrating details into the digital asset transaction data, e.g., adding or changing the value during the creation of the digital asset transaction. In some embodiments, such a change in the value is insignificant to the payee.

[0045] In some embodiments, the transaction data comprises payload data e.g., Digital Asset Type, Asset Quantity, Transfer Details, and the like, and metadata e.g., Transaction ID, Timestamp, Sender ID, and the like. In some embodiments, the transaction comprises a monetary amount, and in others it may not.

[0046] In some embodiments, the present disclosure provides for encoding and/or integrating details into the digital asset by a system or a primary system, e.g., a wallet or a master wallet, that manages and controls the assets or funds of a user or entity, e.g., Merchant/Service Provider/Business ("M/SP/B").

[0047] The term “wallet” or any form of thereof such as sub-wallet, parent wallet, master wallet, e-wallet, and the like, which is used herein, refers to a digital wallet.

[0048] In accordance with an aspect of the present disclosure, a system and method are provided that can be employed for avoiding the separation of communication channels when transmitting data alongside payments. Thus, often-ignored data points in the original transaction data structure of the digital asset, e.g., the decimal places in the value of the Digital Assets or Tokens can carry meaningful data, thereby converting a standard payment into a smart payment.

[0049] In some embodiments, such smart payment involves integrating executable instructions within the transaction data to automate specific actions upon receipt. These instructions may comprise verification codes, for verification process, and/or machine commands. Furthermore, in some embodiments, the executable instructions can cancel the digital asset transfer if one or more predefined conditions are not satisfied.

[0050] In some embodiments, the present disclosure provides a system and method for creating transactions with integrated details related to the purpose of a transfer. In some embodiments, in this scenario, a full compatibility is preserved with existing ledger, blockchain, or payment infrastructure rules.

[0051] The present disclosure is not limited to the embodiments described above, but it can be realized, modified, and indicated in examples described further below.

[0052] Reference is made to Fig. 1 which depicts a method for encoding and integrating details into a digital asset transaction data, according to an exemplary embodiment of the present disclosure.

[0053] In step 105, a sender (also referred to as a transmitting entity) is obtaining information comprising details required to initiate a transfer of a digital asset transaction.

[0054] In some embodiments, the sender is an automated machine incorporating at least a part of system 200 and the components thereof.

[0055] In some embodiments, at least part of the information is received through an RTP from a payer seeking to initiate a digital payment. In some cases, the sender may also be the payer, operating a system or a computerized device (e.g., system 200 or computerized device 430, as described further below).

[0056] In some cases, the obtained details comprise the 1) value for payment in digital asset, and 2) transaction details, description of products or services, metadata, and additional instructions.

[0057] In some embodiments, the sender obtained information comprising one or more of the following: - Information, such as: encryption key, or ID (e.g., public key or wallet address) of the recipient of the transaction.

- Amount: The quantity of the digital asset to be transferred.

- Optional Details: Characters of product/ service, fees, or any other additional data, such as those required for the transaction.

- Additional Verification Data: Such as asset multi-factor authentication (MFA), biometric data or one-time passwords, to enhance security.

- Asset Type: Specifies the digital asset used (e.g., Bitcoin, Ethereum, USDC).

[0058] In some embodiments, the sender can obtain from the received information, details such as, asset/content type, licensing terms, details specifying how the asset can be used, product name, geolocation keywords, and the like.

[0059] In some embodiments, the received information includes a portion of the details necessary to execute the transfer of the digital asset, while the remaining details are completed by the sender. For example, the sender may retrieve missing details from data stored within an internal component or subsystem of the sender, which is configured to supply such details.

[0060] In some embodiments, in case of a digital asset, the received information comprises details such as a product specific, a service name, a request-to-pay (referred as an RTP), or a cryptographic verification parameter.

[0061] In some embodiments, the sender can also select some of the details from an advertised list (e.g., on the internet) provided by a seller/service provider (e.g., the recipient). In some embodiments, the details can be provided to a device connected via IOT allowing the machine to determine the code to integrate and the monetary amount of the transaction.

In some embodiments, at step 105 the sender may execute preliminary validations to ensure that at least some of the details required to initiate the transfer are existed and appear valid.

[0062] In step 110, the sender encodes the details required to initiate the digital asset transfer according to the transaction data structure, thereby generating one or more strings that can be integrated into the data of the transaction. The encoding process, in some embodiments, involves defining specific data fields and performing necessary transformations to adapt the details for the integration.

[0063] In some embodiments, the encoding process of the details can add authentication information or other relevant data integrated into fields of the digital asset data transaction such as the decimal places of a digital asset payment or payload in case of a Token.

[0064] In some embodiments, the encoded details are, at least in part, related to the specific objectives, action, purpose, characteristics, or conditions of the transaction involving the digital asset.

[0065] For example, a product of a vending machine can be presented to a person with a unique barcode containing parameters such as a product price (e.g., 5.00 DC), product identifier in decimal places (e.g., 000001). Thus, the monetary amount of the transaction is set to be 5.00000001. In such an example, the monetary amount of the transaction is utilized to carry details related to the transfer purpose (purchase a specific product).

[0066] In another exemplary case, a payment of 0.12345678 USDT could carry the integrated details: 0.12 representing the paid amount (e.g., for HIPA ventilation service), representing a machine command or data point (e.g., device ID, verification code), and 56representing additional data (e.g., VM location). Thus, such an approach ensures that the fractional part of the payment is not solely used for monetary precision but also as a carrier of essential transactional data, e.g., details of the service which the payment is seeking for.

[0067] Further example can be embodied in cryptocurrencies (e.g., Bitcoin, Ethereum, USDT) with data fields such as: invoice No., customer ID, Timestamp, Transaction Inputs and Outputs, Block Height, and Hash Values which remain in their original structure. In such an example, the encoding process modifies one or more values within these fields or adjusts the monetary amount without altering and/or adding field names, content lengths, or internal structure of the field content. In such example, protocols such as Proof-of-Work (PoW), or Ethereum Virtual Machine (EVM) can still maintain and handle the transaction while ensuring compatibility with any existing systems, e.g., a third-party system involved in the transfer.

[0068] In another exemplary embodiment, in a Token transaction format, the transaction creation process integrates the encoded details, while adhering to the Token data structure. In some embodiments, this Token format, data fields such as Token Identifier and Owner Address, along with metadata fields remain in their original structure. These embodiments may be useful when the recorded timing of the information is important to preserve its integrity (compliance, accounting, law-enforcement orders, etc.).

[0069] In some embodiments, the encoding process modifies one or more values of the fields or, in some cases adjusts the monetary amount, without altering field names, lengths, or internal structure of the field content, enabling standard protocols, e.g., ERC-(Ethereum Request for Comments 20), to handle the transaction while ensuring compatibility with existing systems, e.g., third-party systems.

[0070] In another exemplary embodiment, the present disclosure enables the transfer of details within transactions in the format of Central Bank Digital Coins (CBDCs). This includes applications such as micro-payments, offline payments, online payments, anonymous payments, and more. Such capabilities extend the utility of CBDCs beyond what is possible with traditional forms of fiat money currently issued by central banks.

[0071] In some embodiments, the approach, exposed herein, allows various protocols, which may vary by country, operator, or business unit, to handle the transaction while ensuring compatibility with existing financial systems.

[0072] In some embodiments, the fractional decimal places of a digital asset's monetary amount are used to carry transactional data. Such an approach effectively leverages the existing payment infrastructure, allowing it to function as a dual-purpose channel for both monetary transfer and data transmission. Examples of transactional data encoded and integrated into the decimal places can comprise, alongside the monetary value, information such as a certain amount for toll payments (in a locked-payment plan, as elaborated further below), device category, exit point (e.g., a toll road exit point), machine-specific commands, and the like.

[0073] In some embodiments, the locked-payment plan enables the locking of a specified amount to facilitate future payments, such as toll road payments. In some embodiments, under this plan, a registered payer provides payment details and makes an initial deposit, which locks a designated amount specifically for toll road transactions. In some embodiments, any unused balance may either roll over for future use or be refunded upon termination of the plan.

[0074] In step 115, the sender integrates the encoded details into at least part of the fields of the transaction data structure, while adhering to the original transaction data structure, hereby preserving the original format.

[0075] In some embodiments, the digital asset and the transaction are determined based on an RTP, and the encoded details are integrated into the fields of the transaction data structure, determined by the format of the transaction type.

[0076] In some embodiments, the sender integrates the encoded details into the monetary amount field, at the decimal places or the payload of valueless Tokens, of the transaction data.

[0077] In step 120, a transaction is created by the sender with at least part of the integrated encoded details previously prepared, while adhering to the predefined format and constraints of the applicable protocol (e.g., ERC-20 for Tokens or PoW for cryptocurrencies).

[0078] In some embodiments, creating the transaction involve generating specific digital representations of the transaction (e.g., a transferable code or a script) and, in some cases, signing the transaction with a digital signing process.

[0079] In some embodiments, the transaction is created by the sender which adheres to a specific type of digital assets adapted to be governed by specific rules or protocols concerning their use, ownership, and transfer. In some embodiments, the sender can create a transaction which adheres to the predefined format and organizational rules of the digital asset.

[0080] In step 125, the sender transfers the digital asset by sending the transaction to a recipient (also referred to as a receiving entity). In some embodiments, the recipient may be validated before transmitting. For example, a public key used to validate the recipient identity.

[0081] In step 130, the recipient receives the transaction. In some embodiments, the encoded details are decoded.

[0082] In some embodiments, the recipient interprets the received transaction details, metadata and / or the additional instructions for the purpose of executing one or more actions.

[0083] In some embodiments, sender sends a notification indicating that the transaction is available to be pulled, for example, in a pull-mode as described further below.

[0084] In some embodiments, additional operations, such as a verification process or other forms of validation, may be performed by the recipient upon interpreting the encoded details. For example, if the transaction involves a smart contract, the parties may validate the conditions before executing the contract.

[0085] In some embodiments, the decimal value contains the “activator” to the smart contract, diminishing the need in human intervention.

[0086] In some embodiments, such as smart contract is a self-executing program that automates the execution of contract terms, e.g., directly on a blockchain, once predefined conditions are met.

[0087] In step 135, an act based on the interpreted encoded details from the transaction is performed. In some embodiments, the action is related to the transfer purpose of the digital asset transaction, as aforementioned. For example, if the transaction involves transferring a digital asset for a specific service (e.g., vending machine operation), the recipient can interpret the instructions and trigger the related action (e.g., dispensing the chosen product, as encode to the payment load).

[0088] In some embodiments, the method depicted in Fig. 1 facilitates multiple transactions, remaining agnostic to specific protocols or communication methods. Thus, such an approach can enable the integration of digital asset transactions with various industry standards and protocols that were not originally designed for such purposes, without necessitating any modifications to those standards or protocols.

[0089] In some embodiments, the present disclosure provides for transmitting transaction-related details and verification data (also known as verification code) as a part of the digital asset, e.g., in DC (digital coin).

[0090] For example, in Cryptographic Verification Code case, the monetary amount (e.g., 5.05, 50.10, 100.00 DC) can be utilized for carrying encoded and integrated details. In this example:

[0091] In case of CBDC or Stablecoins the structure of the field content is: [Main Amount].[YYXXXXXX] o The first two (2) decimal places denoted as YY are reserved for payment precision o The last six (6) decimal places in the filed content denoted as XXXXXX carry Data Transmission Details.

[0092] As for the example above, in case of Crypto assets: The implementation varies based on smallest tradeable unit.

[0093] In this example, at least some of the decimal places can also be utilized to transmit cryptographic proof or Cryptographic Verification Code.

[0094] In some embodiments, the Cryptographic Verification Code enables secure transmission of verification data through payment decimal places, allowing organizations to combine payment and verification in a single transaction.

[0095] In some embodiments, the present disclosure enables transmitting cryptographic proofs which verify specific conditions or states, such as document timestamps, digital signatures, membership status, authentication codes and/or the like.

[0096] For example, in case of a user requiring to prove document existence at a specific time, instead of using separate channels for payment and verification, a single payment can be sent, wherein the main amount represents the service fee and the decimal places carry the cryptographic proof. Thus, a record of both the payment and the verification can be created, while the proof is permanently recorded in the payment's decimal places on the blockchain/ledger. This exemplary case supports various types of cryptographic proofs while decimal places (the decimals reserved for monetary value) are used to transmit cryptographic proofs as aforementioned.

[0097] In some embodiments, the cryptographic proof refers to a mechanism that uses cryptographic algorithms to verify the authenticity or integrity of a transaction, asset, or identity, without revealing the underlying data. In some embodiments, such cryptographic proof can be a digital signature, a zero-knowledge proof (ZKP), a hash key, a public key, and the like.

[0098] Reference is made to Fig. 2, which is a schematic depiction of a system, in accordance with some exemplary embodiments of the present disclosure.

[0099] Fig. 2 shows a system 200 as described herein is only an exemplary embodiment of the present disclosure, and in practice may have more or fewer components than shown, may combine two or more of the components, or a may have a different configuration or arrangement of the components. The various components of system 200 may be implemented in hardware, software, or a combination of both hardware and software.

[00100] In some embodiments, system 200 comprises at least one or more processing unit 205, a memory unit 210, storage system 215, a communication controller 220, encoding module 225, cryptographic module 230, data validation module 235, transaction management module 240, logging & auditing module 245, and user interface module 250.

[00101] In some embodiments, system 200 may store in a non-volatile memory thereof, such as storage system 215, software instructions or components configured to operate a processing unit (also "hardware processor," "CPU," or simply "processor"), such as processing unit 205.

[00102] In some embodiments, the software components may include an operating system, including various software components and/or drivers for controlling and managing general system tasks (e.g., memory management, storage system control, power management, etc.) and facilitating communication between various hardware and software components.

[00103] In some exemplary embodiments, the processing unit 205, the memory unit 210, the storage system 215, and the communication controller 220 are provided by an external computerized device on which the system 200 is operated. In some embodiments, the processing unit 205, the memory unit 210, the storage system 220, can be virtualized resources provided by virtualization computerized resources.

[00104] In some embodiments, system 200 is a standalone computer, or a server designed to handle multiple users implementing computing methods. In some embodiments, the software instructions or components configured to operate a processing unit 205 comprising, program instructions required for the operations of managing, storing, creating and control a digital asset transfer, encoding transfer related data, integrating transfer related data, and creating a digital asset transaction, the program instructions executable by at least one hardware processor, and the like.

[00105] In some embodiments, the processing unit 205 is configured to execute the encoding instructions, manage data stored in storage system 215, and communicates with other components of the system 200. In some embodiments, processing unit 205 is configured to process and execute program instructions that govern the encoding of transfer-related data into the digital asset transaction data.

[00106] In some embodiments, the storage system 215 is adapted to store at least part of the received and computed data, including digital asset information, encoded details, transaction logs, and instructions. In some embodiments, memory unit 210 comprises a Non-volatile memory (e.g., Flash, EEPROM) to ensure that the data persists even after power is lost.

[00107] In some embodiments, the encoding module 225 is a dedicated hardware or software module responsible for encoding the data within the digital asset structure. encoding module 225 can apply the specific encoding rules or formats for the asset (e.g., cryptocurrency, Token, or other digital asset types). In some embodiments, encoding module 225 encodes the transaction data (such as the digital asset's value and related instructions as aforementioned) according to the transaction data structure format. In some embodiments, encoding module 225 is configured to utilize cryptographic algorithms, data compression techniques, and serialization methods for the purpose of encoding transaction data and / or details into the field values of the transaction data.

[00108] In some embodiments, the cryptographic module 230 is configured to provide encryption and decryption functionalities to secure data during encoding and / or transmission. In some embodiments, the cryptographic module 230 handles the cryptographic processes necessary to ensure confidentiality, integrity, and authenticity of digital asset transactions.

[00109] In some embodiments, cryptographic module 230 is configured to encrypt the transaction data or digital asset monetary amount within the data structure to prevent tampering or unauthorized access. In some embodiments, cryptographic module 230 is configured is also sign transactions or data packets to verify the identity of the sender or asset holder.

[00110] In some embodiments, the communication controller 220 is configured to operate one or more methods and technologies to conduct the communications (wired, or wireless), e.g., communication based at least in part on wireless communication, e.g., Wi-Fi. In some embodiments, the communication controller 220 is configured to enables system 200 to communicate with other devices or systems (such as digital wallets, payment systems, or IoT devices). In some embodiments, the communication controller 220 supports communication protocols such as TCP/IP, MQTT, NFC, Bluetooth, QR code scanning, Barcode scanning, or other relevant standards for data transmission.

[00111] In some embodiments, the communication controller 220 is configured to allow system 200 to send digital asset transaction to another computerized device or server. In some embodiments, the communication controller 220 is configured to ensure that the digital asset transaction is transferred while using a compatible protocol, enabling interoperability with various systems in the industry.

[00112] In some embodiments, the transaction management module 240 is configured to handle the management of digital asset transactions, ensuring the correct execution of actions such as digital asset transfer, value assignment, and the associated business logic (e.g., dispensing goods, activating services).

[00113] In some embodiments, the transaction management module 240 is configured to integrate to encoded details into the transaction data. In some embodiments, such an integration is part of the transaction creation.

[00114] In some embodiments, the transaction management module 240 is configured to define the specific transaction rules for the digital asset and generates the required instructions, which are then encoded and inserted into the data of the transaction. In some embodiments, the transaction management module 240 is configured to validate transactions, check balances, and update records after successful encoding.

[00115] In some embodiments, the data validation module 235 is configured to ensure that the data encoded within the digital asset structure is valid and adheres to expected formats.

[00116] In some embodiments, the data validation module 235 is configured to execute checks to ensure that the encoded details (e.g., transaction values, instructions) are correctly structured and does not contain errors or inconsistencies.

[00117] In some embodiments, the data validation module 235 is configured to validate that the encoded details are well-formed, ensuring that no data corruption occurs during the encoding process. In some embodiments, such validation involves checksum validation or cryptographic hash checks. In some embodiments, such validation involves ensuring the data structure of the transaction adheres with the original transaction data structure format.

[00118] In some embodiments, the user interface module 250 is configured to an interface for the user to interact with system 200. In some embodiments, such interface could be through a display screen, buttons, or a software application that allows the user to view, modify, initiate, or approve digital asset transactions.

[00119] In some embodiments, the user interface module 250 is configured to act as a mid-layer infracting directly with a blockchain platform while performing the encoding before conveying the transaction request to the clearing engine (e.g., blockchain platform). For example, the user interface module 250 can be configured as application performs and manage an interface to interact with blockchain platforms that enable users to interact directly with smart contracts and digital assets.

[00120] In some embodiments, the user interface module 250 is configured to provide a CLIs (Command Layer Interface) offering a text-based interface to interact with blockchain networks, managing digital assets, and deploying or interacting with smart contracts.

[00121] In some embodiments, the user interface module 250 is configured to allow the user to input data related to the digital asset transfer, such as values, instructions, or transaction details. In some embodiments, the user interface module 250 can also allow the user to monitor the encoding process or approve transactions before they are finalized.

[00122] In some embodiments, the logging & auditing module 245 is configured to keep detailed logs and audit at least some trails of the transactions and encoding actions performed by the system 200. In some embodiments, the operations logging & auditing module 2comprises timestamped records of the data encoded, transactions executed, and any actions taken on the digital asset transfer data. In some embodiments, the the logging & auditing module 245 is configured to maintain an immutable record of the encoding processes for compliance, auditing, and security purposes.

[00123] In some embodiments, system 200 may be operated, at least in part, with a computerized device such as mobile phones or computerized tablets, IoT appliances, transportation vehicles, and the like.

[00124] In some embodiments, system 200 is used as a part of another system operating transactions and offering multiple business services to users while incorporating user and machine interface, machine to machine interface, or user to user interface, a peer to peer (also known as P2P). In some embodiments, system 200 can be configured to operate within a computerized device managing an automated business transactions conducted directly between devices without human intervention, streamlining processes and enhancing efficiency, e.g., Machine-to-Machine (also known as M2M).

[00125] In some embodiments, system 200 is used as a part of an IoT device management system allowing preforming transactions while the machine-to-machine protocol can operate the transaction without any additional adjustment for supporting the transfer process.

[00126] In some embodiments, system 200 provides for eliminating the need for separate communication channels when transmitting data integrated with the payments in a machine-to-machine (M2M) context. In some cases, traditional M2M communication protocols, e.g., MQTT or CoAP, typically require a dedicated channel for data transmission and a separate channel for payment processing. This requirement for separate communication channels can, in some cases, increase complexity, introduce latency, and reduce overall efficiency.

[00127] For example, in an application managed and controlled by a Toll Road Operator (TRO), the locked-payment plan enables the locking of a specified amount to facilitate future payments, along with encoded details. Such and exemplary case gives the TRO “built-in” data that enables TRO to plan the business and utilize details from the upfront additional data received from the user, such as: - Locked amount (e.g., 50.00) in a locked-payment scheme.

- Vehicle category (e.g., 02 for a standard car).

- Planned exit point (e.g., 031 for a specific exit).

[00128] Consequently, the data is encoded into the digital asset during the "lock payment" transaction. The encoded details are integrated into the decimal places of the digital asset (for example, 50.0000000231 DC). Thus, the system prepares the decimal places of the digital asset as follows: a) 50.00 represents the locked amount. b) 000 is reserved for future use (decimals may be utilized for additional data or transaction granularity). c) 02 denotes the vehicle category. d) 031 signifies the planned exit point.

[00129] In some embodiments, there is no need to encode and integrate the entry point since the payment transaction is sent to a specific digital wallet address.

[00130] In accordance with an aspect of the present disclosure there is provided a system 200 and method operable thereon for adding authentication information or any other relevant details or data into the decimal places or valueless Tokens payload of a digital asset transaction.

[00131] For example, when a vending machine receives a payment, the decimal portion of the payment could carry the machine-specific command, as well as authentication data to verify that the payment is legitimate and, in some cases, from a trusted source. In some embodiments, authentication data can add a layer of cryptographic verification to the transaction, ensuring both security and anonymity, depending on the desired configuration.

[00132] In some embodiments, the program instructions stored in system 200 and the components thereof are used to operate functionalities of a digital wallet, or a cryptocurrency wallet. In some embodiments, such instructions use an internet connection to access the blockchain network for the digital asset, e.g., by the communication controller 220.

[00133] In some embodiments, system 200, or a part of the components thereof is configured as a parent-wallet designed to function as the main account overseeing multiple sub-wallets, enabling comprehensive fund management, responsible for updating the global ledger and ensuring that balances are accurately tracked across at least some designated wallets, including one or more sub-wallets.

[00134] In some embodiments, system 200, or a part of the components thereof is configured as sub-wallet designed to function in a hierarchical structure of parent wallet and sub-wallet, wherein the sub-wallet can be configured for specific purposes or users, such as budgeting for particular expenses or managing allowances.

[00135] System 200, according to an aspect of the present disclosure, can operate on a plurality of different computing devices including but not limited to personal computers and mobile devices such as phones, personal digital assistants (PDAs), tablet camera, and the like.

[00136] In some embodiments, system 200 is a portable computerized device, e.g., a laptop PC, a tablet PC, and the like. In some embodiments, communication controller 220 may be configured to communicate with telecommunication networks, e.g., Internet Protocol-based network. In some embodiments, the communication controller 220 can be configured to operate the required hardware and software components for the purpose of communicating over telephone and/or satellite networks, e.g., Global System for Mobile Communications (GSM).

[00137] In some embodiments, the system 200 is configured to access the digital wallet of a user to determine the current balance. In some embodiments, such a determination is achieved by querying the blockchain or the relevant ledger where the transaction history of the user and balances are recorded. For examples, blockchain balancing check process or tools may be employed by system 200 to check the balance of a wallet address. Such a tool may be any computerized process operated by a computerized device, and/or application such a third-party application, a built-in method within the system, and the like.

[00138] In some embodiments, system 200 or at least some of the components thereof, can be configured to create or configure a transaction and/or a transfer of a digital asset such as a digital coin transaction, or a token transaction. In such cases, system 200 is configured, e.g., by the user interface module 250 to obtain information related to a transfer purpose of the digital coin, wherein the information comprises details regarding a product, a service, a request-to-pay, and/or a cryptographic verification parameter. In some embodiments, the details are obtained from information sent, at least in part, by either a payee or a payer seeking to initiate a digital payment process.

[00139] Further in this exemplary case, system 200 can be configured to store the details in a database or a storing area resides in storage system 215. System 200 can also be configured to encode, at least some of the details from the received information by encoding module 225. In some embodiments, the integrating process comprises one or more steps of inserting details into at least one part of the digital asset monetary amount fields, including decimal digits (if applicable) or Token quantity (if applicable), while preserving the data fields and the data structure thereof as aforementioned.

[00140] In some embodiments, system 200 is configured to ensure that the transaction remains compatible with existing payment schemes, rulebooks, ledger or blockchain protocols, such that one communication channel is used to transfer the traction.

[00141] Continuing with the example, system 200 and/or some of the components thereof can be configured to enable the transaction available to be obtained by a receiver, wherein the receiver can interpret the integrated encoded details for the purpose of executing or recording at least one corresponding action or data entry related to the transaction transfer. In some cases, additional metadata fields and/or external communication channels are not required.

[00142] In some embodiments, the corresponding action interpreted by the receiver is at least one of the following: activating or unlocking a service, executing a smart contract function, initiating a cryptographic verification or compliance check, triggering an automated device operation, dispensing or providing a product, opening a gate, recording transaction-related data for audit, and logging.

[00143] Reference is made to Fig. 3 depicting a method for integrating a designated code encoded according to the digital asset transaction data structure, according to exemplary embodiment of the present disclosure.

[00144] In step 305, a sender receives a designated code. In some embodiments, the designated code is received from a receiver. In some embodiments, the sender is system 2or a system operated by a person. In some embodiments, the sender is an automated machine.

[00145] In some embodiments, the designated code is obtained from an ASP or a PSP, as further illustrated below (see Fig. 5, ASP 465, PSP 440). The designated code may, in various embodiments, represent a verification code, a secure code associated with a contract, a contract type, instructions defining the transfer purpose of the digital asset, an interest rate applicable to a payment, an activation code to initiate a service or action, or any other code or string interpretable by the entities involved in the transfer.

[00146] In step 310, the designated code is encoded by the sender to generate one or more strings intended for integration into the transaction data. In some embodiments, the encoding process includes defining specific data fields and applying the necessary modifications.

[00147] In step 315, by the sender, a data is prepared and the encoded designated code is integrated into the fields of the transaction data structure of the digital asset and the transaction data field. In some embodiments, the integration process comprises update fields of the payload and/or the metadata. In some embodiments, the monetary amount is determined and the specific value containing the encoded designated code is determined and prepared.

[00148] In step 320 a transaction is created, by the sender, while using the updated values and/or content of the data fields, thereby forming the transaction associated with the digital asset.

[00149] In step 325, the transaction containing the designated code is transferred by either the sender or by the PSP per the sender order, over the network to the recipient. In some embodiments, the designated code is transferred to a clearing engine which credit the recipient.

[00150] In some embodiments, the recipient is within a separate telecommunication network, and/or separated digital asset network/blockchain. In some embodiments, adhering to industry standards can enhance interoperability between different systems, blockchains, networks, and computerized platforms.

[00151] In step 330, upon receiving the transaction, the recipient extracts and/or decodes the designated code, e.g., the verification code, from the transaction data, e.g., from the decimal places of the digital asset monetary amount and subsequently validates the designated code, according to the purpose of that designated code.

[00152] In some embodiments, error detection is performed by using checksum validation or cryptographic hash checks to identify corrupted data.

[00153] In step 335, the recipient is acting based on the designated purpose of the extracted and/or decoded code. For example, in case the designated code is a verification code, based on successful verification process the payment proceeds. In some exemplary cases, a product in a vending machine is provided, or a gate is opened, based on the designated code, and in some cases also based on the agreed-upon format of the encoding.

[00154] In some other exemplary cases, the code may be used by the recipient to verify the authenticity, ownership rights, or authorization of the transaction, ensuring the transaction has not been tampered with, ensuring that authorized sender conducted a specific action, and/or originates from a legitimate source. Additionally, the code may implement cryptographic method that enables one party to prove to another without revealing the information itself.

[00155] Furthermore, the code may implement cryptographic methods, such as Zero-Knowledge Proof (ZKP) technologies, which allow one party to prove information to another without disclosing the information itself. This enables the recipient to validate the transaction while maintaining the confidentiality of the underlying data.

[00156] In some embodiments, the code may facilitate actions such as providing a product, opening a gate, or performing an operation aligned with the intended purpose of the digital asset transfer.

[00157] In some embodiments, the method in Fig. 3 enables a process to align with practices in digital asset management where authentication information integrated into the transaction data facilitates seamless verification processes.

[00158] Reference is made to Fig. 4, which shows a diagram illustrating the interaction of several devices involved in the digital asset transfer, according to exemplary embodiment of the present disclosure.

[00159] Fig. 4 shows a system 400 comprises a POS 420, a computerized device 430, a PSP 440, and an ASP 465, wherein POS refers to Point of Sales, PSP refers to Payment Service Provider, and ASP refers to Additional Service Provider. System 400 demonstrates a system or platform designed to facilitate the processing of digital asset transfers, such as payments or exchanges, for purposes such as purchasing goods or services. In some cases, System 400 is integrated with third-party services to ensure secure and efficient transactions are operated to complete the transfer.

[00160] System 400 as described herein is only an exemplary embodiment of the present disclosure, and in practice may have more or fewer components than shown, may combine two or more of the components, or a may have a different configuration or arrangement of the components. The various components of system 400 may be implemented in hardware, software, or a combination of both hardware and software.

[00161] In some embodiments, POS 420, PSP 440, ASP 465 and/or computerized device 430 may integrate with and/or operate based on system 200 or certain components thereof. In some embodiments, additional components, e.g., an ATM, may be incorporated into system 400 to support various use cases, systems, and/or methods implemented to facilitate at least part of the functionality described in the present disclosure.

[00162] In some embodiments, ASP 465 is configured to provide software applications and services, which computers, computerized devices, payers, or users can access the PSPs payments services over the internet.

[00163] In some embodiments, POS 420 is a hardware-based device operated by software and it is configured to function also as, or integrate with, hardware terminals or computerized devices commonly used in retail stores, vending machines, IoT devices, toll road management systems, ATMs, and similar applications. In some embodiments, POS 4comprises or integrates with an interface module, enabling devices such as computerized device 430 to communicate and interact with POS 420 to receive details such as transaction and/or payment requests.

[00164] In some embodiments, the POS 420 is configured to communicate and interact through the receipt of scanned QR codes, scanned Barcode, NFC (Near Field Communication), and/or other methods that facilitate digital wallet transactions. For example, POS 420 is configured to interact and communicate with computerized device 430.

[00165] In some embodiments, POS 420 is an online POS implemented as a software solution integrated into e-commerce platforms for processing digital coin payments.

[00166] In some embodiments, POS 420 comprises Human Interface Devices (HID), e.g., such as keyboard 435 for selecting products and confirming transactions and/or a touch- screen 425 for interacting with a user during a payment process, or for operating any functionality introduced and executed by computerized device 430.

[00167] In some embodiments, touch-screen 425 can display a QR code or Barcode, for customers to scan with their digital wallet, and thus, in some cases, formulating an RTP for the sender to send to the receiver.

[00168] In some embodiments, POS 420 is designed to convert digital coin into Fiat (e.g., USD, EUR), or to other digital asset at the time of the transaction. In some embodiments, POS 420 supports / accepts payments in various digital assets.

[00169] In some embodiments, POS 420 incorporate features for fraud prevention, such as encryption, multi-signature wallets, or two-factor authentication. In some embodiments, POS 420 is designed to ensure adherence to KYC/AML regulations.

[00170] The term “KYC/AML” regulations (Know Your Customer/Anti-Money Laundering) used herein refers to legal and regulatory frameworks designed to combat financial crimes such as money laundering, terrorism financing, fraud, and other illicit activities.

[00171] In some embodiments, computerized device 430 can be a computer, mobile phone, or any electronic device capable of processing digital asset (e.g., a digital currency based payment) transactions or initiating payment requests (e.g., RTP). In some embodiments, computerized device 430 operates software applications and/or hardware components configured to initiate and/or conduct a payment request e.g., RTP.

[00172] System 400 also comprises a PSP 440 designed to facilitate the processing of digital payments for merchants and customers. In some embodiments, PSP 440 is designed to offer online services to enable businesses to accept, process, and payments with digital assets. Thus, PSP 440 may be configured to facilitate the processing of digital asset transfers between a sender and a recipient.

[00173] In some embodiments, PSP 440 is a physical server, or a virtual server designed to communicate with POS 420 over internet protocols. PSP 440 as described herein is only an exemplary embodiment of the present disclosure, and in practice may combine one or more additional services via the internet and/or third-party servers.

[00174] In some embodiments, PSP 440 has access to digital wallet for accepting digital asset. In some embodiments, the PSP 440 conducts one or more payment processes such as: facilitate payments made using digital asset, fiat currencies, or a combination of both, both online and offline, and handle transactions between payees and payers, e.g., customer operating computerized device 430, and POS 420, ensuring digital asset are transferred securely.

[00175] In some embodiments, user operating the computerized device 430 is adapted to initiate a payment request (RTP) or, in some cases to initiate a digital asset transfer. Thus, the computerized device 430 can be configured to communicate with the POS 420 to initiate the transfer. In some embodiments, the POS 420 is also designed to send a payment request, based on digital asset, to the computerized device 430, including details such as the amount and item description.

[00176] In some embodiments, the computerized device 430 is configured to approve a payment request received from POS 420. In such cases, POS 420 can be configured to transmit a payment request to computerized device 430, including details such as the payment amount and item description. In some embodiments, POS 420 is equipped with an interface enabling a payer to initiate and/or process the payment requests directly without the need to operate any device such as computerized device 430.

[00177] In some embodiments, POS 420 is designed to create a transaction and communicate the transaction with the PSP 440 upon approving the payment by the computerized device 430.

[00178] In some embodiments, POS 420 is configured to create a transaction by encoding the transaction specific details and integrate these details without altering its original format of the data structure of the transaction of the specific digital asset used by POS 420, as aforementioned.

[00179] In some embodiments, such a communication is executed over communication channel 450. In some embodiments communication channel 450 operates a standard communication protocol utilized to exchange information over a network or communication channel.

[00180] In some embodiments, communication channel 450 utilizes network protocols, including but not limited to TCP/IP, UDP, HTTP, FTP, or other protocols facilitating communication over the networks such as the internet. In some embodiments, communication channel 450 employs or integrates protocols such as Ethernet, Wi-Fi (IEEE 802.11), NFC or Bluetooth. In some embodiments, communication channel 450 utilizes or combines Machine-to-Machine (M2M) protocols, such as LWM2M, CoAP, or any other standard protocol used in the industry for M2M communication. In some embodiments, communication channel 450 is configured to utilize or integrate protocols such as MQTT, particularly for Internet of Things (IoT) applications.

[00181] In some embodiments, PSP 440 is configured to receive the payment request from the POS 420 or from ASP 465 and confirm that the payment is legitimate and complete (e.g., the transaction is confirmed on the blockchain or validated within their system). In some embodiments, the PSP 440 is also configured to send an acknowledgment to the POS 420, or from ASP 465.

[00182] In some embodiments, the transaction received by PSP 440 can be recorded on the centralized or DLT (Distributed ledger technology) of the PSP 440. In some embodiments, PSP 440 is configured to update the blockchain.

[00183] In some embodiments, a validation and legitimacy check take place between POS 420, ASP 465 and PSP 440. Thus, POS 420 ASP 465 are designed to communicate with the PSP 440 to validate the payment and the PSP 440 verifies the legitimacy of the transaction by checking the clearing engine/ blockchain for confirmation, and in some cases, the PSP 440 can execute additional checks like KYC/AML compliance and fraud detection.

[00184] In some embodiments, the PSP 440 is configured to send an acknowledgment to the POS 420 or to ASP 465 upon successful confirmation of the payment. In some embodiments, the POS 420 and/or ASP 465 are also configured to send a final update to the PSP 440 for the purpose of recording the completion of the transaction.

[00185] In some embodiments, ASP 465 is designed to support software applications and services over the internet, enabling the transfer and/or active processing of transactions. In some embodiments, such services may be configured to manage, store, or transmit transaction details between parties (e.g., between a POS and a PSP) and / or transaction routing to the PSP 440 or other financial institutions.

[00186] In some embodiments, the ASP 465 is configured to initiate and create digital transactions. In some embodiments, the ASP 465 can be configured to modify or adjust certain details, e.g., such as fees, routing information, or additional service-related parameters, before the transaction is signed.

[00187] In some embodiments, the computerized device 430 is configured to communicate with the ASP 465 via a communication channel 460. The communication channel 460 may be characterized such communication channel 450 and may operate in a comparable manner.

[00188] In some embodiments, ASP 465 is configured to receive a payment request from computerized device 430. In some embodiments, ASP 465 is also configured to process the request and generate a designated code (e.g., a verification code such as 4-digit or 6-digit number) to be sent to the computerized device 430 by, in some cases, a secure channel (e.g., SMS, email, or phone-internal-application notification).

[00189] In some embodiments, the computerized device 430 is configured to initiate the transfer of a digital transaction directly to ASP 465. For example, in case the original payment amount is 100.00 and the verification code is 1234, the computerized device 4can modify the payment amount to 100.1234 by integrating the verification code into the third and fourth decimal positions.

[00190] In some embodiments, the computerized device 430 is configured to transfer the transaction, which has the modified payment amount (100.1234) to ASP 465. In some embodiments, the computerized device 430 is configured to initiate the transfer and send the transaction having the modified amount to any designated receiving entity (e.g., bank transfer, mobile payment app).

[00191] In some embodiments, ASP 465 and/or PSP 440 are configured to support Smart Contracts by creation contract transactions. Thus, in some embodiments, the ASP 465 and/or the PSP 440 are configured with the following technical capabilities: ability to create contracts dynamically based on the encoded parameters in the payment, decode the information from the payment (e.g., contract type, duration, interest rates) from the decimal places, and execute automatically based on the decoded parameters such as, determining the contract's duration, or other business logic integrated and/or encoded into the transaction.

[00192] In some embodiments, system 400 or some of the components thereof are configured with additional components to enable specific payment process scenarios. For example, system 400 can incorporate with an ATM for using payment transaction to send data to M/SP/B (the ATM operator), thus, to enable cardless cash withdrawals by encoding withdrawal authorization data in the decimal places of the payment monetary amount.

[00193] In some embodiments, such a configuration with the ATM also enables to combine withdrawal request with an authorization and security parameters in a single transaction. For example, system 400 can be configured to enable a payer to request cash withdrawal through PSP 440 which may be configured to perform the necessary checks and to generate authorized payment order through a creation of a transaction comprising the withdrawal amount, authorization code, and/ or time-sensitive security parameters in the decimal places in the monetary amount. In such an example, PSP 440 is configured to interact with the ATM enabling the payer to present a payment request to the ATM. Thus, the ATM is configured to interact with the PSP 440 as aforementioned and the transaction can be completed with CBDC/cash exchange. In such an exemplary case, the PSP 440 may also be configured to operate the necessary verification software, generate secure code and generate time-sensitive validation checks.

[00194] In some embodiments, system 400 or some of the components thereof are configured with additional components to facilitate a purchase through a vending machine (VM). In some embodiments, system 400 can be configured to create and transfer a transaction to the merchant, i.e., operates the VM while enabling the transfer to operate with minimal payer interventions.

[00195] For example, each product in a VM is presented with a QR code or Barcode, enabling a payer to scan a specific product code. In such an exemplary case, system 400 is configured such that upon scanning a product with a device such as computerized device 430, a payment request is sent from computerized device 430 to the VM (or a wallet managed by the VM) while an application operated by the computerized device 430 automatically encodes and integrates the monetary amount to comprise the product ID and the value in the payment value. In some cases, such a VM can be configured with a sub-wallet, identify the received monetary amount thereby decoding the product ID, validate the transaction, and release the product in accordance with the transaction.

[00196] In some embodiments, system 400 or some of the components thereof are configured with additional components to facilitate a Tall Road Operator (TRO) application by receiving vehicle category and planned exit point information, along with secured payment through “locked-payment” mechanism. For example, system 400 can be configured to communicate and operate with TRO application positioned in each Tall Road exit and entry points, while each of the points is configured with sub-wallet.

[00197] In such exemplary case, the inserted monetary amount can be encoded with the vehicle category, monetary locked-payment, and/or the planned exit point (and other agreed and desired information between payer/driver and TRO).

[00198] This disclosure enables the use of digital assets in any TRO system that was configured before the introduction of this disclosure, providing a means for integrating digital asset transactions, as exposed herein, into pre-existing systems without requiring modifications.

[00199] In an exemplary, case system 400 can be configured to work in a pull-mode-transfer enabling the recipient to pull the transaction from the sender, once the transaction has approved. For example, POS 420 initiates a transaction request sent to computerized device 430. The sender device (computerized device 430) prepares the transaction and notifies POS 420. In some embodiments, upon notification, POS 420 pulls the transaction from computerized device 430. In some embodiments, POS 420 receives, e.g., from computerized device 430, a notification that the transaction is ready to be pulled.

[00200] In some embodiments, computerized device 430 is configured to connect directly with PSP 440 for the purpose of utilizing any services proposed by PSP 440. In some embodiments, such a connection can be via a standard communication protocol commonly utilized in the industry for connecting devices to service providers over the internet.

[00201] In some embodiments, ASP 465 can communicate with PSP 440 for the purpose of initiating, completing, verifying, or validating a payment. In some embodiments, ASP 465 or PSP 440 can communicate directly with the POS 420.

[00202] In some embodiments, all components in the diagram, including computerized device 430, PSP 440, ASP 465, and POS 420, are configured to communicate over standard communication channels (e.g., HTTPS, MQTT, WebSockets) as needed to facilitate the payment process.

[00203] Reference is made to Fig. 5 which illustrates a method for executing a payment process involving digital assets, according to exemplary embodiments of the present disclosure.

[00204] In step 505, a payer seeking to purchase a good or service payer initiates a purchase request to the POS. In some embodiments, the initiation of the process comprises preparing details about a purchase. In some embodiments, the payer is a person operating the computerized device (e.g., computerized device 430).

[00205] In some embodiments, such a preparation act involves one or more operations such as scanning a QR code or Barcode, using a button or keypad, operating a computerized device, operating a programmable logic controller (PLC), or any other action related to a purchase request.

[00206] For example, such a details preparation process may apply in case the payer seeks to conduct a purchase from a vending machine, to pay in a Toll Road Payment system, to withdraw fiat cash against digital assets such as CBDC or Stablecoins, from an ATM, and the like. In such exemplary cases, the payer, by operating a computerized device, prepares the details related to the transfer purpose of the transaction such as payment-specific information (e.g., item price, service ID, and/or product ID).

[00207] In step 510, the payer may submit a purchase request to a POS or any computerized device designed to receive or create a digital transaction. In some embodiments, the request comprises at least part of the detailed previously prepared. In some embodiments, the request comprises payer identification details such as wallet address.

[00208] In step 515, upon receiving, the POS may validate and acknowledge the purchase request. In some embodiments, this step involves verification of the amount, the details with the payer, employ a verification code to validate the transaction, and the like.

[00209] In some embodiments, an additional request is sent to the payer by the POS (e.g., to the phone of the payer), prompting the user to approve the payment.

[00210] In step 520, the POS accepts the purchase request provides details for a payment request to the payer, including transaction amount and any additional transfer related details. In some embodiments, the preparing process of the payment request involves adding the wallet address of the payer and the payment amount.

[00211] In some embodiments, the details of the payment request comprise additional details to be encoded and integrated into the payment transaction. In some embodiments, such details may be any details which are interpretable by a receiving entity, as aforementioned.

[00212] In some embodiments, the POS is configured to function as a payee, thereby issuing a payment request.

[00213] In step 525, the transaction is prepared by the by the POS, or, in some cases, by the payer’s device. In some embodiments, this initiation involves incorporating the details prepared, received, and/or obtained by the POS. In some embodiments, the transaction creation process includes specifying the payer wallet address.

[00214] In some embodiments, an encoding and integration process takes place by the payer or any device operated by the payer, as part of the transaction creation process.

[00215] In some embodiment, in case the payer device is not configured nor capable of creating a transaction with digital asset, once the payer acknowledges the transaction details, the POS prepares the transaction with received details on behalf of the payer.

[00216] In some embodiments, transaction preparation process employs at least part of the processes such as creating and signing the transaction using the user’s private key, adding recipient digital wallet address, adding the payment amount integrated with the encoded details, adding transaction fee, adding any relevant details to the metadata and / or payload of the transaction.

[00217] In some embodiments, step 525 may also comprise utilization of a verification code as aforementioned.

[00218] In step 530, the transaction is finilzed created by the POS, and specific details are made available to the PSP to ensure smooth payment processing and, where applicable, facilitate product or service delivery. In some embodiments, the PSP is allowed to access specific details of the transaction necessary to facilitate the payment process and/or product delivery.

[00219] In step 535, the transaction is transferred to the PSP by the POS. In some embodiments, this is an optional step.

[00220] In some embodiments, the PSP interprets, at least a part of, the encoded detailed from the transaction, thereby facilitate the payment or execute a corresponding action related to the digital asset transaction and/or its transfer purpose.

[00221] In some embodiments, the PSP interprets, at least a part of, the encoded detailed from the transaction prior any decoding code is obtained.

[00222] In some embodiments, the agreed-upon format is utilized to interpret the encoded details and convert the interpreted details to actions, as aforementioned.

[00223] In step 540A, the PSP processes the payment deducting the specified amount from the payer’s wallet balance. In some embodiments, the PSP also updates the POS with a confirmation about a successful payment process. For example, in case the POS is employed by a vending machine, the PSP transfer the transaction to credit the vending machine’s wallet with the corresponding amount from the payer’s wallet. In some embodiments, any transaction fees (e.g., blockchain fees or PSP service charges) are deducted as specified in the transaction details.

[00224] In some embodiments, the charging the wallet balance is followed by a confirmation sent by the PSP to the POS and the user’s wallet balance, PSP generates a receipt or acknowledgment for the payer and/or the POS.

[00225] In step 540B, the POS executes an action based on the interpreted details of the transaction. In some embodiments, the execution of these corresponding actions, or at least a part thereof, occurs after the payer has been successfully charged or after the POS has received a successful payment confirmation from the PSP.

[00226] In some embodiments, the execution of the corresponding actions, or at least a part thereof, occurs prior to receiving any approval by the POS.

[00227] In some embodiments, the method exposed in Fig. 5 can be employed, at least in part, in an operation of a vending machine which can be configured as a POS.

[00228] In some embodiments, each product in the vending machine (POS) is assigned, at least with a part of: Base Price, Product Code, and in some cases Sub-Wallet Address. In some embodiments, in a vending machine, the payer can choose a product (e.g., by scanning a code) and then either the payer or the vending machine (POS) can prepare a transaction with details include the payment amount, product code, and wallet address. In some embodiments, upon successful verification, the vending machine dispenses the product linked to the product code.

[00229] In some embodiments, the method exposed in Fig. 5 may be implemented, at least in part, within an application operated by a TRO, which may be configured as a PSP or an ASP, to enable the payment processing and integrate vehicle category and planned exit point details within the transaction data.

[00230] In some embodiments, a unique sub-wallet is associated or integrated with each toll road entry point for the purpose of enabling the digital transaction transferring method disclosed herein. In some embodiments, upon entering the toll road, a payer operating a computerized device (e.g., computerized device 430) may initiate a locked-payment transaction for a vehicle, wherein a locked-payment, as referred to herein, denotes a digital payment mechanism that reserves or 'locks' a specified amount of funds in the payer's account for subsequent transaction execution.

[00231] In some embodiments, the TRO application entry point initiates payment transactions. Thus, the TRO application creates the transaction by employing a unique sub-wallet. In some embodiments, the TRO application at the entry point encodes the price, the vehicle type, and other details within the monetary amount as aforementioned.

[00232] In some embodiments, the method exposed in Fig. 5, or a part of the steps thereof can be employed for payment transaction process where a payment amount is used not only for a value transfer but also to encode contract-related data within the transaction.

[00233] In some embodiments, the system exposed allows automated creation and configuration of smart contracts application or a similar platform (M/SP/B), either is configured as a PSP or ASP to facilitate these transactions.

[00234] In some embodiments, the payment amount in the transaction specifies the value to be secured in the contract, and the decimal places in the payment monetary amount comprising essential information to configure the contract. In some embodiments, this specification allows a single payment to handle both value transfer and contract setup. In some embodiments, the payer utilizing the contract sends a payment with the encoded parameters (both the secured value and contract details).

[00235] Consequently, based on the parameters encoded in the decimal places, the contract executes automatically according to the predefined terms. In some embodiments, the funds are only released according to the terms specified in the encoded parameters (e.g., after the contract duration ends, or after specific conditions are met).

[00236] In some embodiments, the method exposed in Fig. 5 can be employed for smart device where a payment amount is used not only for a value transfer but also to encode contract-related data within the transaction.

[00237] A smart device refers to an electronic device that is generally interconnected with other devices or networks. Smart devices are typically designed to support a wide range of form factors and various properties associated with ubiquitous computing.

[00238] In some embodiments, the encoding of specific product identifiers, quantities, and delivery preferences within the data structure of the transaction can be implemented across various devices and systems, such as those used in healthcare facilities, building management applications, warehouse management systems, and the like. Thus, in some embodiments, the present disclosure can provide for reducing complexity and ensuring seamless integration between industry-standard systems, digital ecosystems, and payment systems.

[00239] The present disclosure provides for various optional embodiments to transfer, handle, and use a “digital transaction”, a “digital asset transaction”, or simply a “transaction”. The transaction is organized according to predefined structure while comprising a payload structure (referring to the primary content or data being transmitted), a transfer amount (indicating the value being transferred), and associated metadata (covering additional contextual or operational information).

[00240] The scope of this disclosure is not limited to any specific form of digital asset transactions, which are often represented in the form of scripts or code. Rather, digital asset transactions can be represented using various methods or formats, depending on the underlying technology or platform.

[00241] In some embodiments, the process of creating the transfer involves two key steps: first, arranging the data according to the transaction data structure; and second, generating specific representations of the transaction and, in some cases, signing the transaction.

[00242] In some embodiments, creating the transfer requires two key steps, one is arranging the data according to the transaction data structure, and one is creating the representation, generate it, and in some cases sign it.

[00243] Exemplary embodiments can handle transaction presented by: structured formats for interoperability (e.g., xml or json), binary encoding to compactly represent the transaction, executable containing logic and rules to be executed on the blockchain (e.g., in smart contract), and/or Token format with tokenized representations that follow specific protocols.

[00244] The present disclosure provides for covering a broad scope and is not limited to the formats or representations known today, New or future formats, techniques, or technologies for representing transactions that achieve the objectives described herein are also encompassed within the scope of the present disclosure.

[00245] In some embodiments, while the entire scope of the present disclosure can be embodied in a large and broaden scope, in cases involving transaction creation, it is clear that the following implementation scenarios are achieved by some embodiments of the present disclosure:

[00246] Service or Device Activation: in such a case a sender can integrate instructions (coded or not coded) that automatically command IoT devices, gates, vending machines or the like, to unlock or perform an action when the transaction is received, or the transfer is completed.

[00247] Cryptographic Verification: Data is encoded and/or integrated into the decimal or Token (e.g., a valueless Token) portion can represent verification codes, a cryptographic signature, a timestamp, a proof statement and the like. This allows a single transaction to handle both payment and verification.

[00248] Anonymous Yet Traceable Payments: The Sender can insert anonymous reference codes to identify the purpose of the transaction (e.g., subscription for a magazine, donation to a political party, etc.) without disclosing personal information to the receiver. Where regulatory checks are needed, partial references to KYC/AML statuses can be encoded and verified off-chain.

[00249] Smart Contracts: integrate details into decimal digits may define the choice of a certain contract or contract type, and contract parameters (e.g., a timeframe, an interest rate, rules, etc.) such that the Receiver (or an associated smart contract) can parse and apply these parameters automatically.

[00250] Machine-to-Machine Commerce: Industrial or IoT systems can exchange payments that not only transfer value but also carry sensor readings, machine instructions, or operational data, bypassing additional communication layers.

[00251] Illustrative Process Flow: Various embodiments of the disclosed method may include steps such as: (i) Data Collection: The Sender acquires or generates details (e.g., a product code, cryptographic proof, or service ID) to be integrated (with, or without encoding prior inserting) into the transaction data. (ii) Encoding: The system converts these details into numeric form, arranging them within the valid decimal range of the transaction amount or the total quantity of tokens being transferred, and integrate the encoded details into the transaction structure. (iii) Transaction Creation: The Sender (via a Wallet) create a valid transaction that satisfies the ledger’s or blockchain’s (or any payment system clearance engine) standard format. Only the numerical value is adjusted to incorporate the desired data; no new fields are added. (iv) Broadcast or Transmission: The transaction is transfer to the Receiver, potentially through a Payment Service Provider (“PSP”) or directly to the ledger. (v) Decoding and Execution: Upon receiving the transaction, the Receiver’s system (or e.g., a wallet) decodes the data by extracting the designated decimal or token payload. The system then executes the relevant action (e.g., product dispensation, contract activation, record verification, or compliance check).

[00252] The above description provides preferred exemplary embodiment(s) only, and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the above description or any preferred exemplary embodiment(s) of the systems and/or methods therein, will provide those skilled in the art with an enabling description for implementing a preferred exemplary embodiment. It is understood that various changes may be made in the function and arrangement of elements without departing from the spirit and scope as set forth in the appended claims.

Claims (28)

318438/3 CLAIMS What is claimed is:

1. A system comprising a non-transitory computer-readable storage medium having stored thereon program instructions executable for creating a digital asset transaction, the program instructions executable by at least one hardware processor to: obtain one or more details related to a transfer purpose of the transaction; encode at least part of the obtained details according to a data structure of the transaction and integrate said encoded details into one or more fields of the transaction data as part of the transaction creation; wherein the encoding and integration processes are configured to preserve the original transaction data structure; and wherein said encoded details are interpretable by a receiving entity to execute a corresponding action related to the transfer purpose of the digital asset; transfer the created transaction to the receiving entity.

2. The system of claim 1, wherein the details related to the transfer purpose comprise a plurality of additional details, including one or more of: a timestamp, a device identifier, a confirmation code, authentication information, a service ID, a product ID, an item price, a description of a product, a product code, a description of a service, a fee, routing information, and a verification code.

3. The system of claim 1, wherein the action comprises one or more of the following: activating or unlocking a service, executing a smart contract function, initiating a cryptographic verification or compliance check, triggering an automated device operation, dispensing or providing a product, opening a gate, recording transaction-related data for 318438/3 audit or logging, or performing an operation aligned with the intended purpose of the digital asset.

4. The system of claim 1, wherein the program instructions are further executable to integrate the encoded details in a manner that ensures compatibility with a communication protocol that supports the original asset data structure.

5. The system of claim 1, wherein the integration of the encoded details, comprising one or more details related to the transfer purpose, is performed into one or more decimal places of the monetary amount of the digital asset.

6. The system of claim 1, wherein the program instructions are further executable to integrate the encoded details into one or more places of the payload of a valueless Token.

7. The system of claim 6, wherein the program instructions are further executable to integrate the encoded details while maintaining the lengths and expected data types of the digital asset payment value.

8. The system of claim 1, wherein the program instructions are further executable to encode the details in an agreed-upon format, thereby making the encoded details interpretable by the receiving entities.

9. The system of claim 1, wherein the program instructions are further executable to encode the details such that the receiving entity interprets the encoded details and executes the corresponding actions prior to any additional approval of the transaction.

10. The system of claim 1, wherein the program instructions are further executable to transfer said created transaction through sending a notification, to the receiving entity, to pull said created transaction.

11. The system of claim 1, wherein the program instructions are further executable to encode and integrate a cryptographic proof into one or more decimal places of the monetary amount of the digital asset, as part of the transaction creation.

12. A method for creating a digital asset transaction, the method comprising: 318438/3 obtaining one or more details related to a transfer purpose of the transaction; encoding at least part of the obtained details according to a data structure of the transaction, and integrating the encoded details into one or more fields of the transaction data as part of the transaction creation; wherein the encoding and integration are configured to preserve the original transaction data structure; wherein the encoded details are interpretable by a receiving entity for executing a corresponding action related to the transfer purpose of the digital asset; and transferring the created transaction to the receiving entity.

13. The method of claim 12, wherein the details related to the transfer purpose comprise a plurality of additional details, including one or more of: a timestamp, a device identifier, a service ID, a product ID, an item price, a description of a product, a product code, a description of a service, a fee, routing information, a confirmation code, authentication information, or a verification code.

14. The method of claim 12, wherein the action comprises one or more of the following: activating or unlocking a service, executing a smart contract function, initiating a cryptographic verification or compliance check, triggering an automated device operation, dispensing or providing a product, opening a gate, recording transaction-related data for audit or logging, or performing an operation aligned with the intended purpose of the digital asset.

15. The method of claim 12, wherein the integrating of the encoded details comprising one or more details related to the transfer purpose, is performed into the decimal places of the digital asset monetary amount.

16. The method of claim 15, wherein the integration is configured to maintain the lengths, and expected data types of the digital asset payment value. 318438/3

17. The method of claim 12, wherein the encoded details are in an agreed-upon format to ensure that the encoded details are interpretable by the receiving entity.

18. The method of claim 12, wherein integrating the encoded details is in a manner that ensures compatibility with a communication protocol that supports the original asset data structure.

19. The method of claim 12, wherein the encoded details are interpretable by the receiving entity and the corresponding actions are executable prior to any additional approval of the transaction or any decoding code is obtained.

20. The method of claim 12, wherein transferring said created transaction is done through sending a notification, to the receiving entity, to pull said transaction, which comprises both data and code, to the receiving entity.

21. A method for creating a digital asset transaction using a received designated code, the method comprising: receiving a designated code associated with the transaction; encoding the received designated code within transaction data; encoding the designated code within the transaction data; creating the transaction with the designated code integrated into one or more fields of the transaction data, wherein the encoded designated code is interpretable by a receiving entity for executing one or more corresponding actions related to the transfer purpose of the digital asset transaction; transferring the digital asset transaction to the receiving entity; and receiving, from the receiving entity, a response containing the encoded designated code and performing the corresponding action. 318438/3

22. The method of claim 21, wherein the action comprises one or more of the following: providing a product, opening a gate, execute a verification process, or execute an operation aligned with the intended purpose of the digital asset.

23. The method of claim 22, wherein the encoded details comprising one or more details related to the transfer purpose, are integrated into the decimal places of the digital asset monetary amount.

24. The method of claim 21, wherein the integration is configured to maintain the lengths, and expected data types of the digital asset payment value.

25. The method of claim 21, wherein integrating the encoded details is in a manner that ensures compatibility with a communication protocol that supports the original asset data structure.

26. The system of claim 1, wherein said encoded details, comprising one or more details related to the transfer purpose, remain transparent to other entities involved in the transfer.

27. The system of claim 1, wherein said transaction is created and transmitted in one communication channel and is recorded on one distributed ledger used by the system.

28. The method of Claim 1, wherein the corresponding action is encoded for automatic execution by the receiving entity.