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 to U.S. Patent Application No. 18 / 188,172, filed with the U.S. Patent and Trademark Office on March 22, 2023, which claims priority to U.S. Provisional Patent Application Serial No. 63 / 366,781, filed on June 22, 2022, the entire contents of which are incorporated herein by reference.

[0002] Various embodiments of the present disclosure relate to non-fungible tokens, and more particularly, to electronic devices and methods for a data provisioning framework using non-fungible tokens. [Background technology]

[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 offer multimodal transportation services to users through a MaaS application. Based on these services, the software application can accumulate large amounts of data about each user over a period of time. This data can be useful for applications such as fleet operations in a geographical area or demand estimation for services offered by the mobility service provider. Depending on the significance or size of the data, data owners may wish to sell or share the data with users under certain terms and conditions. In traditional IT systems that follow a client-server model, it can be difficult to identify customers who purchase data with the malicious intent of exploiting, manipulating, or reselling it for commercial purposes. It can be even more difficult for traditional IT systems to prevent such data from being misused or attempted to be tampered with or resold. Summary of the Invention [Problem to be solved by the invention]

[0004] The limitations and disadvantages of conventional approaches will become apparent to those skilled in the art by comparing the described system with certain aspects of the present disclosure illustrated in the remainder of this application and with reference to the drawings. [Means for solving the problem]

[0005] A system and method for a data provisioning framework using non-fungible tokens is provided substantially as hereinbefore illustrated and / or described in connection with at least one of the figures and more fully set forth in the claims.

[0006] These and other features and advantages of the present disclosure will become apparent from a consideration of the following detailed description of the disclosure when taken in conjunction with the accompanying drawings, in which like reference characters refer to like elements throughout. [Brief explanation of the drawings]

[0007] [Figure 1] FIG. 1 is a block diagram illustrating an exemplary system for data provisioning using non-fungible tokens, according to an embodiment of the present disclosure. [Figure 2] 2 is a block diagram illustrating the example Mobility as a Service (MaaS) transportation network of FIG. 1 in accordance with an embodiment of the present disclosure. [Figure 3A] 3B, together with an exemplary sequence of operations for data provisioning using non-fungible tokens, according to an embodiment of the present disclosure. [Figure 3B] 3A, together with an exemplary sequence of operations for data provisioning using non-fungible tokens, according to an embodiment of the present disclosure. [Figure 4A] 4B, together with FIG. 4C, illustrate an exemplary scenario for data provisioning using non-fungible tokens, according to embodiments of the present disclosure. [Figure 4B] 4A, together with FIG. 4B, illustrates an exemplary scenario for data provisioning using non-fungible tokens, according to an embodiment of the present disclosure. [Figure 5] 1 is a block diagram illustrating an exemplary data collection system according to an embodiment of the present disclosure. [Figure 6] 1 is a flowchart illustrating operations of an exemplary method for data provisioning using non-fungible tokens, according to an embodiment of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0008] The following embodiments can be found in a system and method for data provisioning using non-fungible tokens. The system covers an end-to-end process of a digital supply chain process, such as the creation or definition of a dataset (original data), its sale, ownership of the dataset, and consumption of the dataset for analytical purposes. An exemplary aspect 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 associated with a data owner in a storage device. The system can receive a purchase request for a non-fungible token (NFT) from one or more accounts of a data user at any time. The NFT can represent a dataset on a distributed ledger. Based on whether the purchase request satisfies conditions related to the sale of the NFT, the system can update ownership information of the NFT on the distributed ledger to include the data user. The system then receives a request to access the dataset. The access request is validated based on the ownership information and whether the access request satisfies at least one of the dataset's access rules and conditions related to the use of the dataset. Based on the validation, the system can provide a copy of the dataset from the storage device to an analytical system associated with the data user. The system can determine consumption patterns of the provided copies on the analysis system after the copies are provided, and control access to the copies of the dataset on the analysis system based on the consumption patterns.

[0009] Applications connecting different mobility providers can generate large amounts of datasets. Data owners can own such datasets. For example, a user of an application that provides MaaS using one or more public or private transportation modes can be a data owner of a dataset of MaaS trips. For example, the dataset can include information on the use of transportation ticket types, such as single-use tickets, registration-based tickets, and season tickets. If the dataset is valuable, the data owner may want to share or sell the dataset to trusted parties. In traditional IT systems, it can be difficult to detect customers who use the dataset improperly for commercial purposes, tamper with the dataset, or purchase the dataset with the intention of reselling it. In traditional IT systems, it can be much more difficult to prevent such misuse or attempts to tamper with or resell the dataset. Therefore, there is a need for a data provisioning framework that ensures secure and tamper-proof access to such datasets.

[0010] To address these issues and meet these needs, the present disclosure introduces a system that provides data provisioning using non-fungible tokens. The disclosed system can leverage a distributed ledger to protect ownership and access permissions for datasets. Once such datasets are created on the distributed ledger, an encrypted version of the dataset can be shared using open technology to prevent illegal copying of the dataset. For example, the disclosed system can create an NFT on a public distributed ledger based on whether the dataset meets the conditions for creating an 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 a data user's account. For example, the purchase request can be received based on a selection of a listed NFT on the NFT marketplace. The system can determine whether the purchase request meets the conditions associated with the sale of the NFT. The data user can then pay for the purchase of the NFT. Once 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 a request for access to a dataset via a user device and validate the access request based on the ownership information and further based on whether the access request satisfies at least one of the dataset's access rules and conditions associated with the use of the dataset. Based on the validation, the system can provide a copy of the dataset from the storage device to an analysis system and determine a consumption pattern of the dataset. Based on the consumption pattern, access to the copy of the dataset on the analysis system can be controlled. Thus, the system provides a data provisioning framework for securely sharing datasets, such as travel data, with limited participants who have ownership of NFTs for the dataset. The system can further protect rights regarding the use of the dataset and prevent illegal copying of the dataset.

[0012] FIG. 1 is a block diagram illustrating an exemplary system for data provisioning using non-fungible tokens, according to an embodiment of the present disclosure. FIG. 1 illustrates a diagram of a system 100. The system 100 may 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 analytics system 116, a server 118, a database 120, and a communication network 122. The middleware system 106 may include a storage device 124. The MaaS network 112 may include a machine learning (ML) model 126. The distributed ledger 108 may be used to store NFTs purchased on an NFT marketplace 110. As an example, the NFT marketplace 110 may list NFTs 128 for a dataset. The data collection system 102, owner device 104, middleware system 106, distributed ledger 108, MaaS network 112, user device 114, analytics system 116, and server 118 may be communicatively coupled to each other via a communications network 122. Figure 1 further shows a data owner 130, which may be associated with the owner device 104, and a data user 132, which may be associated with the user device 114. The data owner 130 may be the initial owner of the dataset.

[0013] System 100 may include suitable logic, circuitry, and interfaces that can be configured to provide a secure data provisioning mechanism for datasets associated with various data owners. System 100 may enable data owners (e.g., data owner 130) to submit datasets to request the creation of NFTs (e.g., NFT 128) on distributed ledger 108. Once created, such NFTs may be listed on NFT marketplace 110, and data users (e.g., data user 132) may purchase NFTs (e.g., NFT 128) to access the respective datasets represented by such NFTs. System 100 may also enable secure storage of datasets through the use of suitable encryption techniques (e.g., asymmetric encryption techniques that encrypt datasets using public and private keys). Examples of system 100 may 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 with multiple shared resources, a network of computer workstations, a network of edge devices, or combinations thereof.

