Data Provisioning Framework Using Non-Fungible Tokens

Abstract

Disclosed are a system and method for data provisioning using non-fungible tokens (NFTs). The system stores a dataset associated with a data owner and receives, from a data user's account, a purchase request for an NFT representing the dataset in the ledger. The system updates the ownership information of the NFT to include the data user, based on whether the purchase request meets the conditions related to the sale of the NFT. The system receives an access request to the dataset and validates the request based on the ownership information and whether the access request meets the access rules of the dataset and the conditions related to the use of the dataset. The system provides a copy of the dataset to an analysis system based on the validation and determines the consumption pattern of the copy. The system controls access to the copy on the analysis system based on the consumption pattern.

Description

Technical Field

[0001] 〔Cross-Reference to Related Applications / Incorporation by Reference〕 This application claims the benefit of priority of U.S. Patent Application No. 18 / 188,172, filed Mar. 22, 2023, which claims priority to U.S. Provisional Patent Application Serial No. 63 / 366,781, filed Jun. 22, 2022, the entire contents of which are hereby incorporated by reference.

[0002] Various embodiments of the present disclosure relate to non-fungible tokens. Specifically, various embodiments of the present disclosure relate to an electronic device and method for a data provisioning framework using non-fungible tokens.

Background Art

[0003] Advances in information technology have led to the development of tools that enable different service providers to collaborate and provide services to users through a single software application. For example, multiple mobility service providers can register with a mobility-as-a-service network and provide multimodal transportation services to users through a MaaS application. Based on these services, the software application can accumulate a large amount of data about each user over a certain period of time. These data can be useful for applications such as fleet operations in a certain geographical area or demand estimation of services provided by mobility service providers. Data owners may wish to sell or share the data under certain terms and conditions depending on the significance or size of the data. In conventional IT systems that follow the client-server model, it can be difficult to identify customers who purchase data with malicious intent to misuse, tamper with, or resell the data for profit. It can be even more difficult for conventional IT systems to prevent such misuse of data or any attempt at tampering or reselling.

Summary of the Invention

Problems to be Solved by the Invention

[0004] Those skilled in the art will appreciate the limitations and disadvantages of conventional and customary techniques by comparing the described system with some aspects of the present disclosure shown hereinafter with reference to the drawings.

Means for Solving the Problems

[0005] Provided is a system and method for a data provisioning framework using non-fungible tokens, illustrated and / or described in relation to substantially at least one figure and further shown more fully in the claims.

[0006] These and other features and advantages of the present disclosure will be understood by considering the following detailed description of the present disclosure with reference to the accompanying drawings, in which like elements are denoted by like reference numerals throughout.

Brief Description of the Drawings

[0007]

Figure 1

Figure 2

Figure 3A

Figure 3B

Figure 4A

Figure 4B

Figure 5

Figure 6

Best Mode for Carrying Out the Invention

[0008] In a system and method for data provisioning using non-fungible tokens, embodiments described below can be found. The system covers end-to-end processes of a digital supply chain process, such as creation or definition of a dataset (original data), sale, ownership of the dataset, and consumption of the dataset for analysis purposes. Exemplary aspects of the present disclosure can provide a system capable of performing operations for data provisioning using non-fungible tokens. The system can store a dataset related to a data owner in a storage device. The system receives a purchase request for one or more non-fungible tokens (NFTs) from one or more accounts of a data user at any point in time. The NFT can represent a dataset on a distributed ledger. The system can update the ownership information of the NFT on the distributed ledger to include the data user based on whether the purchase request meets the conditions related to the sale of the NFT. Thereafter, the system receives an access request to the dataset. The access request is verified for validity based on whether the access request meets at least one of the ownership information, access rules of the dataset, and conditions related to the use of the dataset. The system can provide a copy of the dataset from the storage device to an analysis system related to the data user based on the validity verification. After the copy is provided, the system can determine the consumption pattern of the provided copy on the analysis system and control access to the copy of the dataset on the analysis system based on the consumption pattern.

[0009] Applications that connect different mobility providers can generate large amounts of datasets. Data owners can own such datasets. For example, users of an application that provides MaaS using one or more public or private transportation means can be the data owners of the dataset of the MaaS trip. For example, the dataset can include information on the use of types of transport tickets such as single-use tickets, registration-based tickets, and seasonal tickets. If the dataset is valuable, the data owner may want to share the dataset with a trustworthy party or sell it to a trustworthy party. In conventional IT systems, it may be difficult to detect customers who use the dataset improperly for profit, tamper with the dataset, or purchase the dataset with the intention of reselling it. In conventional IT systems, it has often been much more difficult to prevent such abuse, or attempts to tamper with or resell the dataset. Therefore, there is a need for a data provisioning framework that guarantees secure and fraud-prevented access to such datasets.

[0010] The present disclosure introduces a system that provides data provisioning using non-fungible tokens to address these problems and meet the needs. The disclosed system can utilize a distributed ledger to protect the ownership and access permissions of data sets. When such a data set is created on the distributed ledger, an encrypted version of the data set can be shared using open technologies to prevent illegal copies of the data set. For example, the disclosed system can create an NFT on a public distributed ledger based on whether the data set meets the creation conditions of the NFT. The created NFT can be listed on an NFT marketplace associated with the public distributed ledger. The system can receive a purchase request for the NFT from the data user's account. For example, the purchase request can be received based on the selection of the NFT listed on the NFT marketplace. The system can determine whether the purchase request meets the conditions related to the sale of the NFT. Subsequently, the data user can pay the purchase price of the NFT. When the NFT is purchased, the system can update the ownership information of the NFT on the distributed ledger to include the data user.

[0011] The system can receive an access request to the data set via a user device and verify the access request based on the ownership information and further based on whether the access request meets at least one of the access rules of the data set and the conditions related to the use of the data set. The system can provide a copy of the data set from the storage device to the analysis system based on the verification and determine the consumption pattern of the data set. Based on this consumption pattern, access to the copy of the data set on the analysis system can be controlled. Thus, the system provides a data provisioning framework that securely shares data sets, such as travel data, with limited participants who own the NFT of the data set. The system can further protect the rights related to the use of the data set and prevent illegal copies of the data set.

[0012] Figure 1 is a block diagram showing an exemplary system for data provisioning using non-fungible tokens according to an embodiment of the present disclosure. A diagram of system 100 is shown in FIG. 1. System 100 can include a data collection system 102, an owner device 104, a middleware system 106, a distributed ledger 108, a non-fungible token (NFT) marketplace 110, a mobility as a service (MaaS) network 112, a user device 114, an analysis system 116, a server 118, a database 120, and a communication network 122. The middleware system 106 can include a storage device 124. The MaaS network 112 can include a machine learning (ML) model 126. The distributed ledger 108 can be used to store NFTs purchased in the NFT marketplace 110. As an example, the NFT marketplace 110 can list an NFT 128 for a dataset. The data collection system 102, the owner device 104, the middleware system 106, the distributed ledger 108, the MaaS network 112, the user device 114, the analysis system 116, and the server 118 can be communicatively coupled to each other via the communication network 122. FIG. 1 further shows a data owner 130 who may be associated with the owner device 104 and a data user 132 who may be associated with the user device 114. The data owner 130 can be the first owner of the dataset.

[0013] System 100 can include suitable logic, circuitry, and interfaces configured to provide a secure data provisioning mechanism for datasets related to various data owners. System 100 can enable a data owner (such as data owner 130) to submit a dataset and request the creation of an NFT (such as NFT 128) on the distributed ledger 108. After creation, such an NFT can be listed on the NFT marketplace 110, and a data user (such as data user 132) can purchase the NFT (such as NFT 128) and access each dataset represented by such an NFT. System 100 can also enable secure storage of the dataset by using suitable encryption techniques (e.g., asymmetric encryption techniques that encrypt the dataset using public and private keys). Examples of System 100 can include, but are not limited to, a network of Internet of Things (IoT) devices, a cluster of mainframe machines, a centralized server or data center having multiple shared resources, a network of computer workstations, a network of edge devices, or a combination thereof.

[0014] The data collection system 102 can include suitable logic, circuitry, and interfaces configured to receive a data set from a data owner 130 and create an NFT 128 on a distributed ledger 108 based on whether the data set (i.e., the data submitted by the data owner 130) meets the creation conditions of the NFT 128. The data collection system 102 can receive a purchase request for the NFT 128 from an account of a data user 132. The account can be, for example, a wallet account of the data user 132 on the distributed ledger 108 or a distributed ledger other than the distributed ledger 108. In one example, the account can be associated with a decentralized application (DApp) that can be linked to the distributed ledger 108. The DApp can include functions for searching, listing, and purchasing NFTs. Access to the DApp can be authenticated based on, for example, an account associated with the DApp and a decentralized identifier. The data collection system 102 can update the ownership information of the NFT 128 on the distributed ledger 108 to include the data user 132 based on whether the purchase request meets the conditions related to the sale of the NFT 128. Examples of the data collection system 102 can include, but are not limited to, a network of Internet of Things (IoT) devices, a group of mainframe machines, a centralized server, a data center having multiple shared resources, a network of computer workstations, or a network of edge devices.

[0015] The owner device 104 can include suitable logic, circuitry, and interfaces configured to send a request to onboard the data owner 130 to the data collection system 102. The owner device 104 can be associated with the data owner 130. Examples of the owner device 104 can include, but are not limited to, a computer device, a hardware-based annealer device, a smartphone, a cellular phone, a gaming device, a mainframe machine, a server, a computer workstation, and / or a consumer electronics (CE) device.

[0016] The middleware system 106 can include a software application that can function as a bridge between the storage device 124 and an application operating on the data collection system 102. The middleware system 106 can be responsible for the management and distribution of the data stored in the storage device 124.

[0017] The distributed ledger 108 can be a decentralized distributed database system that holds an immutable record of data operations or transactions. A series of data operations can be grouped as blocks and further linked to previous data operation blocks to form a chain of multiple blocks. All data operation blocks can be stored in a distributed manner where all participants or nodes store all the blocks. Further, the distributed ledger 108 can include an operating system that can enable the deployment of a series of smart contracts among multiple parties.