[0014] The data collection system 102 may include suitable logic, circuitry, and interfaces that can be configured to receive a dataset from a data owner 130 and create an NFT 128 on the distributed ledger 108 based on whether the dataset (i.e., the data submitted by the data owner 130) meets the conditions for creating the NFT 128. The data collection system 102 may receive a purchase request for the NFT 128 from an account of a data user 132. The account may 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 may be associated with a decentralized application (DApp) that can be linked to the distributed ledger 108. The DApp may include functionality for searching, listing, and purchasing NFTs. Access to the DApp may be authenticated based on an account associated with the DApp, a decentralized identifier, etc. The data collection system 102 may update 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 associated with the sale of the NFT 128. Examples of data collection systems 102 include, but are not limited to, a network of Internet of Things (IoT) devices, a cluster of mainframe machines, a centralized server, a data center with multiple shared resources, a network of computer workstations, or a network of edge devices.

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

[0016] The middleware system 106 may include a software application that may act as a bridge between the storage device 124 and applications running on the data collection system 102. The middleware system 106 may be responsible for managing and distributing the data stored on the storage device 124.

[0017] The distributed ledger 108 can be a decentralized, distributed database system that maintains an immutable record of data operations or transactions. A series of data operations can be grouped into a block and further linked to previous data operation blocks to form a chain of blocks. All data operation blocks can be stored in a distributed manner, with all participants or nodes storing all of the blocks. Additionally, 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 distributed ledger 108 may maintain a chain of blocks that uses accounts as state objects, and the state of each account may be tracked through this chain. An account may represent the identity of a user, mining node, or automated agent. Every data operation block or smart contract may be associated with an account on the chain of blocks. By way of example and not limitation, the distributed ledger 108 may be a blockchain ledger that uses accounts as state objects and that tracks the state of each account through a blockchain. The scope of this disclosure may not be limited to the implementation of the distributed ledger 108 as a particular type of ledger. This disclosure contemplates other implementations of the distributed ledger 108 without departing from the scope of this 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, an 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 distributed ledger 108. For example, the front-end interface can be a user interface (UI) for a web application, website, or mobile application. The data collection system 102 can receive a request to purchase the 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 allows users to plan trips involving services from 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 multiple homogeneous or heterogeneous mobility providers and their infrastructure, such as ticketing gates, applications, and / or point-of-sale (PoS) devices, operating on the MaaS network 112 to provide various mobility services. Each mobility provider enjoys secure data ownership and can collaborate on related transaction data through at least one node in the set of distributed ledger nodes, thereby enhancing connectivity among various mobility providers. Further details regarding the MaaS network 112 are shown, for example, in FIG. 2.

[0021] The user device 114 may include suitable logic, circuitry, and interfaces that may be configured to provide, based on user input, a request to purchase an NFT 128 that represents a dataset on the distributed ledger 108. Additionally, the user device 114 may provide a request to access the dataset to the data collection system 102. The user device 114 may be associated with a data user 132. Examples of the user device 114 may include, but are not limited to, a computing device, a hardware-based annealer device, a digital annealer device, a quantum-based or quantum-inspired annealer device, a smartphone, a cellular telephone, 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 may include suitable logic, circuitry, and interfaces that may be configured to receive a copy of the dataset from the storage device 124 upon authenticating an access request from a data user 132. The analysis system 116 may include software tools that process and analyze the received copy of the dataset. In some embodiments, the functionality of the analysis system 116 may be at least partially or entirely incorporated into a user device 114 associated with the data user 132. Examples of the analysis system 116 may include, but are not limited to, a computing 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] Server 118 may include suitable logic, circuitry, interfaces, and / or code that may be configured to control access to copies of datasets on analysis system 116 based on consumption patterns. Server 118 may be implemented as a cloud server and may perform operations via web applications, cloud applications, HTTP requests, repository operations, file transfers, etc. Other implementations of server 118 may 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, server 118 can be implemented as a number of distributed cloud-based resources using a number of techniques known to those skilled in the art. Those skilled in the art will appreciate that the scope of the present disclosure may not be limited to the implementation of server 118 and data collection system 102 as two separate entities. In some embodiments, the functionality of server 118 may be incorporated, in whole or at least in part, into data collection system 102 without departing from the scope of the present disclosure. In some embodiments, server 118 may host database 120. Alternatively, server 118 may be separate from database 120 and communicatively coupled to a device that stores database 120.

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

[0026] The communication network 122 may include a communication medium that enables the data collection system 102, the owner devices 104, the middleware system 106, the distributed ledger 108, the NFT marketplace 110, the MaaS network 112, the user devices 114, the analytics system 116, and the server 118 to communicate with one another. The communication network 122 may be either a wired or wireless connection. Examples of the communication network 122 may include, but are not limited to, the Internet, a cloud network, a cellular or wireless mobile network (such as long-term evolution and fifth-generation (5G) new wireless (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 in the system 100 may 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, at least one of 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, wireless access point (AP), device-to-device communication, cellular communication protocols, and Bluetooth (BT) communication protocols.

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

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

[0029] The ML model 126 may include electronic data that may be implemented, for example, as a software component of an application executable on the data collection system 102. The ML model 126 may rely on libraries, external scripts, or other logic / instructions for execution by a processing device. The ML model 126 may 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 a violation of a condition associated with the sale of an NFT 128 exists. Additionally or alternatively, the ML model 126 may be implemented using hardware, including a processor, a microprocessor (e.g., that performs or controls the execution 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 may be implemented using a combination of hardware and software.

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

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

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

[0033] When the purchase request is received, the data collection system 102 may 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 associated with the sale of the NFT 128. For example, the data collection system 102 may verify whether the details specified in the purchase request meet the conditions associated with the sale of the NFT 128. If the purchase request meets the conditions associated with the sale of the NFT 128, the ownership information of the NFT 128 may be updated to include the data user 132. Details regarding the conditions associated with the sale of the NFT 128 are shown, for example, in FIG. 3B.

[0034] The middleware system 106 can receive a request for access to a dataset from the analysis system 116. Purchasing an NFT 128 alone 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 validate the access request based on ownership information and whether the access request satisfies at least one of the access rules for the dataset and the conditions associated with the use of the dataset. For example, when an access request is received, the ownership information can be verified to determine whether the account from which the access request originates is the same as the account of the data user 132 used to purchase the NFT 128. Once the ownership information is validated, the information specified in the access request can be verified to determine whether the access request satisfies the access rules for the dataset and the conditions associated with the use of the dataset. If there is a violation of the access rules for the dataset or the conditions associated with the use of the dataset, the access request can be denied. Details regarding the validation of an 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 validation. For example, once the access request is validated, 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 encrypted and / or anonymized form. The middleware system 106 can share private key(s) with the wallet account of the data user 132 for individually decrypting the copy of the dataset. Details regarding providing a 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 a 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 terms associated with the sale of NFTs 128s, the access rules of the dataset, or terms associated with the use of the dataset. If a violation is detected, the data collection system 102 can prevent access to the copy of the dataset. More details regarding consumption patterns and access control to copies of the dataset are shown, for example, in FIG. 3B.

[0037] The disclosed system 100 can provide benefits to data owners 130, owners of the system 100, and data users 132. The system 100 can provide higher profit margins to data owners 130. Furthermore, the disclosed system 100 can help data owners 130 expand their associated publishing businesses and strengthen primary and secondary markets for their associated publishing businesses. The system 100 can also provide new opportunities for new entrants and market leaders who want to sell their own datasets. Data owners 130 can also sell their own datasets by auctioning NFTs 128 associated with the datasets. The disclosed system 100 can manage secondary markets, such as analytics as a service, to protect users' data from data spoofing and counterfeiting. Data users 132 can have the option to interact directly with data owners 130. Furthermore, data users 132 can be assured that the dataset is authentic through the involvement of the distributed ledger 108 and the MaaS network 112.

[0038] Data uses can be broadly categorized into primary and secondary uses. Primary use can be transaction settlement for revenue sharing between MaaS-related players, such as mobility providers and mobility service providers. Secondary use can include reuse of datasets for analysis by governments, related institutions, service providers such as location-based services (LBS) players, and marketing companies. Other uses can also exist, where data analytics players process the data and resell it as new NFTs using the framework. For example, data from such analysis can represent new datasets suitable for the creation of new NFTs for analytics players to resell using the same data provisioning framework. Usage patterns can indicate popular datasets that could be subject to further modification, such as the option to increase the price and thereby generate additional profits for owners.

[0039] Figure 2 is a block diagram illustrating the MaaS network of Figure 1 in accordance with an embodiment of the present disclosure. The description of Figure 2 will be provided with reference to elements of Figure 1. Figure 2 illustrates a MaaS network 112. The MaaS network 112 may participate in a publish-subscribe pattern. The MaaS network 112 may include a set of publisher nodes 202A, 202B, ... 202N, a message broker 204, and a set of subscriber nodes 206A, 206B, ... 206N. The MaaS network 112 may 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. Additionally, the MaaS network 112 may include a set of distributed ledger nodes 212, which may 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 issuer nodes (e.g., ticket readers or ride booking applications), subscriber nodes, and at least one message broker that communicates transaction messages from the issuer nodes to the subscriber nodes 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 can include ledger nodes that record transactions related to various mobility services, such as ticketing transactions for MaaS transportation services, media usage or consumption statistics, or payment settlements between various stakeholders, such as content owners, transportation providers, or operators of the MaaS network 112.

[0041] The set of issuer nodes 202A, 202B, ... 202N of all transportation service providers associated with the MaaS network 112 may exchange data according to a standard or common communication protocol. The MaaS network 112 may include homogeneous issuer nodes that may follow a MaaS standard communication specification. In some embodiments, the MaaS network 112 may also include heterogeneous issuer nodes that may follow a proprietary communication protocol. The MaaS network 112 may provide plug-in-based support for the set of issuer nodes 202A, 202B, ... 202N to support such heterogeneous issuer nodes until each transportation service provider provides its support according to the MaaS standard communication specification.

[0042] The MaaS network 112 may allow issuer nodes associated with different transportation providers to join the MaaS network 112. The MaaS network 112 may provide bulk cluster management of issuer nodes through a node management device. All issuer nodes may adhere to a set protocol that enables them to operate on the MaaS network 112. The set protocol may mandate a common security architecture (for issuer node authentication and authorization), network protocols (e.g., HTTP, MQTT, AMQP, etc.), a uniform data request or response format (e.g., JSON, CSV, XML format), and API / data schema. This may ensure that each issuer node adheres to a cluster-level configuration (e.g., a device profile including company name, company ID, gate ID, gate number, etc.) and device-level certificates (i.e., authentication credentials). The cluster-level configuration and set protocol pattern may facilitate transportation providers to deploy new issuer nodes or replace existing issuer nodes in a plug-and-play manner. This can facilitate the MaaS network 1112 functioning as a homogeneous transportation network with interoperability between resources (such as issuer node equipment) of various transportation providers.

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

[0044] Each of the set of subscriber nodes 206A, 206B... 206N may include suitable logic, circuitry, code, and / or interfaces that may be configured to receive transactional messages from one or more of the set of publisher nodes 202A, 202B... 202N via the message broker 204. Each transactional message may include a topic to which one or more of the set of subscriber nodes 206A, 206B, 206N may subscribe. Example implementations of a subscriber node may include, but are not limited to, a web server, an edge device, an edge node, a cloud server, a cluster node of a cloud-based server, a workstation, or any computing device with fog computing capabilities.

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

[0046] The message broker 204 may include suitable logic, circuitry, code, and / or interfaces that may be configured to route transactional messages from a publisher node (e.g., first publisher node 202A) to a subscriber node (e.g., first subscriber node 206A). The decision to allow the message broker 204 to route such transactional messages to a subscriber node may be made by a server (not shown in FIG. 1 ) associated with the MaaS network 112. Exemplary implementations of the message broker 204 may include, but are not limited to, an application server, a cloud server, a mainframe server, a database server, a web server, or other type of server.

[0047] The message broker 204 may be configured to communicate with each of the set of publisher nodes 202A, 202B...202N and the set of subscriber nodes 206A, 206B...206N via 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 may include suitable logic, circuitry, code, and / or interfaces that may be configured to store transaction data associated with a respective mobility provider. For example, a first MP node 208A may store transaction data associated with a first mobility provider. The transaction data may include a record of a user's trips. Each trip may correspond to MaaS transportation services that the first transportation provider may offer during at least one leg of the trip. Each of the plurality of MP nodes may be referred to as a node of a first distributed ledger 208 that may store transaction data for various mobility providers in the MaaS network 112.

[0049] The plurality of MaaS nodes 210A, 210B...210N may include suitable logic, circuitry, code, and / or interfaces that may be configured to store transaction data related to all mobility providers in the MaaS network 112. The storage of transaction data related to each of the transportation service providers may be used to settle payments between transportation service providers that provide transportation services to users. Each of the plurality of MaaS nodes 210A, 210B...210N may correspond to a node of the second distributed ledger 210 that may store 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 associated with a set of distributed ledger nodes 212. For example, each of the first MP node 208A and the first MaaS node 210A can be associated with a driver node 212A, a user node 212B, and a document node 212C.

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

[0052] In one embodiment, at least two ledger nodes in each of the first distributed ledger 208 and the second distributed ledger 210 can store transaction data related to MaaS transportation services. The MaaS transportation services can be associated with one or more of a plurality of transportation providers and / or users (e.g., passengers) who can access the MaaS transportation services through a unified MaaS interface or a set of issuer nodes 202A, 202B...202N. The transaction data related to the MaaS transportation services can be included in a set 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 transaction data is updated based on transaction requests from the set 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 capable of maintaining an immutable record of data operations or transactions. For example, a transaction can include a record of NFT consumption patterns or sales of NFTs via the NFT marketplace 110 (as described in FIG. 1). A series of data operations can be grouped as a block 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, where at least two participants or nodes in each of the first distributed ledger 208 and the second distributed ledger 210 can store a subset of multiple blocks associated with one or more transactions in which those participants or nodes can participate. Additionally, each of the first distributed ledger 208 and the second distributed ledger 210 may include an operating system (e.g., a Java Virtual Machine (JVM)) that may enable deployment of smart contracts among multiple parties, such as, for example, mobility provider node(s) 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., the Corda blockchain, the Ethereum® blockchain, or the Hyperledger blockchain). Each of the first distributed ledger 208 and the second distributed ledger 210 can store a set of immutable state objects that the first distributed ledger 208 and the second distributed ledger 210, respectively, can track. The state objects can include a set of distributed ledger-compliant 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 for transactions), and content including state characteristics with certain state values. A smart contract can include a set of terms under which multiple parties to the smart contract can agree to interact with each other. Smart contracts may execute on one or more nodes on each of the first distributed ledger 208 and the second distributed ledger 210 and manage transitions between state objects to generate transactions. Smart contracts may be written once and reused for many state objects, and may reference governing legal prose through a cryptographic hash.

[0055] Each of the first distributed ledger 208 and the second distributed ledger 210 may use secure cryptographic hashes to identify parties and data and may also 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 may store transactions between a set of parties in a manner that is visible only to the relevant set of parties. Parties involved in a transaction may store the current state object of that transaction in a vault (a database associated with each distributed ledger, such as the first distributed ledger 208 and the second distributed ledger 210). Another party entitled to view or process the transaction (e.g., verify the validity of the transaction) may retrieve the current state object of the transaction from the vault. Additionally, each state object of the first distributed ledger 208 and the second distributed ledger 210 may include smart contracts between the parties or nodes that may 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., a first state object) to generate an output state object (e.g., a second state object). As a result, the updated transaction can form a provenance chain (which can be associated with transaction data). Each of the first distributed ledger 208 and the second distributed ledger 210 can agree on the updated transaction based on determining the validity of the updated transaction and determining the uniqueness of the updated transaction. In one embodiment, participants at the nodes associated with the updated transaction can determine the validity of the updated transaction by independently executing smart contracts and validation logic associated with the transaction. Furthermore, consensus nodes associated with each of the first distributed ledger 208 and the second distributed ledger 210 can determine the uniqueness of the updated transaction based on checking that no other transactions have been agreed upon using the same input state object as the current transaction.