[0018] The decentralized ledger 108 can maintain a chain of blocks in which accounts can be used as state objects, and the state of each account can be tracked by this chain. An account can represent the identity of a user, mining nodes, or automated agents. All data operation blocks or smart contracts can be associated with accounts on the chain of blocks. By way of non-limiting example, the decentralized ledger 108 can be a Blockchain ledger that uses accounts as state objects and can track the state of each account by the blockchain. The scope of the present disclosure can be not limited to the implementation of the decentralized ledger 108 as a specific type of ledger. In the present disclosure, other implementations of the decentralized ledger 108 are also possible without departing from the scope of the present disclosure.

[0019] The NFT marketplace 110 can be an application such as a digital marketplace that can be used to list NFTs for sale. For example, the NFT 128 can be listed on the NFT marketplace 110. The NFT marketplace 110 can include a front-end interface accessible via a web client and a back-end interface that can be linked to the decentralized ledger 108. For example, the front-end interface can be a user interface (UI) of a web application, website, or mobile application. The data collection system 102 can receive a purchase request for an NFT based on user input related to the selection of the NFT 128 via the NFT marketplace 110.

[0020] The MaaS network 112 can be an application that enables users to plan trips involving services of different transportation providers. The MaaS network 112 can include a message broker, a set of publisher nodes, a set of distributed ledger nodes, and a set of subscriber nodes that communicate with the set of publisher nodes via the message broker. The set of publisher nodes can be communicatively coupled to the distributed ledger 108. The MaaS network 112 can facilitate the operation of multiple homogeneous or heterogeneous mobility providers and their infrastructure such as ticketing gates, applications, and / or point-of-sale (PoS) devices on the MaaS network 112 to provide various mobility services. Each mobility provider enjoys secure data ownership and can share related transaction data through at least one of the set of distributed ledger nodes. This can enhance connectivity among various mobility providers. Details regarding the MaaS network 112 are further shown, for example, in FIG. 2.

[0021] The user device 114 can include suitable logic, circuitry, and interfaces configured to provide a purchase request for the NFT 128 representing a dataset on the distributed ledger 108 based on user input. Further, the user device 114 can provide an access request to the dataset to the data collection system 102. The user device 114 can be related to the data user 132. Examples of the user device 114 can include, but are not limited to, a computer device, a hardware-based annealer device, a digital annealer device, a quantum-based or quantum-inspired annealer device, a smartphone, a cellular phone, a mobile phone, a gaming device, a mainframe machine, a server, a computer workstation, and / or a consumer electronics (CE) device.

[0022] The analysis system 116 can include suitable logic, circuits, and interfaces configured to receive a copy of the dataset from the storage device 124 upon authentication of an access request from the data user 132. The analysis system 116 can include software tools that process and analyze the received copy of the dataset. In some embodiments, the functionality of the analysis system 116 can be incorporated at least partially or entirely into the user device 114 associated with the data user 132. Examples of the analysis system 116 can include, but are not limited to, a computer device, a smartphone, a mobile phone, a gaming device, a mainframe machine, a server, a computer workstation, and / or a consumer electronics (CE) device.

[0023] The server 118 can include suitable logic, circuits, interfaces, and / or code configured to control access to a copy of the dataset on the analysis system 116 based on consumption patterns. The server 118 can be implemented as a cloud server and can execute operations via, for example, a web application, a cloud application, an HTTP request, a repository operation, and a file transfer. Other examples of implementations of the server 118 can include, but are not limited to, a database server, a file server, a web server, a media server, an application server, a mainframe server, or a cloud computing server.

[0024] In at least one embodiment, the server 118 can be implemented as a plurality of distributed cloud-based resources by using a plurality of techniques well known to those skilled in the art. Those skilled in the art will understand that the scope of the present disclosure is not limited to the implementation of the server 118 and the data collection system 102 as two independent entities. In some embodiments, without departing from the scope of the present disclosure, the functions of the server 118 can be wholly or at least partially incorporated into the data collection system 102. In some embodiments, the server 118 can host the database 120. Alternatively, the server 118 can be separated from the database 120 and communicatively coupled to a device storing the database 120.

[0025] The database 120 can be configured to store a copy of the dataset. The database 120 can be stored or cached on a device such as a server (e.g., server 118) or the data collection system 102. In some embodiments, the database 120 can be hosted on a plurality of servers stored in the same or different locations. The operations of the database 120 can be executed using hardware including a processor, a microprocessor (e.g., one or more that execute or control the execution of operations), a field programmable gate array (FPGA), or an application specific integrated circuit (ASIC).

[0026] The communication network 122 can include a communication medium that enables the data collection system 102, the owner device 104, the middleware system 106, the distributed ledger 108, the NFT marketplace 110, the MaaS network 112, the user device 114, the analysis system 116, and the server 118 to communicate with each other. The communication network 122 can be either a wired connection or a wireless connection. Examples of the communication network 122 include, but are not limited to, the Internet, a cloud network, a cellular or wireless mobile network (such as Long-Term Evolution and 5th Generation (5G) New Radio (NR)), a Wireless Fidelity (Wi-Fi) network, a Personal Area Network (PAN), a Local Area Network (LAN), or a Metropolitan Area Network (MAN). The various devices within the system 100 can be configured to connect to the communication network 122 according to various wired and wireless communication protocols. Examples of such wired and wireless communication protocols include, but are not limited to, Transmission Control Protocol and Internet Protocol (TCP / IP), User Datagram Protocol (UDP), Hypertext Transfer Protocol (HTTP), File Transfer Protocol (FTP), ZigBee, EDGE, IEEE802.11, Light Fidelity (Li-Fi), 802.16, IEEE802.11s, IEEE802.11g, multi-hop communication, a wireless access point (AP), device-to-device communication, a cellular communication protocol, and at least one of the Bluetooth (BT) communication protocol.

[0027] The memory device 124 can include suitable logic, interfaces, and / or code configured to store a dataset. The memory device 124 can be included or integrated into a device such as a server (e.g., server 118) or the data collection system 102. The operation of the memory device 124 can be executed using hardware including a processor, a microprocessor (e.g., executing or controlling one or more operations), a field programmable gate array (FPGA), or an application specific integrated circuit (ASIC). In some other cases, software can be used to implement the database 120.

[0028] The ML model 126 can be a classifier model that can be trained to identify the relationship between inputs such as features in a training dataset and output labels. The ML model 126 can be defined by hyperparameters such as, for example, the number of weights, the cost function, the input size, and the number of layers. The parameters of the ML model 126 can be adjusted to update the weights towards the global minimum of the cost function of the ML model 126. The ML model 126 can be trained to output classification results for a series of inputs after training for a plurality of epochs on the feature information in the training dataset. The classification results can indicate the class labels of each input in the series of inputs (e.g., input features extracted from new / invisible instances). For example, based on consumption patterns, if a violation of conditions related to the sale of NFTs, access rules for the dataset, or conditions related to the use of the dataset is detected, the ML model 126 can classify the data user 132 with a blacklist label.

[0029] The ML model 126 can include electronic data that can be implemented as a software component of an application executable, for example, on the data collection system 102. The ML model 126 can rely on libraries, external scripts, or other logic / instructions for execution by a processing device. The ML model 126 can rely on computer-executable code and routines that enable a computer system, such as the MaaS network 112, to perform one or more operations, such as determining whether there is a violation of conditions related to the sale of the NFT 128. In addition to or instead of this, the ML model 126 can also be implemented using hardware including a processor, a microprocessor (e.g., that performs or controls the performance of one or more operations), a field programmable gate array (FPGA), or an application specific integrated circuit (ASIC). Alternatively, in some embodiments, the ML model 126 can also be implemented using a combination of hardware and software.

[0030] An NFT can be described as a type of digital asset that represents the ownership or authenticity proof of a unique item or object. For example, the NFT 128 can represent the ownership or authenticity proof of a dataset related to the data owner 130. Typically, an NFT can be stored on a distributed ledger (such as the distributed ledger 108) and is non-fungible, that is, the NFT is unique and has a unique value. Generally, an NFT cannot be copied, replaced, or subdivided on a distributed ledger. This is in contrast to conventional cryptocurrencies that can be considered interchangeable with a uniform value.

[0031] During operation, the data collection system 102 can control the middleware system 106 to store a dataset related to the data owner 130 in the storage device 124. In certain embodiments, the raw version of the dataset can be stored in the storage device 124. In another embodiment, the dataset can be encrypted and the encrypted dataset can be stored in the storage device 124. Details regarding the storage of the dataset are shown, for example, in FIG. 3A.

[0032] The NFT marketplace 110 can receive a purchase request for the NFT 128 from the account of the data user 132 at any time. This account can be a wallet or an account associated with a DApp that can be linked to the distributed ledger 108. The NFT 128 can represent a dataset on the distributed ledger 108. The NFT marketplace 110 can be a digital marketplace where the NFT 128 can be listed for purchase. The NFT marketplace 110 can receive a purchase request based on user input provided by the data user 132. For example, the user input can be received based on the user's interaction with a user interface (UI) element related to the NFT 128. Details regarding the purchase request are shown, for example, in FIG. 3A.

[0033] Upon receiving the purchase request, the data collection system 102 can update the ownership information of the NFT 128 on the distributed ledger 108 to include the data user 132 based on whether the purchase request meets the conditions related to the sale of the NFT 128. For example, the data collection system 102 can verify whether the details specified in the purchase request meet the conditions related to the sale of the NFT 128. If the purchase request meets the conditions related to the sale of the NFT 128, the ownership information of the NFT 128 can be updated to include the data user 132. Details regarding the conditions related to the sale of the NFT 128 are shown, for example, in FIG. 3B.