[0057] 3A and 3B collectively illustrate an exemplary sequence of operations for data provisioning using non-fungible tokens, according to an embodiment of the present disclosure. The description of FIGS. 3A and 3B is provided with reference to elements in FIGS. 1 and 2. FIGS. 3A and 3B illustrate an exemplary sequence diagram 300 illustrating exemplary operations 302-328. The exemplary operations 302-328 may be performed by any computer system, such as components of system 100 of FIG. 1. The exemplary sequence diagram 300 further illustrates 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 analytics 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 a 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 by the data owner 130 from the owner device 104. As an example, a data collection application interface can be rendered on the owner device 104. The data collection application interface 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 amount 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 taken by the data owner 130 through multiple mobility service providers. The mobility service providers can be transportation providers whose services the data owner 130 has used to travel from one location to another. The data owner 130 can use multiple mobility service providers in a single trip. For example, a data owner, such as the data owner 130, can use a ride hailing service (e.g., a taxi service) for a first leg of the trip, a train service for a second leg of the trip, and a flight service for a third leg of the trip. The series of past trips can include information related to each trip taken by the data owner 130 in the past. For example, the information related to the trip can include the travel date, the duration of the trip, the number of mobility providers involved in the trip, the payment method for the trip, etc. The mobility service data related to the series of past trips can include information related to each trip in 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 associated with the system (e.g., an entity that manages the operation of the system 100 or the data collection system 102). The master service agreement can include legal terms and conditions that the data owner 130 must 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. The master service agreement (MSA) can also indicate that the data owner 130 warrants that they are the sole owner of the data. Furthermore, the master service agreement (MSA) can indicate that the data owner 130 warrants that the information provided by the data owner 130 during the onboarding process is authentic.

[0061] Once 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 a raw version of the data set. Thus, 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 the dataset and the data type of each attribute of the dataset. As an example, a decision tree can be used to extract datasets that are considered to be most valuable for creating an NFT 128. 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 duration of the trip, and the locations visited during the trip can be collected from the ticket data and used to determine the value of the dataset. In some embodiments, the data collection system 102 can define a data catalog containing logical groupings for extracting the dataset. For example, the data collection system 102 can group data points in the mobility service data based on the type of mobility provider, the mode of transportation, and the geographic location, etc. As an example, the mobility service data can include a trip identifier for the trip, the set of locations the data owner 130 could visit during the trip, the set of mobility providers used by the data owner 130 during the trip, and the payment method used by the data owner 130 during the trip, etc. Payment instruments or other payment related information may be sensitive data that can be filtered out while the data collection system 102 extracts the data set from the mobility services data.

[0063] At 306, it may be determined whether an NFT should be created for the dataset. The data collection system 102 may determine whether an NFT 128 should be created for the dataset based on the conditions for creating the NFT 128. The creation of the NFT 128 may depend on factors such as the size of the dataset, the type of dataset, the type of attributes used in the dataset, and the value of the dataset (e.g., in terms of monetary value or market demand). For example, the type of dataset may be authentic or falsified. If the dataset is not authentic, the data collection system 102 may determine not to create an NFT 128 at 308. The sequence diagram 300 may be aborted at 308. On the other hand, if the dataset is authentic, the data collection system 102 may determine to create an NFT 128. Note that the data collection system 102 may create the NFT 128 using standard token specifications such as ERC-721 and ERC-1155. The dataset may be classified as an asset and may be represented via an NFT 128 on the distributed ledger 108. The distributed ledger 108 may also include ownership information associated with 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. Once 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 associated with 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 (e.g., ownership information and a preview) to help a purchaser (e.g., data user 132) understand the dataset listed on the NFT marketplace 110. This allows the purchaser (e.g., data user 132) to browse, search, filter, and purchase the dataset according to their requirements. Further details regarding the listing of created NFTs 128 are shown, for example, in FIG. 4B.

[0065] At 312, the dataset can be stored in a 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 some embodiments, the dataset can be classified and preprocessed based on this classification before being stored in the storage device 124. For example, the dataset can be classified into one of a set of classes (e.g., anonymized, secure, raw, etc.) based on whether the dataset contains personally identifiable information (PII), financial information, demographic details, etc. In some embodiments, the dataset can be anonymized before being stored in the storage device 124. For example, to obtain an anonymized version of the dataset, values ​​associated with PII in the dataset can be removed or replaced with numeric or alphanumeric identifiers. The anonymized version of the dataset can be stored in the storage device 124. In another embodiment, the dataset can be stored in encrypted and / or anonymized form in the storage device 124 after the creation of the NFT 128. Encrypting the dataset can ensure that the dataset is securely stored in the storage device 124. This prevents unauthorized persons or devices from accessing the data set.

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

[0067] In some embodiments, a data owner 130 associated with an owner device 104 may specify verifiable credentials during onboarding that include information such as eligibility criteria for purchasing an NFT asset. Such credentials associated with a data user 132 may be verified via the middleware system 106 to determine whether the data user 132 should be allowed to purchase a listed NFT 128.

[0068] If the purchase request meets the conditions associated with the sale of the NFT 128, the data collection system 102 may accept the purchase request. Digital assets, such as money, digital fiat currency, cryptocurrency, or coupons, may then 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 as payment for the purchase of the NFT 128.

[0069] In some embodiments, the terms associated with the sale of the NFT 128 may include one or more of the following: the number of downloads of the dataset permitted to the data user 132; a limit on the time period during which the data user 132 may download the dataset; a limit on access to the raw version of the dataset represented by the NFT 128; a limit on access to the dataset based on the location of the data user 132; a limit on reselling the dataset by the data user 132; a limit on access to aggregated data of the dataset; a limit on the number of copies of the dataset permitted; a limit on the purpose for which the NFT 128 is purchased; or a limit on access to anonymized versions of the dataset. The number of downloads of the dataset permitted to the data user 132 may prevent the data user 132 from endlessly downloading the dataset. For example, the number of downloads of the dataset permitted may be two. After the dataset has been downloaded twice, the data user 132 may not be allowed to download the dataset. The limit on the time period during which the dataset may be downloaded may provide a time window during which the dataset may be downloaded or accessed on the analysis system 116. For example, the time period for downloading the dataset may be two weeks from the date of purchase of the dataset. Two weeks after the purchase date of the dataset, the dataset may be unavailable to data users 132 for download. The restrictions on access to the raw version of the dataset represented may indicate whether the raw version of the dataset should be accessed by the data user 132. For example, the restrictions on access to the raw version of the dataset may mandate that the data user 132 should only be able to access an encrypted or anonymized form of the dataset. The restrictions on access to the dataset based on the location of the data user 132 may require that the location of the data user 132 be within a predetermined geographic region in order to access the dataset.A data user 132 may be prevented from accessing a dataset if the data user 132's location is not within a predetermined geographic region. Restrictions on the resale of a dataset may prevent the data user 132 from reselling the dataset to anyone who is not the valid owner of the dataset. Restrictions on access to aggregated data of a dataset may specify whether the data user 132 should be able to access the aggregated data. The aggregated data may be, for example, a summary of the dataset. Restrictions on the number of allowable copies of a dataset may specify the maximum number of copies of the dataset that the data user 132 is permitted to sell. Restrictions on the purpose of purchasing an NFT 128 may prevent the data user 132 from purchasing an NFT 128 for purposes other than a predetermined purpose. For example, restrictions on the purpose of purchasing an NFT 128 may require that the dataset be used only for descriptive analytics. Thus, a purchase request received from the data user 132's account may be rejected if the purpose of purchasing the NFT 128 is not for descriptive analytics. Restrictions on access to the de-identified version of the dataset may specify whether the data user 132 should be able to access the de-identified version.

[0070] 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 associated with the sale of the NFT 128. If the purchase request meets the conditions associated with the sale of the NFT 128, the ownership information of the NFT 128 can be updated to include the account of the data user 132. That is, the NFT 128 can be transferred to the account of the data user 132.

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

[0072] At 318, ownership verification can be performed. Upon receiving the access request, the middleware system 106 can verify ownership information associated with the access request. The middleware system 106 can verify whether the account used to request access or download the data set is the same account from which the purchase request originated. Specifically, ownership verification can be performed to verify whether the data user associated with the analysis system 116 is the same 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 associated with the use of the dataset. In some embodiments, the conditions associated with the use of the dataset can include conditions for providing access to the dataset based on whether the data user 132 accepted a service agreement upon 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 analytics system 116. The status of the data user 132 can be a whitelist status or a blacklist status. The service agreement can include a set of terms and conditions that the data user 132 must agree to in order to access the dataset (represented by the NFT 128). If the data user 132 does not agree to the terms and conditions of the service agreement, the data user 132 can be prevented from using the dataset. The service agreement can be a binding agreement between the data user 132 and the data owner 130. In some embodiments, the service agreement can also include terms and conditions associated with the sale of the NFT 128.

[0074] Restrictions on the use of a dataset can prevent a data user 132 from using the dataset if the data user 132 is associated with a blacklist status. In many cases, the data collection system 102 can blacklist a data user that is found to have previously violated the dataset's access rules or the conditions associated with the dataset's use. Such users can be given blacklist status to prevent them from using the dataset in the future.

[0075] The permission to stream a dataset to an analysis system 116 may indicate the conditions under which the dataset may be streamed to the analysis system 116. For example, the permission to stream a dataset to an analysis system 116 may indicate that the dataset may be streamed in "100" kilobyte sized data subsets that the analysis system 116 can process on the fly.

[0076] Once the data collection system 102 verifies that the access request meets the conditions associated with the use of the dataset, the MaaS network 112 may receive 320 a request to audit and track consumption of the dataset associated with the NFT 128. The MaaS network 112 may receive the request to audit and track the NFT 128 from the middleware system 106. The MaaS network 112 may validate, audit, and track consumption of the dataset associated with the NFT 128 over the period that the service agreement between the data user 132 and the data owner 130 is in effect.

[0077] At 322, the ML model 126 can receive a request to verify whether the access request satisfies the access rules for the dataset. The ML model 126 can verify whether the access request satisfies the access rules for the dataset from the MaaS network 112. In one embodiment, the access rules for 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 on the analytics system 116 or downloaded, a number of participants who can act on the dataset through the analytics system 116, or locations where the dataset can be downloaded or accessed via the analytics system 116. The list of valid analytics for the dataset can prevent undesirable actions from being taken on the dataset other than those in the list of valid analytics. As an example, the list of valid analytics can include an action to predict demand for a particular mobility provider that has previously provided services to the data owner 130, an action to determine a price the data owner 130 typically prefers to pay for services, an action to determine key locations the data owner 130 prefers to visit, etc.

[0078] The period of time during which a dataset may be accessed or downloaded on the analysis system 116 may be based on a time window of hours, days, weeks, or months, after which the analysis system 116 may not allow the dataset to be accessed or downloaded. For example, the period of time may be two weeks from the date of purchase of the NFT 128. After two weeks from the date of purchase of the NFT 128, the analysis system 116 may not allow the dataset to be accessed or downloaded.

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

[0080] The locations where the dataset can be downloaded or accessed via the analysis system 116 can correspond to a geographic 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 some embodiments, conditions associated with the sale of an NFT 128, access rules for a dataset, or conditions associated with the use of a dataset may be described in a first smart contract on the distributed ledger 108 or a second smart contract on a ledger node of the MaaS network 112. An access request may be validated by executing the first smart contract on the distributed ledger 108 or the second smart contract on a ledger node of the MaaS network 112. For example, if conditions associated with the sale of an NFT 128, access rules for a dataset, or conditions associated with the use of a dataset are described in a first smart contract on the distributed ledger 108, then the first smart contract on the distributed ledger 108 may be executed to determine whether a request to purchase an NFT 128 satisfies the conditions associated with the sale of the NFT 128. The first smart contract on the distributed ledger 108 may further execute to determine whether the access request satisfies the access rules of the dataset or conditions associated with the use of the dataset (as described in the first smart contract on the distributed ledger 108).