[0034] The middleware system 106 can receive an access request from the analysis system 116 to a dataset. Just purchasing the NFT 128 may not allow the analysis system 116 associated with the data user 132 to access the dataset. The analysis system 116 can generate an access request based on user input. The data collection system 102 can control the middleware system 106 to verify the access request based on ownership information and whether the access request meets at least one of the access rules for the dataset and the conditions related to the use of the dataset. For example, when an access request is received, the ownership information can be verified to determine whether the account that sent the access request is the same as the account of the data user 132 used to purchase the NFT 128. When the ownership information is verified, the information specified in the access request can be verified to determine whether the access request meets the access rules for the dataset and the conditions related to the use of the dataset. If there is a violation of the access rules for the dataset or the conditions related to the use of the dataset, the access request can be rejected. Details regarding the verification of the access request are shown, for example, in FIG. 3B.

[0035] The data collection system 102 can control the middleware system 106 to provide a copy of the dataset from the storage device 124 to the analysis system 116 associated with the data user 132 based on the verification. For example, when the access request is verified, the middleware system 106 can stream a copy of the dataset to the analysis system 116. For example, the copy of the dataset can be streamed in an encrypted and / or anonymized form. The middleware system 106 can share a (single or multiple) private key for individually decrypting the copy of the dataset with the wallet account of the data user 132. Details regarding the provision of the copy of the dataset are shown, for example, in FIG. 3B.

[0036] After a copy of the dataset is provided, the data collection system 102 can determine the consumption pattern of the provided copy on the analysis system 116. The data collection system 102 can control access to the copy of the dataset on the analysis system 116 based on the consumption pattern. For example, the data collection system 102 can analyze the consumption pattern to determine whether there is a violation of conditions related to the sale of the NFT 128, access rules for the dataset, or conditions related to the use of the dataset. If a violation is detected, the data collection system 102 can prevent access to the copy of the dataset. Details regarding the consumption pattern and access control to the copy of the dataset are shown, for example, in FIG. 3B.

[0037] The disclosed system 100 can provide benefits to the data owner 130, the owner of the system 100, and the data user 132. The system 100 can bring a higher profit margin to the data owner 130. Furthermore, the disclosed system 100 can assist the data owner 130 in expanding its related publishing business and strengthening the primary and secondary markets of its related publishing business. Also, the system 100 can provide new opportunities to new entrants and market leaders who wish to sell the owned dataset. The data owner 130 can also sell the dataset owned by the data owner 130 by auctioning the NFT 128 related to the dataset. The disclosed system 100 can manage a secondary market such as analytics as a service to prevent user data from data spoofing and forgery. The data user 132 can have the option to interact directly with the data owner 130. Furthermore, the data user 132 can ensure that the dataset is genuine through the involvement of the distributed ledger 108 and the MaaS network 112.

[0038] The use of data can be broadly classified into primary use and secondary use. Primary use can be for transaction settlement for revenue sharing among MaaS-related players such as mobility providers and mobility service providers. Secondary use can include the reuse of data sets for analysis by service providers such as the government, related institutions, location-based service (LBS) players, and marketing companies. There can also be other uses where data analytics players process the data and resell it as a new NFT using a framework. For example, data from such analysis can represent a new data set suitable for creating a new NFT for resale by the analytics player using the same data provisioning framework. Usage patterns can indicate popular data sets that can be subject to further changes such as options that bring additional benefits to the owner by increasing the price.

[0039] Figure 2 is a block diagram showing the MaaS network of FIG. 1 according to an embodiment of the present disclosure. The description of FIG. 2 is made in relation to the elements of FIG. 1. FIG. 2 shows a MaaS network 112. The MaaS network 112 can be related to a publish-subscribe pattern. The MaaS network 112 can include a series of issuer nodes 202A, 202B,... 202N, a message broker 204, and a series of subscriber nodes 206A, 206B... 206N. The MaaS network 112 can further include a plurality of mobility provider (MP) nodes 208A, 208B,... 208N of a first distributed ledger 208, and a plurality of MaaS nodes 210A, 210B... 210N of a second distributed ledger 210. Further, the MaaS network 112 can include a series of distributed ledger nodes 212 that can include a driver node 212A, a user node 212B, and a document node 212C.

[0040] The MaaS network 112 can support standard communication specifications. The MaaS network 112 can include an issuer node (e.g., a ticket reader or a ride reservation application), a subscriber node, and at least one message broker that conveys transaction messages from the issuer node to the subscriber node according to a publish - subscribe network protocol such as, but not limited to, a Message Queuing Telemetry Transport (MQTT) - based messaging protocol, an Advanced Message Queuing Protocol (AMQP) - based messaging protocol, or a Message - Oriented Middleware (MOM) - based messaging framework. In at least one embodiment, the MaaS network 112 can include a distributed ledger that includes a ledger node that records transactions related to various mobility services such as ticketing transactions for MaaS transport services, media usage or consumption statistics, or payment settlements among various stakeholders such as content owners, transport providers, or operators of the MaaS network 112.

[0041] A series of issuer nodes 202A, 202B,... 202N of all transport service providers related to the MaaS network 112 can exchange data according to a standard or common communication protocol. The MaaS network 112 can include homogeneous issuer nodes that can comply with the MaaS standard communication specification. In one embodiment, the MaaS network 112 can also include heterogeneous issuer nodes that can comply with a dedicated communication protocol. The MaaS network 112 can provide plug - in - based support to the series of issuer nodes 202A, 202B,... 202N so that it can support such heterogeneous issuer nodes until each transport service provider provides its support according to the MaaS standard communication specification.

[0042] The MaaS network 112 can enable issuer nodes associated with different transportation providers to participate in the MaaS network 112. The MaaS network 112 can provide bulk cluster management of issuer nodes through a node management device. All issuer nodes can follow set protocols that enable operation on the MaaS network 112. The set protocols can mandate a common security architecture (for authentication and authorization of issuer nodes), network protocols (such as HTTP, MQTT, and AMQP), a unified data request or response format (such as JSON, CSV, XML formats), and an API / data schema. This can ensure that each issuer node follows a cluster-level configuration and device-level certificate (i.e., authentication credentials) (such as a device profile including company name, company ID, gate ID, and gate number). The pattern of the cluster-level configuration and set protocols can facilitate the transportation provider to deploy new issuer nodes or replace existing issuer nodes in a plug-and-play manner. This can easily enable the MaaS network 1112 to function as a homogeneous transportation network with interoperability among resources (such as issuer node devices) of various transportation providers.

[0043] Each of a series of issuer nodes 202A, 202B... 202N can include suitable logic, circuitry, code, and / or interfaces configured to operate as a ticket processing client for the transportation services of respective transportation service providers. For example, each of a series of issuer nodes 202A, 202B... 202N can read, issue, recharge, or cancel tickets as a ticket processing client to create events related to respective transportation services. Based on such events, transaction messages can be communicated to one or more subscriber nodes (such as a series of subscriber nodes 206A, 206B... 206N) of the MaaS network 112 through the message broker 204. Examples of a series of issuer nodes 202A, 202B... 202N include, but are not limited to, consumer electronic devices having travel planning or reservation applications, ticket readers on turnstiles, ticket vending kiosks, point-of-sale (PoS) devices, mobile POS, ticket dispensers, and smart doors of transportation vehicles that can read tickets to start or end a journey.

[0044] Each of a series of subscriber nodes 206A, 206B... 206N can include suitable logic, circuitry, code, and / or interfaces configured to receive transaction messages from one or more of a series of issuer nodes 202A, 202B... 202N via the message broker 204. Each transaction message can include a topic that one or more of the series of subscriber nodes 206A, 206B, 206N can subscribe to. Examples of subscriber node implementations include, but are not limited to, web servers, edge devices, edge nodes, cloud servers, cluster nodes of cloud-based servers, workstations, or any computer device having fog computing capabilities.

[0045] The first issuer node 202A among a series of issuer nodes 202A, 202B... 202N, and the first subscriber node 206A among a series of subscriber nodes 206A, 206B... 206N can be associated with a first transport provider. Other nodes such as the second issuer node 202B and the second subscriber node 206B can be associated with a first transport provider or a second transport provider that can be different from the first transport provider.

[0046] The message broker 204 can include suitable logic, circuitry, code, and / or interfaces configured to route transaction messages from issuer nodes (such as the first issuer node 202A) to subscriber nodes (such as the first subscriber node 206A). The decision to permit the message broker 204 to route such transaction messages to subscriber nodes can be made by a server associated with the MaaS network 112 (not shown in FIG. 1). Exemplary implementations of the message broker 204 can include, but are not limited to, an application server, a cloud server, a mainframe server, a database server, a web server, or other types of servers.

[0047] The message broker 204 can be configured to communicate with each of a series of issuer nodes 202A, 202B... 202N and a series of subscriber nodes 206A, 206B... 206N through a suitable publish-subscribe network protocol such as, but not limited to, an MQTT-based messaging protocol, an AMQP-based messaging protocol, or a message-oriented middleware (MOM)-based messaging framework.

[0048] The plurality of MP nodes 208A, 208B... 208N can include suitable logic, circuitry, code, and / or interfaces configured to store transaction data related to respective mobility providers. For example, the first MP node 208A can store transaction data related to the first mobility provider. The transaction data can include records of a user's trips. Each trip can correspond to a MaaS transportation service that can be provided by a first transportation provider in at least one leg of the trip. Each of the plurality of MP nodes can be referred to as a node of a first distributed ledger 208 capable of storing transaction data of various mobility providers of the MaaS network 112.

[0049] The plurality of MaaS nodes 210A, 210B... 210N can include suitable logic, circuitry, code, and / or interfaces configured to store transaction data related to all mobility providers of the MaaS network 112. The storage of transaction data related to each of the transportation service providers can be used to settle payments among the transportation service providers that provide transportation services to a user. Each of the plurality of MaaS nodes 210A, 210B... 210N can correspond to a node of a second distributed ledger 210 capable of storing transaction data related to the MaaS network 112.

[0050] Each of the plurality of MP nodes 208A~208N and each of the plurality of MaaS nodes 210A, 210B... 210N can be related to a series of distributed ledger nodes 212. For example, each of the first MP node 208A and the first MaaS node 210A can be related to a driver node 212A, a user node 212B, and a document node 212C.

[0051] A series of subscriber nodes 206A, 206B... 206N can be associated with corresponding nodes of the first distributed ledger 208. For example, the first subscriber node 206A can be associated with the first MP node 208A of the first distributed ledger 208, the second subscriber node 206B can be associated with the second MP node 208B of the first distributed ledger 208, and so on.

[0052] In certain embodiments, at least two ledger nodes of each of the first distributed ledger 208 and the second distributed ledger 210 can store transaction data related to the MaaS transportation service. The MaaS transportation service can be related to one or more of a plurality of transportation providers and / or users (e.g., passengers) who can utilize the MaaS transportation service through an integrated MaaS interface or a series of issuer nodes 202A, 202B... 202N. Transaction data related to the MaaS transportation service can be included in a series of state objects such as an initial state object and updated versions of the initial state object. Each state object can include a smart contract, contract code (or transaction rules agreed upon by the parties to the transaction), and state properties (which can be updated when the transaction data is updated based on transaction requests from the series of issuer nodes 202A, 202B... 202N).

[0053] In at least one embodiment, each of the first distributed ledger 208 and the second distributed ledger 210 can be a decentralized distributed database system that can maintain an immutable record of data operations or transaction records. For example, a transaction can include a record of the consumption pattern of an NFT (as described in FIG. 1) or the sale of an NFT via the NFT marketplace 110. A series of data operations can be grouped as blocks and further linked to previous data operation blocks to form a chain of multiple blocks. All data operation blocks can be stored in a decentralized manner such that at least two participants or nodes of each of the first distributed ledger 208 and the second distributed ledger 210 can store a subset of the multiple blocks related to one or more transactions in which these participants or nodes can participate. Further, each of the first distributed ledger 208 and the second distributed ledger 210 can include an operating system (e.g., Java Virtual Machine (JVM)) that can enable the deployment of smart contracts among multiple parties such as, for example, the (single or plural) mobility provider nodes and counterparty nodes (i.e., MaaS provider nodes) of the first transportation provider.

[0054] By way of example and not limitation, each of the first distributed ledger 208 and the second distributed ledger 210 can be a distributed ledger technology (DLT) system such as a blockchain-based system (e.g., Corda blockchain, Ethereum® blockchain, or Hyperledger blockchain). Each of the first distributed ledger 208 and the second distributed ledger 210 can store a series of immutable state objects that the first distributed ledger 208 and the second distributed ledger 210 can track. The state objects can include a series of distributed ledger corresponding rules for different types of distributed ledger technologies. For example, the state objects can include transaction data such as smart contracts between parties, contract code (rules of transactions), and content including state characteristics having certain state values. The smart contract can include a series of conditions that multiple parties to the smart contract can agree to interact with each other. The smart contract is executed on one or more nodes of each of the first distributed ledger 208 and the second distributed ledger 210 and can manage the transition between state objects for generating transactions. The smart contract can be written once and reused in multiple state objects and can refer to governing legal prose through cryptographic hashes.

[0055] Each of the first distributed ledger 208 and the second distributed ledger 210 can also use a secure cryptographic hash to identify parties and data and link state objects to previous versions of state objects to provide chains of provenance. The first distributed ledger 208 and the second distributed ledger 210 can store transactions among a group of parties so that only the relevant group of parties can view them. The parties associated with a transaction can store the current state object of that transaction in a vault (a database associated with each respective distributed ledger such as the first distributed ledger 208 and the second distributed ledger 210). Another party eligible to view or process a transaction (e.g., to verify the validity of a transaction) can retrieve the current state object of the transaction from the vault. Also, each state object of the first distributed ledger 208 and the second distributed ledger 210 can include a smart contract among the parties or nodes that can participate in the associated transaction.

[0056] In each of the first distributed ledger 208 and the second distributed ledger 210, a participant or node (e.g., the first MP node 208A) can update a transaction by updating state characteristics of an input state object (e.g., the first state object) to generate an output state object (e.g., the second state object). As a result, the updated transaction can form a provenance chain (which can be related to transaction data). Each of the first distributed ledger 208 and the second distributed ledger 210 can agree on the updated transaction based on a determination of the validity of the updated transaction and a determination of the uniqueness of the updated transaction. In one embodiment, a participant of a node related to the updated transaction can determine the validity of the updated transaction by individually executing a smart contract and validity verification logic related to the transaction. Further, the consensus nodes related to each of the first distributed ledger 208 and the second distributed ledger 210 can determine the uniqueness of the updated transaction based on a check that there is no other transaction that reached an agreement using the same input state object as the current transaction.

[0057] Figures 3A and 3B collectively show an exemplary series of operations for data provisioning using non-fungible tokens, according to embodiments of the present disclosure. The description of Figures 3A and 3B is made in relation to the elements of Figures 1 and 2. Figures 3A and 3B show an exemplary sequence diagram 300 showing exemplary operations 302-328. The exemplary operations 302-328 can be performed by any computer system, such as a component of the system 100 of Figure 1. The exemplary sequence diagram 300 further shows a data collection system 102, an owner device 104, a middleware system 106, an NFT marketplace 110, a mobility as a service (MaaS) network 112, a user device 114, an analysis system 116, and an ML model 126.

[0058] At 302, an onboarding request can be received. The data collection system 102 can receive an onboarding request from the data owner 130 for the purpose of submitting a dataset owned by the data owner 130 to the data collection system 102. The onboarding request can be received via user input provided from the owner device 104 by the data owner 130. As an example, on the owner device 104, an interface of a data collection application can be rendered. The interface of the data collection application can receive information such as the name of the data owner 130, the type of data owned by the data owner 130 (e.g., travel data), and the volume of data owned by the data owner 130 (e.g., 100 kilobytes of data). The received information can be transmitted to the data collection system 102.

[0059] At 304, mobility service data can be received. In one embodiment, the data collection system 102 can receive mobility service data related to a series of past trips made by the data owner 130 via multiple mobility service providers. A mobility service provider can be a transportation provider that the data owner 130 has used services to move from one location to another. The data owner 130 can use multiple mobility service providers in one trip. For example, a data owner such as the data owner 130 can use a ride hailing service (e.g., taxi service) in the first leg of a trip, a train service in the second leg of the trip, and a flight service in the third leg of the trip. A series of past trips can include information related to each trip that the data owner 130 has made in the past. For example, the information related to a trip can include the travel date, travel duration, number of mobility providers involved in the trip, and the payment means for the trip. The mobility service data related to a series of past trips can include information related to each trip of the series of past trips.

[0060] The data collection system 102 can execute a master service agreement between the data owner 130 and a data operator related to the system (such as an entity that manages the operation of the system 100 or the data collection system 102). The master service agreement can include legal transaction conditions that the data owner 130 needs to agree to as part of the onboarding process. For example, the master service agreement can indicate that the data owner 130 agrees to share mobility service data with the data collection system 102. Furthermore, the master service agreement can require that the mobility service data be an unaltered version of the user's mobility data. Also, the master service agreement (MSA) can indicate that the data owner 130 is the sole owner of the data. Furthermore, the master service agreement (MSA) can indicate that the data owner 130 guarantees that the information provided by the data owner 130 during the onboarding process is genuine.

[0061] When the data owner 130 agrees to the master service agreement, the data collection system 102 can process the mobility service data and extract a data set from the mobility service data based on the execution of the master service agreement. The data set can be stored in the storage device 124 after extraction. Note that the mobility service data can be the raw version of the data set. Therefore, the mobility service data can include redundant information that can be discarded to extract the data set.

[0062] The data collection system 102 can define the data structure (or schema) of a dataset and the data type of each attribute of the dataset. As an example, a decision tree can be used to extract the dataset that is considered most valuable for creating the NFT128. The ownership information of the mobility service data can be removed from the dataset. As an example, various attributes such as the gender of the data owner 130, the travel period, and the places visited during the travel can be collected from the ticket data and used to determine the value of the dataset. In certain embodiments, the data collection system 102 can define a data catalog that includes a logical grouping for extracting datasets. For example, the data collection system 102 can group data points within the mobility service data based on, for example, the type of mobility provider, the means of transportation, and the geographical location. As an example, the mobility service data can include a travel identifier for a trip, a series of locations that the data owner 130 could visit during the trip, a series of mobility providers that the data owner 130 used during the trip, and the payment means that the data owner 130 used during the trip. The payment means or other payment-related information can be confidential data that can be filtered while the data collection system 102 extracts the dataset from the mobility service data.

[0063] At 306, it is possible to determine whether to create an NFT for a dataset. The data collection system 102 can determine whether to create an NFT 128 for a dataset based on the creation conditions of the NFT 128. The creation of the NFT 128 can depend on factors such as the size of the dataset, the type of the dataset, the type of attributes used in the dataset, and the value of the dataset (e.g., from a monetary value or market demand perspective). For example, the type of the dataset can be a genuine type or a tampered type. If the dataset is not genuine, the data collection system 102 can determine not to create the NFT 128 at 308. The sequence diagram 300 can be aborted at 308. On the other hand, if the dataset is genuine, the data collection system 102 can determine to create the NFT 128. Note that the data collection system 102 can create the NFT 128 using standard token specifications such as ERC - 721 and ERC - 1155. The dataset can be classified as an asset and represented via the NFT 128 on the distributed ledger 108. The distributed ledger 108 can also include ownership information related to the data owner 130 indicating that the NFT 128 is owned by the data owner 130.

[0064] At 310, the NFT can be listed on the NFT marketplace 110. When the NFT 128 is created, the data collection system 102 can list the created NFT 128 on the NFT marketplace 110 associated with the distributed ledger 108. The listing of the NFT 128 can include ownership information related to the data owner 130, as well as a preview of the dataset and the NFT 128. As an example, each NFT listed on the NFT marketplace 110 can be tagged with relevant metadata (such as ownership information and preview) to help a purchaser (e.g., data user 132) understand the dataset listed on the NFT marketplace 110. This enables the purchaser (e.g., data user 132) to view, search, filter, and purchase the dataset according to their requirements. Details regarding the listing of the created NFT 128 are further shown, for example, in FIG. 4B.