[0082] According to an embodiment, the ML model 126 can be configured to verify whether the access request satisfies the access rules of the dataset (as shown in FIG. 3B ). In some embodiments, a subset of the 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 the ownership information and further based on whether the access request satisfies at least one of the access rules of the dataset and conditions associated with the use of the dataset.

[0083] At 324, the data collection system 102 may receive a request to update information related to the NFT 128 on the NFT marketplace 110. If the access request is validated, the data collection system 102 may update information related to accessing the dataset on the first smart contract on the distributed ledger 108 to allow the analytics system 116 to access or download the dataset. The information related to the NFT 128 may be updated on the NFT marketplace 110, and the NFT marketplace 110 may notify the data user 132 that the analytics system 116 associated with the data user 132 can access or download the dataset.

[0084] At 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, a decryption operation can be performed on the received encrypted copy of the dataset. In one embodiment, the data collection system 102 can share a private key with the account of the data user 132 based on 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 private key and obtain the dataset in unencrypted form. In one embodiment, the private 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 and private key of the data user 132. The analysis system 116 can then perform analysis on the dataset in unencrypted form. For example, the analysis system 116 can analyze the dataset in unencrypted form to determine the means of transportation that the data owner 130 may have most frequently used and the locations frequently visited by the data owner 130.

[0086] The data collection system 102 can monitor the analyses performed on the dataset in unencrypted form to determine consumption patterns of the provided copies on the analysis system 116. For example, the consumption patterns can include analytical operations performed on the dataset in unencrypted form and the number of times analyses have been performed on the dataset in unencrypted form. Additionally, the consumption patterns 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, attempts to transfer the dataset outside of the analysis system 116, etc.

[0087] The data collection system 102 can control access to copies of the dataset on the analysis system 116 based on consumption patterns. In some embodiments, the data collection system 102 can determine violations of terms associated with the sale of NFTs 128, access rules for the dataset, or terms associated with use of the dataset based on consumption patterns. For example, if an analysis performed on the dataset in unencrypted form is determined to be an invalid (or insecure) analysis, the data collection system 102 can determine this action as a violation of the terms associated with use of the dataset.

[0088] In one embodiment, a violation can be determined using an ML model 126. The ML model 126 can be trained to determine a violation based on a consumption pattern. The ML model 126 can receive a consumption pattern as input and determine a violation based on an analysis of the consumption pattern. As an example, a data user 132 may attempt to resell a dataset to another party. The consumption pattern may include information related to attempts to resell the dataset. The ML model 126 can determine a violation of terms associated with the sale of an NFT 128 based on the attempts in the consumption pattern. The ML model 126 can also determine malicious behavior by the data user 132 or detect improper consumption of the dataset (e.g., exceeding inventory limits set forth in terms associated with the sale of an NFT 128). If a violation is detected, the data user 132 may lose access 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 definite or indefinite period of time.

[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 transmitted 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 pop up on the user device 114 associated with the data user 132. The notification can indicate that a violation of the terms of use has been determined on the analysis system 116. In one embodiment, the generated feedback can be transmitted 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 illustrate an exemplary scenario for data provisioning using non-fungible tokens, according to embodiments of the present disclosure. Figures 4A and 4B are described with reference to elements of Figures 1, 2, 3A, and 3B. Figures 4A and 4B illustrate an exemplary scenario 400. The exemplary scenario 400 can include mobility service data 402, a data set 404, an NFT 406, a user device 408, a user interface (UI) 410A, a first UI element 412A, a second UI element 412B, a third UI element 412C, a fourth UI element 412D, a user interface (UI) 410B, a fifth UI element 414A, and a sixth UI element 414B. A series of operations associated with the exemplary scenario will now be described.

[0091] During operation, the data collection system 102 may receive mobility service data 402 from an owner device (e.g., owner device 104). The mobility service data 402 may be a raw data set related to the travel history of a data owner (e.g., data owner 130). The mobility service data 402 may include information related to “N” trips taken by the data owner 130. For each trip, a trip identifier (ID) associated with the trip, the names of locations visited by the data owner 130 during the trip, expenses incurred during the trip, mobility providers used for transportation during the trip, and payment instruments used during the trip may be specified. For example, the mobility service data 402 may observe that for trip ID “1,” the data owner 130 traveled from Columbus to Cleveland using one or more ride-hailing services. Furthermore, the expenses incurred for trip ID “1” may be $10, and the data owner 130 may have used Wallet “A” for payment.

[0092] The data collection system 102 can extract a data set 404 from the mobility services data 402. The mobility services data 402 can be filtered to exclude certain sensitive information contained in the mobility services data 402. For example, the mobility services data 402 can be filtered by removing a payment instrument column from the mobility services data 402.

[0093] The data collection system 102 can mint an NFT 406 on a distributed ledger, such as the distributed ledger 108. When an 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 link to a dataset that presents an off-chain source of truth, etc. A smart contract, such as a first smart contract on the distributed ledger 108, can describe terms associated with the sale of the NFT 406, access rules for the dataset, or terms associated with the use of the dataset. The NFT 406 can include information related to the address of the smart contract and a smart contract identification (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 NFT 406 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 a user device 408. FIG. 4B shows the NFT 406 as a listing on a 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, an NFT ID, the owner's wallet ID, and the address of the NFT 406 on the distributed ledger 108. The first UI element 412A may indicate that the NFT ID of the NFT 406 is "48213", the owner wallet ID associated with the data owner 130 is "0zA3967b", and the address of the NFT 406 on the distributed ledger 108 is "0xc0ffec25b678269A83B".

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

[0096] Upon receiving a request to purchase the NFT 406, the NFT marketplace 110 may switch to a second user interface 410B. The second user interface 410B may be displayed on the user device 408. The second user interface 410B may provide a fifth UI element 414A and a sixth UI element 414B. The fifth UI element 414A may provide terms and conditions associated with the NFT 406. Referring to FIG. 4B , the terms and conditions provided in the fifth UI element 414A may require that the dataset 404 be used only for descriptive analysis, that the data user 132 may not share or sell the dataset 404 with third parties, and that the dataset 404 may not be manipulated or tampered with in any way. The data user 132 may read the terms and conditions associated with the NFT 406 and decide to purchase the NFT 406. Based on the selection of the sixth UI element 414B, the NFT marketplace 110 may receive acceptance of the terms and conditions provided in the fifth UI element 414A. A payment of $100 may then 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] Figure 5 is a block diagram illustrating the example data collection system of Figure 1, in accordance with an embodiment of the present disclosure. Figure 5 is described with reference to elements of Figures 1, 2, 3A, 3B, 4A, and 4B. Figure 5 illustrates a block diagram 500 of system 100 of Figure 1. System 100 may include circuitry 502, memory 504, input / output (I / O) devices 506, and a network interface 508. Input / output (I / O) devices 506 may include a display device 510.

[0098] The circuitry 502 may include suitable logic, circuits, and / or interfaces that may be configured to execute program instructions associated with different operations performed by the data collection system 102. The circuitry 502 may include one or more processing units that may be implemented as independent processors. In some embodiments, one or more processing units may be implemented as an integrated processor or a group of processors that collectively perform the functions of one or more processing units. The circuitry 502 may be implemented based on multiple processor technologies known in the art. Example implementations of the circuitry 502 may 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 circuitry.

[0099] The memory 504 may include suitable logic, circuitry, interfaces, and / or code that may be configured to store one or more instructions executed by the circuitry 502. The memory 504 may be configured to store a data set. Example implementations of the memory 504 may 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) cards.