[0065] At 312, a dataset can be stored in the storage device 124 associated with the middleware system 106. The data collection system 102 can store the dataset in the storage device 124 after the creation of the NFT 128. In certain embodiments, the dataset can be classified and pre-processed based on this classification before being stored in the storage device 124. For example, the dataset can be classified into one of a series of classes (e.g., anonymized, secure, raw, etc.) based on whether the dataset contains personally identifiable information (PII), financial information, demographic details, and the like. In certain embodiments, the dataset can be anonymized before being stored in the storage device 124. For example, values associated with PII within the dataset can be removed or replaced with numerical or alphanumeric identifiers in order to obtain an anonymized version of the dataset. The anonymized version of the dataset can be stored in the storage device 124. In another embodiment, after the creation of the NFT 128, the dataset can be stored in the storage device 124 in an encrypted and / or anonymized form. Encryption of the dataset can ensure that the dataset is securely stored in the storage device 124. This can prevent unauthorized persons or devices from accessing the dataset.

[0066] At 314, a purchase request can be received on the NFT marketplace 110. Before the purchase request is received, the data user 132 can sign up or register as a website user on the NFT marketplace 110. The NFT marketplace 110 can authenticate the data user 132 based on the user identification (ID) and password associated with the data user 132. When the data user 132 is authenticated, the NFT marketplace 110 can provide the data user 132 with an option to link the wallet associated with the data user 132 to the user identification. The middleware system 106 can request a smart contract (such as the first smart contract or the second smart contract) via an administrative wallet or a privilege wallet, and record the public address of the data user 132 as a whitelisted user. Thereafter, the NFT marketplace 110 can receive a purchase request for the NFT 128 from the account of the data user 132. As described above, the NFT 128 can be listed on the NFT marketplace 110. As an example, the data user 132 can interact with the user interface (UI) element associated with the NFT 128 on the NFT marketplace 110 to select the NFT 128. The purchase request for the NFT 128 can be received based on the interaction between the data user 132 and the UI element.

[0067] In one embodiment, the data owner 130 associated with the owner device 104 can specify verifiable credentials including information such as qualification criteria for purchasing NFT assets during onboarding. Such credentials associated with the data user 132 can be verified via the middleware system 106 to determine whether the data user 132 should be permitted to purchase the listed NFT 128.

[0068] When the purchase requirement meets the conditions related to the sale of NFT128, the data collection system 102 can accept the purchase requirement. Thereafter, as payment for the purchase of NFT128, digital assets such as money, digital fiat currency, cryptocurrency, or coupons can be transferred from the account of the data user 132 to the account of the data owner 130, or to the account of a data operator associated with the data collection system 102.

[0069] In one embodiment, the conditions related to the sale of NFT128 can include one or more of the following: the number of times the dataset is permitted to be downloaded by data user 132, restrictions on the period during which data user 132 can download the dataset, restrictions on access to the raw version of the dataset represented by NFT128, restrictions on access to the dataset based on the location of data user 132, restrictions on resale of the dataset by data user 132, restrictions on access to the aggregated data of the dataset, restrictions on the number of copies of the dataset that are permitted, restrictions on the purpose of purchasing NFT128, or restrictions on access to the anonymized version of the dataset. The number of times the dataset is permitted to be downloaded by data user 132 can prevent data user 132 from downloading the dataset indefinitely. For example, the number of times the dataset is permitted to be downloaded can be 2. After the dataset has been downloaded 2 times, data user 132 can be prohibited from downloading the dataset. Restrictions on the period during which the dataset can be downloaded can provide a time window during which the dataset can be downloaded or accessed on analysis system 116. For example, the period during which the dataset can be downloaded can be 2 weeks from the date of purchase of the dataset. After 2 weeks from the date of purchase of the dataset, data user 132 can be made unable to download the dataset. Restrictions on access to the raw version of the dataset represented can indicate whether the raw version of the dataset should be accessed by data user 132. For example, restrictions on access to the raw version of the dataset can obligate that data user 132 should only be able to access the dataset in an encrypted or anonymized form. Restrictions on access to the dataset based on the location of data user 132 can require that the location of data user 132 be within a predetermined geographical area in order to access the dataset.If the location of data user 132 does not exist within a predetermined geographical area, data user 132 can be prevented from accessing the dataset. The restriction on reselling the dataset can prevent data user 132 from reselling the dataset to any person who is not the valid owner of the dataset. The restriction on access to the aggregated data of the dataset can specify whether data user 132 should be able to access the aggregated data. The aggregated data can be, for example, a summary of the dataset. The restriction on the allowable number of copies of the dataset can specify the maximum number of copies of the dataset that data user 132 is permitted to sell. The restriction on the purpose of purchasing NFT128 can prevent data user 132 from purchasing NFT128 for purposes other than a predetermined purpose. For example, the restriction on the purpose of purchasing NFT128 can require that the dataset be used only for descriptive analytics. Therefore, if the purpose of purchasing NFT128 is not for descriptive analytics, the purchase request received from the account of data user 132 can be rejected. The restriction on access to the anonymized version of the dataset can specify whether data user 132 should be able to access the anonymized version.

[0070] The data collection system 102 can update the ownership information of NFT128 on the distributed ledger 108 to include data user 132 based on whether the purchase request meets the conditions related to the sale of NFT128. If the purchase request meets the conditions related to the sale of NFT128, the ownership information of NFT128 can be updated to include the account of data user 132. That is, NFT128 can be transferred to the account of data user 132.

[0071] In 316, the middleware system 106 can receive an access request. When the NFT 128 is purchased, the middleware system 106 can receive an access request from the analysis system 116 to a dataset. For example, the analysis system 116 can send an access request (e.g., an HTTP request or a webhook) to download the dataset from the middleware system 106.

[0072] In 318, ownership verification can be performed. When the middleware system 106 receives an access request, it can verify the ownership information associated with the access request. The middleware system 106 can verify whether the account used for the access or download request of the dataset is the same account as the originator of the purchase request. Specifically, the ownership verification can be performed to verify whether the data user associated with the analysis system 116 is the same as the data user who purchased the NFT 128.

[0073] Once the ownership information is verified, the data collection system 102 can verify whether the access request meets the conditions related to the use of the dataset. In certain embodiments, the conditions related to the use of the dataset can include conditions for providing access to the dataset based on whether the data user 132 accepted the service contract when purchasing the NFT 128, restrictions on the use of the dataset based on the status of the data user 132, or permission to stream the dataset to the analysis system 116. The status of the data user 132 can be a whitelist status or a blacklist status. The service contract can include a set of trading conditions that the data user 132 needs to agree to in order to access the dataset (represented by the NFT 128). If the data user 132 does not agree to the trading conditions of the service contract, the data user 132 can be prevented from using the dataset. The service contract can be a binding agreement between the data user 132 and the data owner 130. In certain embodiments, the service contract can also include conditions related to the sale of the NFT 128.

[0074] The restrictions on the use of the dataset can prevent the data user 132 from using the dataset if the data user 132 is associated with a blacklist status. Often, the data collection system 102 can blacklist data users who have been found to have violated the access rules of the dataset or the conditions related to the use of the dataset in the past. Such users can be given a blacklist status to prevent them from using the dataset in the future.

[0075] Permission to stream a dataset to the analysis system 116 can indicate the conditions under which the analysis system 116 can stream the dataset. For example, permission to stream a dataset to the analysis system 116 can indicate that the analysis system 116 can stream a dataset that it can process on the fly in data subsets of "100" kilobytes in size.

[0076] When the data collection system 102 verifies that the access request meets the conditions related to the use of the dataset, the MaaS network 112 can receive, at 320, a request to audit and track the consumption of the dataset related to the NFT 128. The MaaS network 112 can receive a request to audit and track the NFT 128 from the middleware system 106. The MaaS network 112 can perform validation, auditing, and tracking of the consumption of the dataset related to the NFT 128 over the period during which the service contract between the data user 132 and the data owner 130 is valid.

[0077] In 322, the ML model 126 can receive a request to verify whether an access request meets the access rules of the dataset. The ML model 126 can verify whether an access request meets the access rules of the dataset from the MaaS network 112. In certain embodiments, the access rules of the dataset can include one or more of a list of valid analytics for the dataset, a period during which the dataset can be accessed or downloaded on the analysis system 116, the number of participants who can act on the dataset through the analysis system 116, or a location where the dataset can be downloaded or accessed via the analysis system 116. The list of valid analytics for the dataset can prevent unwanted actions other than those within the list of valid analytics from being performed on the dataset. As an example, the list of valid analytics can include actions such as predicting the demand of a particular mobility provider that has provided services to the data owner 130 in the past, determining a price that the data owner 130 typically prefers to pay as a service fee, and determining key locations that the data owner 130 prefers to visit.

[0078] The period during which the dataset can be accessed or downloaded on the analysis system 116 can be based on a time window in units of hours, days, weeks, or months. After this period, the analysis system 116 can be prohibited from accessing or downloading the dataset. For example, this period can be two weeks from the purchase date of the NFT 128. After two weeks from the purchase date of the NFT 128, the analysis system 116 can be prohibited from accessing or downloading the dataset.

[0079] The number of participants who can act on the dataset through the analysis system 116 can correspond to the number of users who can act on the dataset through the analysis system 116. For example, the number of participants who can act on the dataset can be at most one.

[0080] The location from which the dataset can be downloaded or accessed through the analysis system 116 can correspond to a geographical region. The MaaS network 112 can accept all access requests that can be from that region. The MaaS network 112 can reject access requests from other regions.

[0081] In certain embodiments, the conditions related to the sale of the NFT 128, the access rules for the dataset, or the conditions related to the use of the dataset can be described in a first smart contract on the distributed ledger 108 or a second smart contract on the ledger node of the MaaS network 112. The access request can be verified by executing the first smart contract on the distributed ledger 108 or the second smart contract on the ledger node of the MaaS network 112. For example, if the conditions related to the sale of the NFT 128, the access rules for the dataset, or the conditions related to the use of the dataset are described in the first smart contract on the distributed ledger 108, the first smart contract on the distributed ledger 108 can be executed to determine whether the purchase request for the NFT 128 meets the conditions related to the sale of the NFT 128. The first smart contract on the distributed ledger 108 can be further executed to determine whether the access request meets the access rules for the dataset or the conditions related to the use of the dataset (as described in the first smart contract on the distributed ledger 108).

[0082] According to one embodiment, the ML model 126 can be configured to verify whether an access request meets the access rules of a dataset (as shown in FIG. 3B). In some embodiments, a subset of complex access rules can be externalized from the first smart contract or the second smart contract to the ML model 126. The data collection system 102 can validate the access request based on ownership information and further based on whether the access request meets at least one of the access rules of the dataset and the conditions related to the use of the dataset.

[0083] In 324, the data collection system 102 can receive a request to update information related to the NFT 128 on the NFT marketplace 110. When the access request is validated, the data collection system 102 can update the information related to the access of the dataset on the first smart contract on the distributed ledger 108 so that the analysis system 116 can access or download the dataset. On the NFT marketplace 110, the information related to the NFT 128 can be updated, and the NFT marketplace 110 can notify the data user 132 that the analysis system 116 related to the data user 132 can access or download the dataset.

[0084] In 326, an encrypted copy of the dataset can be provided to the analysis system 116. The analysis system 116 can receive the encrypted copy of the dataset from the middleware system 106. The middleware system 106 can provide the encrypted copy of the dataset so that only authorized users can securely access the dataset.

[0085] At 328, the decryption operation of the encrypted copy of the received dataset can be executed. In certain embodiments, the data collection system 102 can share a secret key with the account of the data user 132 based on the validation of the access request to the analysis system 116. The analysis system 116 can decrypt the encrypted copy of the dataset based on the received secret key and obtain the dataset in an unencrypted form. In certain embodiments, the secret key can be retrieved from the distributed ledger 108, and the analysis system 116 can decrypt the encrypted copy of the dataset using the account of the data user 132 and the secret key. Thereafter, the analysis system 116 can perform an analysis on the dataset in an unencrypted form. For example, the analysis system 116 can analyze the dataset in an unencrypted form to determine the means of transportation that the data owner 130 is most likely to have used and the locations that the data owner 130 has frequently visited.

[0086] The data collection system 102 can monitor the analysis performed on the dataset in an unencrypted form and determine the consumption pattern of the provided copy on the analysis system 116. For example, the consumption pattern can include the analysis operations performed on the dataset in an unencrypted form and the number of times the analysis has been performed on the dataset in an unencrypted form. Further, the consumption pattern can include the number of times the dataset has been downloaded, attempts to forge user accounts to access the dataset, attempts to resell the dataset, attempts to tamper with the dataset, and attempts to transfer the dataset outside the analysis system 116.

[0087] The data collection system 102 can control access to a copy of the dataset on the analysis system 116 based on the consumption pattern. In certain embodiments, the data collection system 102 can determine a violation of conditions related to the sale of the NFT 128, access rules for the dataset, or conditions related to the use of the dataset based on the consumption pattern. For example, if an analysis performed on the dataset in unencrypted form is determined to be an invalid (or unsafe) analysis, the data collection system 102 can determine this operation as a violation of the conditions related to the use of the dataset.

[0088] In certain embodiments, violations can be determined by using the ML model 126. The ML model 126 can be trained to determine violations based on the consumption pattern. The ML model 126 can receive the consumption pattern as input and determine a violation based on the analysis of the consumption pattern. As an example, the data user 132 may attempt to resell the dataset to another party. The consumption pattern can include information related to the attempt to resell the dataset. The ML model 126 can determine a violation of the conditions related to the sale of the NFT 128 based on the attempt within the consumption pattern. Also, the ML model 126 can determine malicious behavior of the data user 132 or detect improper consumption of the dataset (e.g., exceeding the inventory limit defined in the conditions related to the sale of the NFT 128). When a violation is detected, the data user 132 may lose the access right to the dataset on the analysis system 116. In some cases, the data collection system 102 can issue a warning to the data user or block the data user 132 for a determined period or an indefinite period.

[0089] In one embodiment, the data collection system 102 or the ML model 126 can generate feedback based on the determination of a violation. The generated feedback can be sent to the user device 114. The data collection system 102 can control the user device 114 associated with the data user 132 to render the feedback. For example, a notification can be popped up and displayed on the user device 114 associated with the data user 132. The notification can indicate that a violation of the usage conditions has been determined on the analysis system 116. In one embodiment, the generated feedback can be sent to the data collection system 102. The data collection system 102 can control the middleware system 106 to block the analysis system 116 from accessing a copy of the dataset or an encrypted copy of the dataset.

[0090] Figures 4A and 4B collectively show an exemplary scenario of data provisioning using non-fungible tokens according to an embodiment of the present disclosure. The descriptions of Figures 4A and 4B are made in relation to the elements of Figures 1, 2, 3A, and 3B. Exemplary scenario 400 is shown in Figures 4A and 4B. Exemplary scenario 400 can include mobility service data 402, dataset 404, NFT 406, user device 408, user interface (UI) 410A, first UI element 412A, second UI element 412B, third UI element 412C, fourth UI element 412D, user interface (UI) 410B, fifth UI element 414A, and sixth UI element 414B. Here, a series of operations related to the exemplary scenario will be described.

[0091] During operation, the data collection system 102 can receive mobility service data 402 from an owner device (e.g., owner device 104). The mobility service data 402 can be a raw data set related to the movement history of a data owner (e.g., data owner 130). The mobility service data 402 can include information related to "N" trips made by the data owner 130. For each trip, a trip identifier (ID) related to the trip, the name of the locations visited by the data owner 130 during the trip, the expenses incurred during the trip, the mobility provider used for movement during the trip, and the payment means used during the trip can be specified. For example, from the mobility service data 402, it can be observed that for the trip with trip ID "1", the data owner 130 moved from Columbus to Cleveland using one or more carpooling services. Further, the expenses incurred during the trip with trip ID "1" are $10, and it can be assumed that the data owner 130 used wallet "A" for payment.

[0092] The data collection system 102 can extract a data set 404 from the mobility service data 402. The mobility service data 402 can be filtered to exclude specific confidential information included in the mobility service data 402. For example, the mobility service data 402 can be filtered by removing the column of payment means from the mobility service data 402.

[0093] The data collection system 102 can create an NFT 406 on a distributed ledger such as the distributed ledger 108. When the NFT is minted, the data collection system 102 can store custom metadata. The metadata can include information such as ownership information, a Uniform Resource Identifier (URI) that can be linked to a data set that is the source of truth present off-chain. Smart contracts, such as a first smart contract on the distributed ledger 108, can describe conditions related to the sale of the NFT 406, access rules for the data set, or conditions related to the use of the data set. The NFT 406 can include information related to the address of the smart contract and a smart contract identifier (ID) associated with the smart contract. Referring to FIG. 4A, the address of the smart contract can be "0xc0ffec254728269b83B" and the smart contract ID can be "58213".

[0094] The NFT406 can be listed on an NFT marketplace such as the NFT marketplace 110. The NFT marketplace 110 can be accessed via a web client on the user device 408. In Figure 4B, the NFT406 is shown as a listing on the first UI 410A of the NFT marketplace 110. The first UI 410A can be associated with a first UI element 412A, a second UI element 412B, a third UI element 412C, and a fourth UI element 412D. The first UI element 412A can provide information related to the current owner of the dataset 404 (e.g., the data owner 130). This information can include, for example, the NFT ID, the owner's wallet ID, and the address of the NFT406 on the distributed ledger 108. The first UI element 412A can indicate that the NFT ID of the NFT406 is "48213", the owner's wallet ID associated with the data owner 130 is "0zA3967b", and the address of the NFT406 on the distributed ledger 108 is "0xc0ffec25b678269A83B".

[0095] The second UI element 412B can provide a preview of the dataset 404 associated with the NFT406. Referring to Figure 4B, the second UI element 412B can indicate that the dataset 404 associated with the NFT406 contains 1000 records and 200 columns and is an anonymized version. The third UI element 412C can include the price of the NFT406. Referring to Figure 4B, the third UI element 412C can indicate that the price of the NFT406 is $100. The data user 132 can analyze the information related to the current owner of the dataset 404 (e.g., the data owner 130), the preview of the dataset 404 associated with the NFT406, and the price of the NFT406 to determine whether to purchase the NFT406. The NFT marketplace 110 can receive a request to purchase the NFT406 based on the interaction between the data user 132 and the fourth UI element 412D.

[0096] When the NFT marketplace 110 receives a request to purchase the NFT 406, it can switch to the second user interface 410B. The second user interface 410B can be displayed on the user device 408. The second user interface 410B can provide a fifth UI element 414A and a sixth UI element 414B. The fifth UI element 414A can provide the transaction conditions related to the NFT 406. Referring to FIG. 4B, the transaction conditions provided within the fifth UI element 414A can require that the dataset 404 be used only for descriptive analysis, that the data user 132 shall not share or sell the dataset 404 to a third party, and that the dataset 404 shall not be manipulated or altered in any form. The data user 132 can read the transaction conditions related to the NFT 406 and decide to purchase the NFT 406. The NFT marketplace 110 can receive an acceptance of the transaction conditions provided in the fifth UI element 414A based on the selection of the sixth UI element 414B. Thereafter, a payment of $100 can be made from the account of the data user 132 to the account of the data owner 130 or the data collection system 102.

[0097] FIG. 5 is a block diagram showing an exemplary data collection system of FIG. 1 according to an embodiment of the present disclosure. The description of FIG. 5 is made in relation to the elements of FIGS. 1, 2, 3A, 3B, 4A, and 4B. FIG. 5 shows a block diagram 500 of the system 100 of FIG. 1. The system 100 can include a circuit 502, a memory 504, an input / output (I / O) device 506, and a network interface 508. The input / output (I / O) device 506 can include a display device 510.

[0098] The circuit 502 can include suitable logic, circuits, and / or interfaces configured to execute program instructions related to different operations performed by the data collection system 102. The circuit 502 can include one or more processing units that can be implemented as a stand-alone processor. In some embodiments, one or more processing units can be implemented as an integrated processor or a group of processors that collectively execute the functions of the one or more processing units. The circuit 502 can be implemented based on a plurality of processor technologies well known in the art. Examples of implementations of the circuit 502 can be an X86-based processor, a graphics processing unit (GPU), a reduced instruction set computing (RISC) processor, an application-specific integrated circuit (ASIC) processor, a complex instruction set computing (CISC) processor, a microcontroller, a central processing unit (CPU), and / or other control circuits.