[0100] The I / O device(s) 506 may include suitable logic, circuitry, interfaces, and / or code that may be configured to receive input and provide output based on the received input. For example, the I / O device(s) 506 may receive a first user input indicating an onboarding request. The I / O device(s) 506 may include a display device 510. Examples of the I / O device(s) 506 may 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 may include suitable logic, circuitry, interfaces, and / or code that may be configured to facilitate communications between the data collection system 102 and the server 118 over the communications network 122. The network interface 508 may be implemented using various known technologies to support wired or wireless communications between the data collection system 102 and the communications network. The network interface 508 may 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 may 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 may be configured to use one or more of a number 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), Fifth Generation (5G) New Radio (NR), Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Bluetooth, Wireless Fidelity (WiFi) (such as IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, or IEEE 802.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 may include suitable logic, circuitry, and interfaces that may be configured to display information related to the dataset and terms and conditions associated with the sale of the NFT 128. The display device 510 may be a touch screen that allows a user (e.g., data owner 130) to provide user input via the display device 510. The touch screen may be at least one of a resistive touch screen, a capacitive touch screen, or a thermal touch screen. The display device 510 may be implemented through a number of known technologies, such as, but not limited to, at least one of a liquid crystal display (LCD) display, a light emitting diode (LED) display, a plasma display, or an organic LED (OLED) display technology, or other display device. According to an embodiment, the display device 510 may 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] FIG. 6 is a flowchart illustrating operations of an exemplary method for data provisioning using non-fungible tokens, according to an embodiment of the present disclosure. FIG. 6 is described with reference to elements in FIGS. 1, 2, 3A, 3B, 4A, 4B, and 5. FIG. 6 illustrates a flowchart 600. The flowchart 600 includes operations 602-618 and may be performed 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 analytics system 116 of FIG. 1, or the circuit 502 of FIG. 2. The flowchart 600 may begin at 602 and proceed to 604.

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

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

[0107] At 608, ownership information of the NFT 128 can be updated on the distributed ledger 108 to include the data user 132 based on whether the purchase request meets the conditions associated with the sale of the NFT 128. The data collection system 102 can update 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 associated with the sale of the NFT 128. More details regarding ownership information are shown, for example, in FIG. 3B.

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

[0109] At 612, the access request can be validated based on the ownership information and whether the access request satisfies the access rules of the dataset and / or the conditions associated with the use of the dataset. The data collection system 102 can validate the access request based on the ownership information and whether the access request satisfies the access rules of the dataset and / or the conditions associated with the use of the dataset. Details regarding the validation 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. Based on the validation, 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. Details regarding providing a copy of the dataset are shown, for example, in FIG. 3B.

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

[0112] At 618, access to copies of the dataset on the analysis system 116 can be controlled based on the consumption patterns. The data collection system 102 can control access to copies of the dataset on the analysis system 116 based on the consumption patterns. More details regarding controlling access to copies of the dataset are shown, for example, in FIG. 3B. Control can proceed to an end.

[0113] Although flowchart 600 is depicted as discrete operations such as 604, 606, 608, 610, 612, 614, 616, and 618, the disclosure is not so limited. Thus, in some embodiments, such discrete operations may be further divided into additional operations, combined into fewer operations, or eliminated, depending on the implementation, without departing from the essence of the disclosed embodiments.

[0114] Various embodiments of the present disclosure may provide a non-transitory computer-readable medium and / or storage medium having stored thereon computer-executable instructions executable by a machine and / or computer to operate a system (e.g., data collection system 102 of FIG. 1 ). Such instructions may cause data collection system 102 to perform operations that may include storing a dataset associated with a data owner (e.g., data owner 130 of FIG. 1 ) in a storage device (e.g., storage device 124 of FIG. 1 ). The operations may further include receiving a purchase request from an account of a data user (e.g., data user 132 of FIG. 1 ) for a non-fungible token (NFT) (e.g., NFT 128 of FIG. 1 ) representing the dataset on a distributed ledger (e.g., distributed ledger 108 of FIG. 1 ). The operations may further include updating ownership information of NFT 128 on distributed ledger 108 to include data user 132 based on whether the purchase request satisfies conditions associated with the sale of NFT 128. The operations may further include receiving a request to access the dataset. The operations may further include 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 conditions associated with use of the dataset. The operations may further include providing a copy of the dataset from the storage device 124 to an analysis system associated with the data user 132 (e.g., analysis system 116 of FIG. 1 ) based on the validation. The operations may further include determining on analysis system 116 a consumption pattern of the provided copy. The operations may further include controlling access to the copy of the dataset on analysis system 116 based on the consumption pattern.

[0115] An exemplary aspect of the present disclosure may provide a system (e.g., data collection system 102 of FIG. 1 ). The system may store a dataset associated with a data owner (e.g., data owner 130 of FIG. 1 ) in a storage device (e.g., storage device 124 of FIG. 1 ). The system may receive a purchase request from an account of a data user (e.g., data user 132 of FIG. 1 ) for a non-fungible token (NFT) (e.g., NFT 128 of FIG. 1 ) representing the dataset on a distributed ledger (e.g., distributed ledger 108 of FIG. 1 ). Based on whether the purchase request satisfies conditions associated with the sale of the NFT 128, the system may update ownership information of the NFT 128 on the distributed ledger 108 to include the data user 132. The system may receive a request to access the dataset. The system may validate 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 conditions associated with use of the dataset. Based on the validation, the system can provide a copy of the dataset from storage device 124 to an analysis system (e.g., analysis system 116 of FIG. 1 ) associated with data user 132. The system can determine a consumption pattern of the provided copy on analysis system 116. The system can control access to the copy of the dataset on analysis system 116 based on the consumption pattern.

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

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

[0118] In some embodiments, after the NFT 128 is created, the dataset 404 may be stored in the storage device 124 in an encrypted and / or anonymized form.

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

[0120] In some embodiments, a first smart contract on the distributed ledger 108 or a second smart contract on a ledger node of the MaaS network 112 may describe terms related to the sale of NFTs 128, access rules for the dataset 404, or terms related to the use of the dataset 404.

[0121] In some embodiments, the access request may be validated by executing a first smart contract on the distributed ledger 108 or a second smart contract on a ledger node of the MaaS network 112.

[0122] In some embodiments, the access rules for the dataset 404 may include one or more of: a list of valid analyses for the dataset 404; a period during which the dataset 404 can be accessed on the analysis system 116 or downloaded; a number of participants who can act on the dataset 404 through the analysis system 116; or a location from which the dataset 404 can be downloaded or accessed via the analysis system 116.