[0099] The memory 504 can include suitable logic, circuits, interfaces, and / or code configured to store one or more instructions executed by the circuit 502. The memory 504 can be configured to store a data set. Examples of implementations of the memory 504 can include, but are not limited to, random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), hard disk drive (HDD), solid state drive (SSD), CPU cache, and / or secure digital (SD) card.

[0100] The I / O device 506 can include suitable logic, circuitry, interfaces, and / or code configured to receive an input and provide an output based on the received input. For example, the I / O device 506 can receive a first user input indicating an onboarding request. The I / O device 506 can include a display device 510. Examples of the I / O device 506 can include, but are not limited to, a touch screen, a keyboard, a mouse, a joystick, a microphone, or a speaker.

[0101] The network interface 508 can include suitable logic, circuitry, interfaces, and / or code configured to facilitate communication between the data collection system 102 and the server 118 via the communication network 122. The network interface 508 can be implemented to support wired or wireless communication between the data collection system 102 and the communication network using various known techniques. The network interface 508 can include, but is not limited to, an antenna, a radio frequency (RF) transceiver, one or more amplifiers, a tuner, one or more oscillators, a digital signal processor, a coder-decoder (CODEC) chipset, a subscriber identity module (SIM) card, or a local buffer circuit.

[0102] The network interface 508 can be configured to communicate via wireless communication with a network such as the Internet, an intranet, a wireless network, a cellular telephone network, a wireless local area network (LAN), or a metropolitan area network (MAN). The wireless communication can use one or more of a plurality of communication standards, protocols, and technologies such as Global System for Mobile Communications (GSM), Enhanced Data GSM Environment (EDGE), Wideband Code Division Multiple Access (W-CDMA), Long Term Evolution (LTE), 5th Generation (5G) New Radio (NR), Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Bluetooth, Wireless Fidelity (WiFi) (such as IEEE802.11a, IEEE802.11b, IEEE802.11g, or IEEE802.11n), Voice over Internet Protocol (VoIP), Light Fidelity (Li-Fi), Worldwide Interoperability for Microwave Access (Wi-MAX), protocols for email, instant messaging, and Short Message Service (SMS).

[0103] The display device 510 can include suitable logic, circuitry, and interfaces configured to display information related to the dataset and conditions related to the sale of the NFT 128. The display device 510 can be a touch screen that allows a user (e.g., the data owner 130) to provide user input via the display device 510. The touch screen can be at least one of a resistive touch screen, a capacitive touch screen, or a thermal touch screen. The display device 510 can be implemented through a plurality of known technologies, such as, but not limited to, a liquid crystal display (LCD) display, a light emitting diode (LED) display, a plasma display, or an organic LED (OLED) display technology, or at least one of other display devices. According to an embodiment, the display device 510 can refer to the display screen of a head-mounted display (HMD), smart glasses, a see-through display, a projection-based display, an electrochromic display, or a transparent display.

[0104] Figure 6 is a flowchart showing the operations of an exemplary method for data provisioning using non-fungible tokens, according to an embodiment of the present disclosure. The description of Figure 6 is made in relation to the elements of Figures 1, 2, 3A, 3B, 4A, 4B, and 5. Figure 6 shows a flowchart 600. The flowchart 600 includes operations 602-618 and can be executed by the data collection system 102, the owner device 104, the middleware system 106, the distributed ledger 108, the NFT marketplace 110, the MaaS network 112, the user device 114, the analysis system 116 of Figure 1, or the circuitry 502 of Figure 2. The flowchart 600 can start at 602 and proceed to 604.

[0105] At 604, a dataset related to data owner 130 can be stored in storage device 124. Data collection system 102 can control middleware system 106 to store the dataset related to data owner 130 in storage device 124. Details regarding the storage of the dataset are shown, for example, in FIG. 3A.

[0106] At 606, NFT marketplace 110 can receive a purchase request for NFT 128 from the account of data user 132. NFT marketplace 110 can receive a purchase request for NFT 128 from the account of data user 132. NFT 128 can represent a dataset on distributed ledger 108. Details regarding the purchase request are shown, for example, in FIG. 3A.

[0107] At 608, based on whether the purchase request meets the conditions related to the sale of NFT 128, the ownership information of NFT 128 on distributed ledger 108 can be updated to include data user 132. Data collection system 102 can update the ownership information of NFT 128 on distributed ledger 108 to include data user 132 based on whether the purchase request meets the conditions related to the sale of NFT 128. Details regarding the ownership information are shown, for example, in FIG. 3B.

[0108] At 610, a request to access the dataset can be received. Middleware system 106 can receive a request to access the dataset. Details regarding the access request are shown, for example, in FIG. 3B.

[0109] At 612, the access request can be verified based on ownership information and whether the access request satisfies at least one of the access rules of the dataset and the conditions related to the use of the dataset. The data collection system 102 can verify the access request based on ownership information and whether the access request satisfies at least one of the access rules of the dataset and the conditions related to the use of the dataset. Details regarding the verification of the access request are shown, for example, in FIG. 3B.

[0110] At 614, a copy of the dataset can be provided from the storage device 124 to the analysis system 116 associated with the data user 132. The data collection system 102 can control the middleware system 106 to provide a copy of the dataset from the storage device 124 to the analysis system 116 associated with the data user 132 based on the verification. Details regarding the provision of the copy of the dataset are shown, for example, in FIG. 3B.

[0111] At 616, the consumption pattern of the provided copy can be determined on the analysis system 116. The data collection system 102 can determine the consumption pattern of the provided copy on the analysis system 116. Details regarding the consumption pattern are shown, for example, in FIG. 3B.

[0112] At 618, based on the consumption pattern, access to the copy of the dataset on the analysis system 116 can be controlled. The data collection system 102 can control access to the copy of the dataset on the analysis system 116 based on the consumption pattern. Details regarding the control of access to the copy of the dataset are shown, for example, in FIG. 3B. The control can proceed to termination.

[0113] Regarding flowchart 600, it is shown as discrete operations such as 604, 606, 608, 610, 612, 614, 616, and 618, but the present disclosure is not limited to this. Thus, in some embodiments, such discrete operations can be further divided into additional operations, combined into fewer operations, or deleted according to the implementation without impairing the essence of the disclosed embodiments.

[0114] Various embodiments of the present disclosure can provide a non - transitory computer - readable medium and / or storage medium storing computer - executable instructions executable by a machine and / or computer to operate a system (e.g., the data collection system 102 of FIG. 1). Such instructions can cause the data collection system 102 to perform operations including storing a data set related to a data owner (e.g., the data owner 130 of FIG. 1) in a storage device (e.g., the storage device 124 of FIG. 1). The operations can further include receiving, from an account of a data user (e.g., the data user 132 of FIG. 1), a purchase request for a non - fungible token (NFT) (e.g., the NFT 128 of FIG. 1) representing the data set on a distributed ledger (e.g., the distributed ledger 108 of FIG. 1). The operations can further include updating the ownership information of the NFT 128 on the distributed ledger 108 to include the data user 132 based on whether the purchase request meets the conditions related to the sale of the NFT 128. The operations can further include receiving an access request to the data set. The operations can further include validating the access request based on the ownership information and whether the access request meets at least one of the access rules of the data set and the conditions related to the use of the data set. The operations can further include providing a copy of the data set from the storage device 124 to an analysis system (e.g., the analysis system 116 of FIG. 1) related to the data user 132 based on the validation. The operations can further include determining, on the analysis system 116, a consumption pattern of the provided copy. The operations can further include controlling access to the copy of the data set on the analysis system 116 based on the consumption pattern.

[0115] Exemplary aspects of the present disclosure can provide a system (e.g., the data collection system 102 of FIG. 1). The system can store a dataset related to a data owner (e.g., the data owner 130 of FIG. 1) in a storage device (e.g., the storage device 124 of FIG. 1). The system can receive a purchase request for a non-fungible token (NFT) (e.g., the NFT 128 of FIG. 1) representing the dataset on the distributed ledger (e.g., the distributed ledger 108 of FIG. 1) from an account of a data user (e.g., the data user 132 of FIG. 1). The system can update the ownership information of the NFT 128 on the distributed ledger 108 to include the data user 132 based on whether the purchase request meets the conditions related to the sale of the NFT 128. The system can receive an access request to the dataset. The system can verify the validity of the access request based on the ownership information and whether the access request meets at least one of the access rules of the dataset and the conditions related to the use of the dataset. The system can provide a copy of the dataset from the storage device 124 to an analysis system (e.g., the analysis system 116 of FIG. 1) related to the data user 132 based on the verification. The system can determine the consumption pattern of the provided copy on the analysis system 116. The system can control access to the copy of the dataset on the analysis system 116 based on the consumption pattern.

[0116] In one embodiment, the data collection system 102 can receive mobility service data 402 related to a past series of trips made by the data owner 130 via multiple mobility service providers. The data collection system 102 can execute a master service contract between the data owner 130 and a data operator related to the data collection system 102. The data collection system 102 can extract a dataset 404 from the mobility service data based on the execution, and the dataset 404 can be stored in the storage device 124 after extraction.

[0117] In one embodiment, the data collection system 102 can create an NFT 128 on the distributed ledger 108 based on whether the dataset 404 meets the creation conditions of the NFT 128. The data collection system 102 can list the created NFT 128 on the NFT marketplace 110 associated with the distributed ledger 108, and the listing of the NFT 128 includes ownership information related to the data owner 130 and a preview of the dataset 404 that the NFT 128 can represent.

[0118] In one embodiment, after creating the NFT 128, the dataset 404 can be stored in the storage device 124 in an encrypted and / or anonymized form.

[0119] In one embodiment, the system can further include a MaaS network 112 that includes a message broker 204, a series of issuer nodes 202A, 202B,... 202N, a series of distributed ledger nodes 212, and a series of subscriber nodes 206A, 206B... 206N that communicate with the series of issuer nodes 202A, 202B,... 202N via the message broker (e.g., the message broker 204 in FIG. 2). The series of issuer nodes can be communicatively coupled to the distributed ledger 108.