[0123] In embodiments, the conditions associated with the sale of the NFT 128 may include one or more of the following: the number of times the data user 132 is permitted to download the dataset 404; a limit on the period of time the data user 132 has the dataset 404 downloaded; a limit on access to the raw version of the dataset 404 represented by the NFT 128; a limit on access to the dataset 404 based on the location of the data user 132; a limit on the resale of the dataset 404 by the data user 132; a limit on access to aggregate data of the dataset 404 represented by the NFT 128; a limit on the number of copies of the dataset 404 that are permitted; a limit on the purpose for which the data user 132 purchases the NFT 128; or a limit on the data user 132's access to an anonymized version of the dataset 404.

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

[0125] In one embodiment, the data collection system 102 can share a private key with the data user's 132 account based on 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 unencrypted form.

[0126] In some embodiments, consumption patterns can be used to determine violations of terms associated with the sale of NFTs 128, access rules for dataset 404, or terms associated with the use of 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, violations can be determined through the use of ML models 126 .

[0129] The present disclosure may also be situated in a computer program product that includes all features that enable the implementation of the methods described herein and that is capable of executing these methods when loaded into a computer system. A computer program in this context means any expression, in any language, code or notation, of a set of instructions that is intended to cause a system having information processing capabilities to perform a particular function, either directly, or after a) conversion into another language, code or notation, or b) reproduction in a different content form, or both.

[0130] While the present disclosure has been described with reference to several embodiments, those skilled in the art will recognize that various modifications may be made and equivalents may be substituted without departing from the scope of the disclosure. Additionally, many modifications may be made to adapt a particular situation or material to the teachings of the disclosure without departing from the scope of the disclosure. Therefore, it is not intended that the disclosure be limited to the particular embodiments disclosed, but rather, it is intended to include all embodiments falling within the scope of the appended claims. [Explanation of symbols]

[0131] 100 systems 102 Data Collection System 104 Owner device 106 Middleware Systems 108 Distributed Ledger 110 NFT Marketplace 112 Mobility as a Service (MaaS) Network 114 User Device 116 Analysis System 118 servers 120 databases 122 Communication Network 124 Storage device 126 Machine Learning (ML) Models 128 Non-fungible Tokens 130 Data Owner 132 Data Users

Claims

1. 1. A system including a storage device that stores a dataset associated with a data owner, The computer receiving a purchase request from a data user account for a non-fungible token (NFT) representing a dataset on a distributed ledger; updating 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 a request to access the data set; 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 conditions associated with the use of the dataset; providing a copy of the dataset from the storage device to an analysis system associated with the data user based on the validation; determining a consumption pattern of the provided copies on the analysis system; controlling access to a copy of the dataset on the analysis system based on the consumption pattern; 3. A method comprising:

2. The computer receiving mobility service data relating to a series of past trips taken by the data owner across multiple mobility service providers; executing a master services agreement between said data owner and a data operator associated with said system; extracting the data set from the mobility services data based on the execution; and wherein the dataset is stored in the storage device after the extraction. The method of claim 1.

3. The computer creating the NFT on the distributed ledger based on whether the dataset satisfies the conditions for creating the NFT; Listing the created NFT on an NFT marketplace associated with the distributed ledger; and the listing of NFTs includes ownership information associated with the data owner and a preview of the data set represented by the NFT; The method of claim 1.

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

5. the system further includes a Mobility as a Service (MaaS) network including a message broker, a set of publisher nodes, a set of distributed ledger nodes, and a set of subscriber nodes in communication with the set of publisher nodes via the message broker; the set of issuer nodes are communicatively coupled to the distributed ledger; The method of claim 1.

6. The terms related to the sale of the NFTs, the access rules for the dataset, or the terms related to the use of the dataset are described in a first smart contract on the distributed ledger or a second smart contract on a ledger node of the MaaS network; The method of claim 5.

7. the access request is validated by executing the first smart contract on the distributed ledger or the second smart contract on the ledger node of the MaaS network; The method of claim 6.

8. the access rules for the dataset include one or more of: a list of valid analyses for the dataset; a period during which the dataset can be accessed on the analytical system or downloaded; a number of participants who can act on the dataset through the analytical system; or a location from which the dataset can be downloaded or accessed via the analytical system. The method of claim 1.

9. the terms and conditions associated with the sale of the NFT include one or more of: the number of downloads of the dataset the data user is permitted to make; a limit on the time period for which the data user has the dataset downloaded; a limit on access to a raw version of the dataset represented by the NFT; a limit on access to the dataset based on the location of the data user; a limit on the resale of the dataset by the data user; a limit on access to aggregate data of the dataset represented by the NFT; a limit on the number of copies of the dataset that are permitted; a limit on the purpose for which the data user may purchase the NFT; or a limit on access to an anonymized version of the dataset by the data user; The method of claim 1.

10. The conditions associated with the use of the dataset include conditions for providing access to the dataset based on whether the data user accepted a service agreement at the time of purchasing the NFT, restrictions on the use of the dataset based on the status of the data user, and permission to stream the dataset to the analysis system, wherein the status of the data user is a whitelist status or a blacklist status. The method of claim 1.

11. The computer Sharing a private key with the data user's account based on validation of the access request, wherein the copy of the data set is an encrypted copy; decrypting the encrypted copy of the data set based on the private key to obtain an unencrypted form of the data set; The method of claim 1 , further comprising:

12. The computer determining violations of terms associated with the sale of the NFT, access rules of the dataset, or terms associated with the use of the dataset based on the consumption patterns; The method of claim 1.

13. The computer generating feedback based on the determination of the violation; and controlling a user device associated with said data user to render said feedback; The method of claim 12 , further comprising:

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

15. a storage device configured to store a dataset associated with the data owner; The circuit and The circuitry comprises: Receive a purchase request from a data user account for a non-fungible token (NFT) representing a dataset on a distributed ledger; updating ownership information of the NFT on the distributed ledger to include the data user based on whether the purchase request satisfies conditions associated with the sale of the NFT; receiving a request to access the data set; 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 conditions associated with the use of the dataset; providing a copy of the dataset from the storage device to an analysis system associated with the data user based on the validation; determining a consumption pattern of the provided copies on the analysis system; controlling access to a copy of the dataset on the analytical system based on the consumption patterns; It is configured as follows: A system characterized by:

16. The circuit comprises: receiving mobility service data relating to a series of past trips taken by the data owner across multiple mobility service providers; executing a master services agreement between said data owner and a data operator associated with said system; extracting the data set from the mobility services data based on the execution; wherein the dataset is stored in the storage device after the extraction.

16. The system of claim 15.

17. The circuit comprises: creating the NFT on the distributed ledger based on whether the dataset satisfies the conditions for creating the NFT; Listing the created NFT on an NFT marketplace associated with the distributed ledger; further configured as follows: the listing of NFTs includes ownership information associated with the data owner and a preview of the data set represented by the NFT; 16. The system of claim 15.

18. The dataset is stored in the storage device in encrypted or anonymized form after creation of the NFT; 20. The system of claim 17.

19. a Mobility as a Service (MaaS) network including a message broker, a set of publisher nodes, a set of distributed ledger nodes, and a set of subscriber nodes communicating with the set of publisher nodes via the message broker; the set of issuer nodes are communicatively coupled to the distributed ledger; 16. The system of claim 15.

Images