[0120] In one embodiment, conditions related to the sale of the NFT 128, access rules for the dataset 404, or conditions related to the use of the dataset 404 can be described in a first smart contract on the distributed ledger 108 or a second smart contract on the ledger nodes of the MaaS network 112.

[0121] In one embodiment, access requests can be verified by executing a first smart contract on the distributed ledger 108 or a second smart contract on the ledger nodes of the MaaS network 112.

[0122] In one embodiment, the access rules for dataset 404 can include one or more of a list of valid analyses for dataset 404, a period during which dataset 404 is accessible or downloadable on analysis system 116, the number of participants who can act on dataset 404 through analysis system 116, or a location where dataset 404 is downloadable or accessible via analysis system 116.

[0123] In an embodiment, the conditions related to the sale of NFT 128 can include one or more of the number of times dataset 404 can be downloaded by data user 132, restrictions on the period during which data user 132 can download dataset 404, restrictions on access to the raw version of dataset 404 represented by NFT 128, access restrictions to dataset 404 based on the location of data user 132, restrictions on resale of dataset 404 by data user 132, restrictions on access to the aggregated data of dataset 404 represented by NFT 128, restrictions on the number of copies of dataset 404 that are allowed, restrictions on the purpose of purchasing NFT 128 by data user 132, or restrictions on access by data user 132 to the anonymized version of dataset 404.

[0124] In one embodiment, the conditions related to the use of dataset 404 can include one or more of access to dataset 404 represented by NFT 128 based on acceptance of a service contract by data user 132, restrictions on the use of dataset 404 based on the status of data user 132, and permission to stream dataset 404 to analysis system 116, where the status of data user 132 can be a whitelist status or a blacklist status.

[0125] In one embodiment, the data collection system 102 can share the account and private key of the data user 132 based on the validation of the access request, and the copy of the dataset can be an encrypted copy. The analysis system 116 can decrypt the encrypted copy 404 of the dataset based on the private key to obtain the dataset in an unencrypted form.

[0126] In one embodiment, based on the consumption pattern, it is possible to determine a violation of the conditions related to the sale of the NFT 128, the access rules for the dataset 404, or the conditions related to the use of the dataset 404.

[0127] In one embodiment, the data collection system 102 can generate feedback based on the determination of the violation. The data collection system 102 can control the user device 114 associated with the data user 132 to render the feedback.

[0128] In one embodiment, the use of the ML model 126 can determine the violation.

[0129] The present disclosure includes all features that enable the implementation of the methods described herein, and can also be positioned in a computer program product that can execute these methods when loaded into a computer system. A computer program in this context means any representation in any language, code, or notation of a set of instructions intended to be executed by a system with information processing capabilities, either directly or after performing either or both of a) conversion to another language, code, or notation, and b) replication in a different form of content.

[0130] Although the present disclosure has been described with reference to several embodiments, those skilled in the art will understand that various changes can be made and equivalents can be substituted without departing from the scope of the present disclosure. Also, many modifications can be made to adapt a particular situation or content to the teachings of the present disclosure without departing from the scope of the present disclosure. Therefore, the present disclosure is not limited to the specific embodiments disclosed, but is intended to cover all embodiments falling within the scope of the appended claims.

Explanation of Reference Numerals

[0131] 100 System 102 Data Collection System 104 Owner Device 106 Middleware System 108 Distributed Ledger 110 NFT Marketplace 112 Mobility as a Service (MaaS) Network 114 User Device 116 Analysis System 118 Server 120 Database 122 Communication Network 124 Storage Device 126 Machine Learning (ML) Model 128 Non-Fungible Token 130 Data Owner 132 Data User

Claims

1. In a system including a storage device that stores a dataset related to a data owner, receiving a purchase request for a non-fungible token (NFT) representing the dataset on a distributed ledger from an account of a data user; updating the ownership information of the NFT on the distributed ledger to include the data user, based on whether the purchase request satisfies conditions related to the sale of the NFT; receiving an access request to the dataset; validating the access request based on the ownership information and whether the access request satisfies at least one of an access rule for the dataset and conditions related to the use of the dataset; providing a copy of the dataset from the storage device to an analysis system related to the data user based on the validation; determining a consumption pattern of the provided copy on the analysis system; controlling access to the copy of the dataset on the analysis system based on the consumption pattern; A method characterized by including the above.

2. receiving mobility service data related to a past series of trips made by the data owner via a plurality of mobility service providers; executing a master service contract between the data owner and a data operator related to the system; extracting the dataset from the mobility service data based on the execution; further including, wherein the dataset is stored in the storage device after the extraction, The method according to claim 1.

3. creating the NFT on the distributed ledger based on whether the dataset satisfies NFT creation conditions; listing the created NFT on an NFT marketplace related to the distributed ledger; further including, The listing of the NFT includes ownership information related to the data owner and a preview of the dataset represented by the NFT, The method according to claim 1.

4. The dataset is stored in the storage device in an encrypted or anonymized form after the creation of the NFT, The method according to claim 3.

5. The system further includes a mobility as a service (MaaS) network including a message broker, a series of issuer nodes, a series of distributed ledger nodes, and a series of subscriber nodes communicating with the series of issuer nodes via the message broker, The series of issuer nodes are communicatively coupled to the distributed ledger, The method according to claim 1.

6. The conditions related to the sale of the NFT, the access rules of the dataset, or the conditions related to the use of the dataset are described in a first smart contract on the distributed ledger or a second smart contract on the ledger nodes of the MaaS network, The method according to claim 5.

7. The access request is verified by executing the first smart contract on the distributed ledger or the second smart contract on the ledger nodes of the MaaS network, The method according to claim 6.

8. The access rules of the dataset include one or more of a list of valid analyses for the dataset, a period during which the dataset can be accessed or downloaded on the analysis system, the number of participants who can act on the dataset through the analysis system, or locations where the dataset can be downloaded or accessed through the analysis system. The method according to claim 1.

9. The conditions related to the sale of the NFT include one or more of the number of times the dataset can be downloaded by the data user, restrictions on the period during which the data user can download the dataset, restrictions on access to the raw version of the dataset represented by the NFT, access restrictions to the dataset based on the location of the data user, restrictions on reselling the dataset by the data user, restrictions on access to the aggregated data of the dataset represented by the NFT, restrictions on the number of copies of the dataset that are allowed, restrictions on the purpose of purchasing the NFT by the data user, or restrictions on access to the anonymized version of the dataset by the data user. The method according to claim 1.

10. The conditions related to the use of the dataset include conditions for providing access to the dataset based on whether the data user accepted a service contract at the time of purchasing the NFT, restrictions on the use of the dataset based on the status of the data user, and allowing streaming of the dataset to the analysis system, where the status of the data user is a whitelist status or a blacklist status. The method according to claim 1.

11. Sharing a secret key with the data user's account based on the validation of the access request, wherein a copy of the dataset is an encrypted copy, Decrypting the encrypted copy of the dataset based on the secret key to obtain a non-encrypted form of the dataset, The method according to claim 1, further comprising.

12. Further comprising determining a violation of conditions related to the sale of the NFT, access rules for the dataset, or conditions related to the use of the dataset based on the consumption pattern. The method according to claim 1.

13. Generating feedback based on the determination of the violation, Controlling a user device related to the data user to render the feedback, The method according to claim 12, further comprising.

14. The violation is determined using a machine learning (ML) model. The method according to claim 12.

15. A storage device configured to store a dataset related to a data owner, A circuit, A system comprising, wherein the circuit Receives a purchase request for a non-fungible token (NFT) representing a dataset on a distributed ledger from a data user's account, Updates the ownership information of the NFT on the distributed ledger to include the data user based on whether the purchase request meets the conditions related to the sale of the NFT, Receives an access request to the dataset, Validates the access request based on the ownership information and whether the access request meets at least one of the access rules for the dataset and the conditions related to the use of the dataset, Provides a copy of the dataset from the storage device to an analysis system related to the data user based on the validation. Determine the consumption pattern of the provided copy on the analysis system, Based on the consumption pattern, control access to the copy of the dataset on the analysis system, Is configured to, A system characterized by that.

16. The circuit, Receives mobility service data related to a past series of trips made by the data owner through multiple mobility service providers, Executes a master service contract between the data owner and a data operator related to the system, Based on the execution, extracts the dataset from the mobility service data, Is further configured to, and the dataset is stored in the storage device after the extraction, The system according to claim 15.

17. The circuit, Creates the NFT on the distributed ledger based on whether the dataset meets the creation conditions of the NFT, Lists the created NFT on an NFT marketplace related to the distributed ledger, Is further configured to, The list of the NFT includes ownership information related to the data owner and a preview of the dataset represented by the NFT, The system according to claim 15.

18. The dataset is stored in the storage device in an encrypted or anonymized form after the creation of the NFT, The system according to claim 17.

19. Further includes a Mobility as a Service (MaaS) network including a message broker, a series of issuer nodes, a series of distributed ledger nodes, and a series of subscriber nodes that communicate with the series of issuer nodes via the message broker, The series of issuer nodes are communicatively coupled to the distributed ledger, The system according to claim 15.

20. A non-transitory computer-readable medium storing computer-executable instructions, and the computer-executable instructions, when executed by a system, Receive a purchase request for a non-fungible token (NFT) representing a dataset on a distributed ledger from an account of a data user, Update the ownership information of the NFT on the distributed ledger to include the data user based on whether the purchase request meets the conditions related to the sale of the NFT, Receive an access request to the dataset, Validating the access request based on the ownership information and whether the access request satisfies at least one of the access rules of the dataset and the conditions related to the use of the dataset; Providing a copy of the dataset from the storage device to an analysis system related to the data user based on the validation; Determining a consumption pattern of the provided copy on the analysis system; Controlling access to the copy of the dataset on the analysis system based on the consumption pattern; A non-transitory computer-readable medium, characterized in that the system is caused to execute operations including the above.

Images