Blockchain-based business inventory systems and methods

Abstract

This document discloses systems, methods, and software for generating customized views of blockchain transactions. A blockchain is maintained in a distributed node network, containing block entries requested by multiple users from user devices. Each block entry includes multiple data portions, each associated with an access level. A request to view one or more data portions of a block entry is received, the request including an access code associated with at least one access level. The access code in the request is evaluated using the blockchain of the block entry to identify the one or more data portions associated with the access level. A customized view of the block entry, including the one or more data portions associated with the access level, is generated. This provides enhanced operational efficiency and customer convenience in industries including parking, hospitality, and autonomous vehicle fleets.

Description

[0001] This application is a divisional application of the invention patent application filed on March 6, 2020, with application number 202080002570.8 and titled "Blockchain-based Commercial Inventory System and Method".

[0002] Cross-references to related applications

[0003] This application is a partial continuation of U.S. Patent Application No. 16 / 806,646, filed March 2, 2020, entitled "Customized View of Restricted Information Recorded Into A Blockchain"; that U.S. Patent Application No. 16 / 579,697, filed September 23, 2019, entitled "Customized View of Restricted Information Recorded Into A Blockchain"; that U.S. Patent Application No. 16 / 294,745, filed March 6, 2019, entitled "Customized View of Restricted Information Recorded Into A Blockchain"; and that U.S. Patent Application No. 62 / 639,393, filed March 6, 2018, entitled "Customized View of Restricted Transactions Recorded into a Blockchain" and that filed July 23, 2018, entitled "Customized View of Restricted Information Recorded into a Blockchain". Priority to U.S. Provisional Patent Application No. 62 / 701,947, “Blockchain”, the entire contents of each of the aforementioned U.S. Provisional Patent Applications are incorporated herein by reference for all purposes. Technical Field

[0004] The various implementations of this technology generally relate to inventory transaction systems. More specifically, some implementations relate to blockchain-based parking systems and other inventory tracking systems. Background Technology

[0005] Blockchain allows user networks to create a digital ledger of data and share that data among other users within the network. Unlike previous database structures, a blockchain database is maintained by numerous independent nodes scattered across a large, distributed network. When a transaction is recorded in the blockchain database, altering or removing that data is extremely difficult, if not impossible, because the data is stored on more than one node in the distributed network. Therefore, data is added to the blockchain database by multiple users, and changing recorded data requires the consent of each (or most) of those users. This distributed control over adding, correcting, and removing data from the blockchain database establishes trust among users in the network, especially when users are unfamiliar with each other. Summary of the Invention

[0006] Various embodiments of this technology generally relate to inventory transaction systems. More specifically, some embodiments relate to blockchain-based parking systems and other inventory tracking systems. These systems provide enhanced systems, methods, and software applications disclosed herein for generating customized views of blockchain transactions. In some embodiments, a blockchain of block entries requested by multiple users from user devices is maintained in a distributed node network. Each block entry includes multiple data portions, each associated with an access level. A request to view one or more data portions of a block entry is received, the request including an access code associated with at least one access level. The access code in the request is evaluated using the blockchain of the block entry to identify one or more data portions associated with the access level. A customized view of the block entry including the one or more data portions associated with the access level is generated.

[0007] Some implementations provide a system for tracking, managing, and implementing parking space transactions in a parking facility. The system can maintain a blockchain (or distributed ledger) of block entries requested by multiple users from user devices in a distributed node network. Examples of users may include customers of the parking facility and / or the operator of the parking facility. The block entries may include entries from the customer relating to at least one parking space offered by the operator of the parking facility, and entries from the operator of the parking facility regarding the availability status of the at least one parking space. Each block entry may each include multiple data portions, each associated with an access level. The system can receive requests to view one or more data portions of a block entry. In some implementations, the request may include an access code associated with at least one access level. The system can then evaluate the access code in the request using the blockchain of the block entry to identify one or more data portions associated with the access level. A customized view of the block entry, including the one or more data portions associated with the access level, can be generated.

[0008] In some implementations, a customized view of blockchain data for parking facility transactions can be generated. The method may include receiving a request to view one or more data portions of a block entry maintained in the blockchain, wherein the one or more data portions of the block entry include restricted information. Each of the one or more data portions of the block entry may be associated with an access level assigned to: a customer of the parking facility, and a user associated with the operator of the parking facility. The method may include evaluating an access code in the request against the blockchain of the block entry to identify the one or more data portions associated with the access level. The method may include generating a customized view of the block entry including any one of the one or more data portions associated with the access level, while applying edits to any of the restricted information not authorized by the access code.

[0009] As an example, in the parking industry, customer and vehicle identification information such as Vehicle Identification Number (VIN), license plate number, access card number, subscription plan details, usage history and preferences, address, known e-wallets, mobile phones, electronic keys, digital fingerprints, used credit / debit cards, and used cryptocurrency wallets can be maintained on the blockchain along with other customer information. Customers will not want any of this information to be publicly accessible, and public access could result in legal liability for parking facility operators and owners. Various implementations use different encryption and hashing technologies to securely store the data on the blockchain, allowing only authorized users to view it. As an example, a driver can enter a parking garage and be identified in public forums using their vehicle's year, brand, and model; however, other private information will not be available for viewing by anyone other than a user with proper access rights, including the user, legitimate parking garage staff, inspectors, supervisors, etc.

[0010] In some implementations, the parking facilities to which this technology is applicable may include commercial parking structures, such as parking lots and garages with numerous parking spaces within a defined spatial area, and parking spaces that may be distributed across a designated area, such as a sector, community, block, or part of a parking lot, garage, or other parking structure in a city or town. In one example, customers of the parking facility may be charged once they enter the facility and their vehicles, and this charging may be based on a blockchain. For example, some people may be pre-charged for the entire day when they enter the garage or parking lot. Some people may be charged a fraction of the full day's fee based on the time spent in the parking lot or garage. Some people may be able to access the facility 24 / 7 / 365 without restriction or pay whenever the facility is open. Some people may not be able to park with a monthly pass when it is not applicable or when additional charges will apply. Implementations of this technology enable blockchain-based parking transaction management and customized views to handle these and other pay-as-you-go or subscription-based parking usage instances, improving convenience and efficiency in parking business operations.

[0011] In the parking example, supply chain efficiency can be improved through real-time tokenization, from customer interactions to a dynamic blockchain. The perception of the purity of consumer products—such as where the seeds come from, the grain fed to the animals, weather and climate, and traceability from the consumer's perspective—is the same for parking. Cost efficiency along the supply chain to the consumer varies in magnitude with know-how and actionable intelligence, all of which can be collected and analyzed more quickly and with greater granularity using publicly available systems and methods. Real-time tokenization of data shared via user interfaces on customer and parking facility operator endpoints not only provides data collection and customized viewing but also facilitates timely updates to information most relevant to the parking business and its customers.

[0012] In parking revenue management, capabilities can be enhanced by knowing parking reservation load, credit card processing, and channel-bundled sales (e.g., parking spaces at a stadium sold out, displaying the percentage of unreserved parking spaces compared to the percentage of people attending an event without reservation). Parking payment processing can be performed using various embodiments of this disclosure by reserving parking spaces with or without payment, or by charging users in real time only when the corresponding parking space is occupied by their vehicle.

[0013] People always make last-minute decisions, and the technology needed to hand over parking spaces to them will allow for faster charging of customers and parking gates to be opened based on the car's geolocation (this can be done in many different ways, such as VIN#, license plate, mobile phone information for credit card payments, placing the car in / using it in the parking space and processing credit card transactions or payment methods, much like toll road transponders). The device can be a transponder or a transmitter. An application can verify when someone arrives at the parking facility in their vehicle, and if GPS or other geolocation technology is on the car / phone / user, the customer can be charged when they arrive at an area that looks like an arrow geolocation. There are built-in rewards in the application, as well as violations that can be paid for through the application, and a mapping calculator for parking space prices. For example, a parking lot charges $8 for early arrivals between 2 pm and 5 pm, $15 for those arriving at 6 pm, and $25 for those arriving an hour later, since the event starts at 7 pm. All this information can be recorded in the blockchain. Additionally, different parking lots or certain parking spaces within a parking facility may have different prices. The parking space closest to the pedestrian exit can cost up to $50 at 7 PM, while the furthest space might cost $5. All this information can be displayed on a map and used to guide users of the app looking for parking. This information allows users to see what is happening in a particular area in the future, in real time, or in the past.

[0014] Logistics offers another direct application of this technology. For example, tracking packages or goods, and the movement of goods from one place to another, is crucial. All information can be included in the movement of goods from their origin to their destination. At each location, goods can be scanned, thus revealing their precise location at a specific time. This can be entered into a blockchain record. Additionally, goods can be associated with specific ships, trucks, vans, or other delivery agencies (e.g., delivery drones), and the GPS location of the delivery agency can be tracked in real time, on request, or at specific time intervals. Additional information such as buyer, seller, owner, insurance information, and demurrage fees associated with the GPS recorded on the blockchain can be reported. Companies and / or governments, for various reasons, do not want everyone to know about their operations but require auditing and the ability to demonstrate to inspectors, controllers, or regulators what they are doing or have done at a certain time / place. The ability to keep things private is mandatory. Thus, various implementations can use a combination of private, public, and hybrid blockchains to store information. Furthermore, various encryption schemes and access levels can be associated with individual portions of the data to ensure privacy where needed or desired, and to grant access when necessary.

[0015] In some implementations, this technology can provide specific applications for the defense industry. For example, the U.S. government needs the ability to review and control procurement, logistics, supplies, troop movements, and so on. If this information falls into the wrong hands, it could have fatal consequences. Maintaining certain aspects of information while obscuring certain aspects is essential for mission success. The ability to categorize data and allow access is imperative to ensure that only those with the necessary authority have access to the data (e.g., to view, monitor, influence, or review it), and that anyone without access cannot view portions of the data. In some implementations, the system can automatically review documents related to the inquiry and automatically apply one or more redaction filters based on the user's clearance status.

[0016] Another direct application of this technology is in the operation of parking facilities. For example, owners or operators of parking garages or parking lots can provide parking spaces to drivers on demand (e.g., hourly or daily) or as part of a subscription plan (e.g., monthly parking). Beyond this basic provision of paid parking spaces, parking facility owners / operators can offer drivers a variety of ancillary services to enhance convenience, safety, and comfort during their use of the facility. Providing such ancillary services can differentiate a particular parking facility from other nearby facilities, giving the owner or operator a competitive advantage in the market and attracting and retaining loyal parking customers. In doing so, parking facilities can experience increased revenue, reduced liability risks, and more efficient business operations. Using blockchain and associated user interfaces to acquire, transmit, record, and track data related to parking transactions facilitates the aforementioned benefits for parking customers and facility owners and operators, as explained in more detail below with examples.

[0017] In some implementations, the inventory units in a physical structure that can be managed using this technology may include travel-related contexts beyond parking facilities. For example, transactions such as reservations, payments, and checks for hotel rooms in one or more buildings, or even hotel rooms distributed across numerous locations within a chain hotel brand, can be managed via the disclosed custom view in the same manner and with similar units of defined inventory as for parking spaces. In one example, a hotel customer may be charged once they arrive at the hotel or once they first enter their room after a successful reservation. The custom view and blockchain transaction records ensure the privacy and security of customers enjoying their hotel stay and assuring the operator of the combination of reservations and payments. Hotel charges and reservations, as well as the provision of related services and business operations, are all based on blockchain and can utilize the custom view according to this disclosure. Convenience and business efficiency are achieved in use cases such as the automatic crediting or debiting of traveler reward points, according to this technology. The benefits of such automation provided by the disclosed blockchain-based technology and custom view are evident in the hotel context and may also be favored by airlines and other ground transportation services.

[0018] Autonomous vehicle fleet management is another direct application of this technology. For example, the owner or operator of one or more autonomous vehicles may experience peak usage during specific time periods on weekdays (e.g., peak commuting hours) and less usage during off-peak hours and weekends. Certain passengers of autonomous vehicles may use them in specific ways, such as calling an autonomous vehicle from a specific location and at a specific time. Tracking passenger usage patterns of autonomous vehicles can enable fleet owners or operators to realize economic benefits and enhance the user experience. All information can be included in where the vehicle is transported from and to what destination, the location of the autonomous vehicle when called, and the routes taken by the autonomous vehicle to and from the destination. This and other useful data can be entered into a blockchain record. Furthermore, the location of an autonomous vehicle can be associated with a specific passenger, and its GPS location can be tracked in real time, on request, or at specific time intervals. The data recorded in the blockchain can be used to facilitate automated billing and auditing.

[0019] Additional information, such as battery energy usage, charging history, vehicle maintenance records, and liability insurance information, can be reported, tracked, and recorded on the blockchain along with vehicle and passenger identifiers. For at least some fleet operators and passengers, maintaining the privacy of these records is important for business and / or personal reasons. However, in some cases, such as court orders or enforcement orders, such information recorded on the blockchain may need to be disclosed to inspectors, controllers, police, or regulators. Thus, various implementations can use a combination of private, public, and hybrid blockchains to store information. Furthermore, various encryption schemes and access levels can be associated with individual portions of the data to ensure privacy where needed or desired, and to grant access when necessary.

[0020] As another example, in the ground transportation industry, this technology can be adopted to track the location of autonomous or human-driven buses, shuttles, and taxis, enabling operators and current or potential passengers to view this data in real time. For instance, a customer might call a shuttle waiting at the airport from a parking facility outside the airport and expect to be picked up. Using a customized view provided by this technology, the customer can see where the shuttle is currently located, determine the accurate estimated arrival time, and see if they have missed the shuttle at their expected stop. This can be particularly beneficial for customers who wish to minimize wasted time waiting for shuttles or other ground transportation. Similarly, hotel shuttle and event shuttle operators, as well as their customers, can benefit in a similar way to increase operational efficiency and convenience.

[0021] Recording tracking data of autonomous or human-driven vehicles used for ground transportation of passengers in a wide variety of contexts in the blockchain further enables real-time updates and tracking of the status of buses, shuttles, and / or cars within a single fleet or two or more vehicle fleets. This data can be paired with passenger pick-up locations recorded in and tracked using the blockchain, where both operators and passengers can conveniently assess operational status using the exposed, customized view, and perform other useful functions based on changing needs or other factors such as traffic conditions and weather, such as changing pick-up locations, providing status updates, and rerouting fleet vehicles.

[0022] Other technical benefits arising from the application and use of this technology in ground transportation include providing passengers with a means of paying for their rides and potentially tipping their drivers using private and secure blockchain-based transactions. The disclosed customized view can be advantageously used by passengers not only to schedule ground transportation and see where and when their rides will arrive, but also to prepay fares, book rides for later dates and times, and, in some implementations, change their pick-up and destination points to better meet their needs. This technology can seamlessly adjust the direction, navigation, and itinerary of human-driven or autonomous vehicles based on passenger needs and the availability of fleet assets capable of serving passengers. As passengers update, and as any changes are made to asset and / or driver availability to meet customer needs, ride fares can be adjusted in real time according to changes in operating and environmental conditions. These value-added technical benefits can be enhanced through the practice of this technology in the ground transportation industry by enabling passengers to pay using any form of payment, including cryptocurrencies, via the disclosed customized view (e.g., through smartphone applications). For operators of ground transport fleets and other services, the performance and efficiency of their vehicles and personnel are easily quantifiable, allowing for the definition and analysis of meaningful metrics using location, timing, and other data recorded and continuously updated in the blockchain.

[0023] As yet another example, in the gaming industry, a customer's Social Security number, biometrics, address, photo, driver's license, prior game play, IRS tax notices, wins / losses, compensation, loyalty card / player card number information, date of birth, known partners, spouse / girlfriend, favorite teams, favorite / disliked activities, tip amounts, ATM use while on property, known e-wallets, used credit / debit cards, used cryptocurrency wallets, etc., can all be kept on the blockchain along with other customer information. Customers will not want any of this information to be publicly accessible, and public access could result in legal liability for the casino. Various implementations use different encryption and hashing technologies to securely store the data on the blockchain, allowing only authorized users to view it. As an example, a customer can participate in a game, and their name or player number can be used to identify them in public forums, but other private information will not be available to anyone other than users with proper access, including users, appropriate casino staff, auditors, regulators, etc.

[0024] Various implementations provide technologies for storing information that the owner intends to keep private but which can be seen and reviewed by authorized entities or individuals in a public ledger, and for providing access to said information. Privacy laws requiring information to remain private exist worldwide. Implementations can ensure compliance with those privacy laws by ensuring that data is stored in the correct format and is accessible only in a compliant manner. As another example, businesses and governments do not want their private information, knowledge, or trade secrets to become public. While these groups may have nothing to hide, making all their information available in an open forum where anyone has the viewability or knowledge of how people, businesses, governments, etc., operate will lead to losses, theft, and increased competition.

[0025] In some implementations, any cryptocurrency carried in a user's digital wallet (e.g., Ethereum versus Bitcoin, etc.) can be used to perform deposit transactions or inventory or parking, and other travel-related transactions (e.g., hotel rooms). In such examples, implementations of this disclosure can enable shapeshifting or value exchange between various types of cryptocurrencies or between cryptocurrencies and real currencies based on exchange rates maintained by an external data source communicating with the blockchain. For example, if a first player has only Bitcoin and deposits 2 Bitcoins into a second player who has 300 Ethereum, and the first player wins the deposit, the appropriate amount of Bitcoins will be automatically deducted from the second player's digital wallet, and the converted amount in Ethereum will be credited to the first player's digital wallet. Such automated currency conversion for payment processing can be applied to several examples described herein, including scenarios for tracking, managing, and implementing inventory (e.g., parking, retail, etc.) transactions. Such decentralized and automated currency exchange can operate continuously without requiring human intervention. In the disclosed implementation, the method can also be applied to artificial intelligence systems and user interfaces for making and accepting inputs, as well as making decisions such as gameplay, event inputs, input types, and risk / odds and expenditures without human intervention.

[0026] In some implementations, inventory transaction management, processing, and tracking according to this technology enable businesses and their customers to integrate multiple payment methods and seamlessly account for any value that can be used to pay for various goods or services. For example, customer payment accounts available for inventory transactions may be prepaid or linked to one or more other accounts. In one use case, an account can be credited or debited with money because it has been prepaid (e.g., topped up by a customer) or has received a refund for a similar or unrelated transaction. For example, cancelled parking or hotel reservations that conform to the provider's policy (e.g., cancelled before a due date / time) can be credited to a customer's account for use in another inventory transaction, and the relevant transaction information is recorded in the blockchain and made available to both the customer and the business via a customized view.

[0027] Some implementations allow data platforms to connect to electronic voting machines. These machines can directly report information about voters and ballots, and submit votes to the data platform for storage on a blockchain. The data platform can encrypt and set access levels for voting records. For example, voting machines can collect personal information, social security numbers, addresses, political affiliations, biometrics, driver's license numbers, photos, etc. Thus, while much of this information used in elections needs to remain private to the public, some information (e.g., whether a person actually voted in a particular election, their political affiliation, etc.) may be public. Furthermore, some implementations provide the use of automated technologies for identifying and / or eliminating voter fraud. For example, some implementations can use artificial intelligence or machine learning engines to review voter data stored on the blockchain and identify voters who voted twice, illegitimate voters, etc.

[0028] In addition, as shown in the examples above, this technology can be used in many other applications, such as banking, jury voting, court trials, healthcare, firearms sales, retail sales, pharmaceuticals, pensions, financial transactions, insurance, and applications requiring review, public access to data, and private access to data.

[0029] Some implementations of this technology can use optional markers in a hybrid format. For example, in some implementations, the system may have the ability to set things as private (not viewable by those without access), public (viewable by everyone), or a hybrid of both (some information is public and some information is private). There are situations where a public blockchain should be used, and that public blockchain can be completely transparent so that everyone can see it. There are also situations where some privacy is required to comply with privacy laws or simply because people do not want others to know that they are the individuals or organizations responsible for doing something; this would be a hybrid format. The ability to obscure certain information or keep it private is imperative for the aforementioned industries.

[0030] Depending on the implementation using private or hybrid formats, there are at least two options for securing data. For example, in some implementations, complete obfuscation of information can be achieved by applying encryption to unlocking. Some implementations may use multi-layered encryption so that portions of the data can be restricted and accessible to different individuals. In hybrid operating modes, some information can be public or transparently visible, while other information will remain obfuscated or private. In some cases, flags can be used to specify data access levels. A flag can be something indicating who the user is to censors, election officials, controllers, etc., and can be a number such as Citizen 1 or Customer 200. In some implementations, a codex can be used, which can be controlled by a system that obfuscates the user's identity, so no one will know who the user is, thus keeping the identity private. Only the person responsible for reviewing or managing the blockchain will be able to determine who is responsible. In some implementations, the codex will never provide this information unless it needs to be reviewed and explained.

[0031] In some implementations, censorship functionality can be integrated into the user interface, giving users (e.g., by clicking a virtual button) the ability to allow all or some information (e.g., columns, formats, sections, etc.) to be private, public, or restricted in access. Some implementations offer real-time monitoring / censorship capabilities that display and allow users to double- or triple-check content kept private. In some implementations, passwords, or passwords with two-party, three-party, or multi-signature authentication, will be part of a blockchain-powered decentralized application (DApp) that enables users to submit, add, or attach information that will be added to the blockchain. In some implementations, this information can be decentralized, allowing for automatic insertion, testing, and monitoring on the decentralized network in real time to prevent information from being leaked or illegally accessed or viewed by unauthorized parties.

[0032] This "Summary" section is provided to introduce a series of concepts in a simplified form, which will be further described in the "Detailed Description" section below. This "Summary" section is not intended to identify key or essential features of the claimed subject matter, nor is it intended to limit the scope of the claimed subject matter. Additional aspects, features, and / or advantages of the examples will be set forth in part in the description below, and in part, additional aspects, features, and / or advantages of the examples described will be apparent or may be learned by practice of this disclosure. Attached Figure Description

[0033] Many aspects of this disclosure can be better understood with reference to the following figures. While several implementations are described in conjunction with these figures, this disclosure is not limited to the implementations disclosed herein. Rather, the aim is to cover all alternatives, modifications, and equivalents.

[0034] Figure 1 An operational architecture for implementing an enhanced application that generates a custom view of restricted transactions recorded in the blockchain is illustrated.

[0035] Figure 2 This illustrates the view customization process used in the implementation of an enhanced application for generating custom views of restricted transactions recorded in the blockchain.

[0036] Figure 3 This illustrates various components of a distributed ledger architecture in an implementation used to generate a custom view of restricted transactions recorded in the blockchain.

[0037] Figure 4 An example of a parking facility is provided, for which the relevant business operations can be implemented at least in part using the disclosed systems and methods.

[0038] Figure 5 This example illustrates a block graph in an implementation of an enhanced application used to generate a custom view of restricted transactions recorded in the blockchain.

[0039] Figure 6 A flowchart illustrating an implementation of an enhanced application for generating a custom view of restricted transactions recorded in the blockchain is shown.

[0040] Figure 7 This example illustrates a block graph in an implementation of an enhanced application used to generate a custom view of restricted transactions recorded in the blockchain.

[0041] Figure 8 A flowchart illustrating an implementation of an enhanced application for generating a custom view of restricted transactions recorded in the blockchain is shown.

[0042] Figure 9 This example illustrates a block graph in an implementation of an enhanced application used to generate a custom view of restricted transactions recorded in the blockchain.

[0043] Figure 10 A flowchart illustrating an implementation of an enhanced application for generating a custom view of restricted transactions recorded in the blockchain is shown.

[0044] Figure 11 This example illustrates a block graph in an implementation of an enhanced application used to generate a custom view of restricted transactions recorded in the blockchain.

[0045] Figure 12 A flowchart illustrating an implementation of an enhanced application for generating a custom view of restricted transactions recorded in the blockchain is shown.

[0046] Figure 13 This example illustrates a block graph in an implementation of an enhanced application used to generate a custom view of restricted transactions recorded in the blockchain.

[0047] Figure 14 A flowchart illustrating an implementation of an enhanced application for generating a custom view of restricted transactions recorded in the blockchain is shown.

[0048] Figure 15 This example illustrates a block graph in an implementation of an enhanced application used to generate a custom view of restricted transactions recorded in the blockchain.

[0049] Figure 16 A flowchart illustrating an implementation of an enhanced application for generating a custom view of restricted transactions recorded in the blockchain is shown.

[0050] Figure 17 An exemplary operational architecture in one implementation of a financial audit scenario is illustrated to generate a customized view of restricted transactions recorded in the blockchain.

[0051] Figure 18 An alternative operational architecture in an implementation of a parking facility business operations tracking scenario is illustrated, used to generate a customized view of restricted transactions recorded in the blockchain.

[0052] Figure 19 An alternative operational architecture in an implementation of a hotel business operations tracking scenario is illustrated, used to generate a customized view of restricted transactions recorded in the blockchain.

[0053] Figure 20 An alternative operational architecture in an implementation of an autonomous vehicle fleet operations tracking scenario is illustrated, used to generate a customized view of restricted transactions recorded in the blockchain.

[0054] Figure 21 An alternative operational architecture in an implementation of a game oversight scenario is illustrated, used to generate a custom view of restricted transactions recorded in the blockchain.

[0055] Figure 22 An alternative operational architecture in an implementation of an inventory tracking scenario is illustrated to generate a custom view of restricted transactions recorded in the blockchain.

[0056] Figure 23 An exemplary custom view of restricted transactions recorded in the blockchain is shown.

[0057] Figure 24 An alternative exemplary custom view of restricted transactions recorded in the blockchain is shown.

[0058] Figure 25 An exemplary custom view of restricted transactions recorded in the blockchain is shown.

[0059] Figure 26 An alternative exemplary custom view of restricted transactions recorded in the blockchain is shown.

[0060] Figure 27 An alternative operational architecture in one implementation of a data access system is illustrated, capable of providing a customized view of restricted or sensitive data recorded in the blockchain.

[0061] Figure 28 A computing system suitable for implementing the techniques disclosed herein is illustrated, which includes any of the architectures, processes, operating scenarios, and sequences of operations illustrated in the accompanying drawings and discussed in the “Detailed Description” section below. Detailed Implementation

[0062] Blockchain has become commonplace in generating data on blockchains and sharing data among users in a distributed network. Unlike previous database structures, blockchain databases are maintained by numerous independent nodes scattered across a large distributed network of nodes. A public blockchain is a digital ledger that is open to any user to input and record data (also referred to in this document as transactions or block entries) into blocks of the blockchain. When a transaction is recorded in the blockchain database, it is extremely difficult, if not impossible, to change or remove transaction data from the database because the data is stored on more than one node in the distributed network. Therefore, data is added to the blockchain database by multiple users, and changing recorded data by adding, revising, or removing data requires the consent of a majority of users or the main controller and co-signatories (e.g., managers and employees, auditors and foremen, etc.) to oversee the change.

[0063] In addition, each block contains data, the hash of the current block, and the hash of previous blocks. The blockchain can also store additional details about transactions in blocks, such as the username that initiated the transaction, other usernames of the parties associated with the transaction, timestamps, executable code, and other information related to the transaction. Hashes identify blocks and the transaction data stored within them. A hash is unique relative to all other hashes and changes whenever a block is modified. Because each block contains the hash of the previous block, blocks form what is called a blockchain. Any tampering with a block will result in a change to the hash of that block. Therefore, since all other blocks in the blockchain no longer contain a valid hash of the previous block, they become invalid.

[0064] While it may be possible to change the hash of each subsequent block in a blockchain, it would be virtually impossible to change each blockchain stored on every node in a distributed network, for both private and public networks. This combination of storing previous hashes to form a blockchain and distributing a complete copy of the blockchain to every node in a distributed network (private, permissioned, and public) establishes a system of trust between users and the transactions stored in the network, especially when users are unfamiliar with each other (i.e., public networks).

[0065] This disclosure describes examples of systems, processes, and applications for generating custom views of blockchain transactions. A blockchain is maintained in a distributed node network, containing block entries requested by multiple users from user devices. Each block entry includes multiple data portions, each associated with an access level. A request to view one or more data portions of a block entry is received, the request including an access code (e.g., hash, private key, biometrics, password, personal identification number (PIN), etc.) associated with at least one access level. The access code in the request is evaluated against the blockchain of the block entry to identify the one or more data portions associated with the access level. A custom view of the block entry, including the one or more data portions associated with the access level, is generated. In some embodiments, portions of the data stored in the blockchain can be individually encrypted. Thus, depending on the access level associated with the access code, decryption of only a portion of the data can be authorized or available, while other portions remain secure.

[0066] The technical benefits that can be understood from this discussion include increased efficiency in identifying the data entries that users are authorized to access (e.g., financial records in banking institutions, customer and associated transaction data for parking facilities, inventory tracked by customers / suppliers, vehicle fleet passenger usage, route and location information, compliance data for game regulatory commissions, confidential documents from government or semi-governmental agencies, health records for medical institutions, Protected Critical Infrastructure Information (PCII), data required by government auditors / inspectors, etc.) and providing customized views of data recorded in blockchain transactions. Some of the implementations described herein also enhance security by allowing users to access data portions from blockchain entries only if the user has authorization to do so. Additionally, some implementations can provide immutable logs showing when and who accessed various data. Furthermore, in some implementations, automated verification (e.g., via artificial intelligence or machine learning engines) can occur to detect specific events (e.g., theft of user account access certificates or facility access devices, insider trading, money laundering, cheating, voter fraud, etc.).

[0067] Specifically for PCII, this technology addresses the protection of customer information and their corresponding credit card or payment information. It utilizes blockchain for payment transactions while obfuscating user information to maintain transaction privacy. The application of this technology makes some of the relevant transaction information available, possibly in a hybrid private or even public form, depending on the situation, while still allowing some information about the user's transactions stored on the blockchain to be sent via a publicly available customized view. This allows customers to keep their information private while benefiting from transparent payment / pricing based on their use or purchase of a unit of commercial inventory. In the context of parking facilities, for example, electric vehicle charging stations are made available in some parking spaces as an additional convenience and commercial service. For both customers and operators, this improves the efficiency and convenience of such services as an adjunct to the main inventory transactions, where all information related to both the main inventory (parking) and all available ancillary services (e.g., pricing, prices, and availability) is stored and updated on the blockchain and can be made available to all interested parties via a customized view.

[0068] More specifically, one implementation provides an unconventional process for generating a customized view of banking transactions. This customized view restricts sensitive user information (e.g., Anti-Money Laundering (AML) or Know Your Customer (KYC) policy documents, account numbers, account balances, account statements), but allows external banking institutions or users to verify that the account has available funds for the transaction. Another scenario provides an unconventional process for reviewing transactions in the blockchain without allowing the reviewer to see the full version of the transactions. For example, the IRS might require a review of all currency transactions performed in the previous tax year. However, it might not require the company being reviewed to provide a complete list of customer names and addresses for each transaction. By providing a customized view of the transactions, the IRS can be confident in the accuracy of the transaction amounts, and the company can maintain the anonymity of its customers.

[0069] Additional technical effects of this discussion can be appreciated within the gaming regulatory industry. For example, one implementation described herein provides an unconventional process for viewing the results of game investments while concealing the amount invested. This could be useful when monitoring the gaming community for profiting players (e.g., card counters, etc.) while allowing players to maintain the privacy of their purses. In another example, a gaming commission might request a customized view of transactions to see some personal information about each player (e.g., verification that each player has a legal age to compete, verification that each player is not blacklisted, player handle / nickname), but without making other personal information (e.g., credit card numbers used to purchase game credits, each player's legal name, etc.) visible.

[0070] In some implementations, third parties can view the game, its associated statistics, and the winners or losers. In one example, a user can select a game to watch from a range of viewable games and then place their bets (e.g., micro-bets or pay-per-view bets) based on what they are watching. In another example, the game engine is hosted and operated entirely using the disclosed blockchain-based systems and methods. For example, a random number generator (RNG) can specify the outcome of a game of chance, rather than a real-world game, using bet winners specified by an external verification source. Game features including the RNG can be stored on the blockchain, or, where the blockchain is partitioned to distribute the computational and storage workload used to run the game, on shards. In another example, if a bet is cancelled, all bets may be invalidated. The disclosed systems and methods can also be used in conjunction with the blockchain to facilitate bets on events that may occur in the future. In such cases, considering the possible dates of the event, if the event will never occur on any of the dates including the player's bets, the bet can be cancelled because the possibility that the event may never occur is a prerequisite for the bet. In this situation, investors will lose their money to the investment registrant, online bot, or the person receiving the investment.

[0071] Another example could include publicly available documentation from applicants seeking a license for a gaming establishment, as required by the Nevada Gaming Commission, detailing their prior business relationships, employment history, criminal records, and financial stability. However, deleted criminal records may not be required. Therefore, the view of the documentation will be tailored to show only those portions required by the Nevada Gaming Commission, omitting, editing, or otherwise obscuring data deemed irrelevant or unnecessary for the purpose of seeking a license. In some implementations, taxes on investment transactions and bonuses can be automatically enforced online at appropriate rates based on the investor's location, such as determined by the investor's device's IP address or GPS location. In one example, the blockchain according to this disclosure provides interoperability for the blockchain to communicate on the platform or between investments.

[0072] In some implementations, the system can ingest private information and generate publicly viewable scores, ratings, or other metrics that can be used in decision-making without disclosing fundamentally confidential information. In some implementations, the system can connect to additional public and private data sources to collect supplementary information, such as public information like FBI reports, credit reports, background reports, etc. This supplementary information can be stored in a blockchain as part of an individual's record or profile. This can be achieved using Social Security numbers, driver's licenses, facial recognition, or fingerprints as a second factor for verification. Thus, once a person enters a casino and registers a card to play, it is possible to collect big data about who that person truly is, and this information is only accessible to the casino, auditors, and regulators to verify that the person is who they claim to be, is legal, and is financially permitted or capable of playing. Commercial and government buildings, such as office buildings and airports, may be able to have camera systems that read license plates of cars entering parking facilities or monitor the facial recognition of drivers and passengers. This information can be compared and scored to see if a car or person is safely entering the facility.

[0073] In one example, a casino can host or maintain a node on a distributed node network. This gives the casino access to and control over its own indisputable record of events. If the network fails, the casino will still be able to manage all its activities based on stakes, play, equity, rewards, etc. Once the network is back online, any necessary updates to the distributed node network can be easily made through the casino's node. This backup capability and independent node scenario provide the casino with operational continuity and similar benefits can be enjoyed in the retail and parking space examples.

[0074] In another implementation, the technological effects can be recognized for unconventional processes involving tracking package delivery and inventory transfer. For example, one or more packages can be scanned in place and then scanned again as they begin transiting within a cargo unit. The transit company may want to allow a recipient of one package to view the data associated with their box, but not all other data associated with other packages in the cargo unit stored in the transaction. Therefore, a customized view of the transaction for the recipient user will be enabled, describing only the location, departure time, and estimated arrival time of their package. Additional information associated with the product can also be collected and stored on a blockchain, detailing product logistics such as the manufacturer, seller, checkpoint location, checkpoint employee, quality control manager, testing center, and the chain of custody throughout the shipment process, as well as the individuals who access the cargo unit during its shipment. At any time, or upon receipt, the recipient may be able to see a portion, but not all, of this information, depending on the recipient's status. For example, competition organizers or regulators may be able to view selective product information about the manufactured dice and the chain of custody to verify that the dice were not adversely affected during routing from a trusted dice manufacturer. This data can be displayed in a customized view.

[0075] Additionally, the examples in this paper describe how access codes in a request for a block entry can be evaluated using the blockchain of the block entry by processing cryptographic codes to verify access to view one or more data portions associated with an access level. In other examples, pointers are also maintained for each of the multiple data portions in a block entry, indicating at least one publication location for each of the multiple data portions in the block entry. Furthermore, in this example, one or more data portions associated with an access level are retrieved using pointers for each of the multiple data portions in the block entry to generate a customized view. Access to the data portions requires the use of personal identification codes, passwords, fingerprints, barcodes, retinal scans, tokens, questionnaires, or any other type of access determination method that includes two-factor, multi-factor, or additional security authentication.

[0076] In other implementations, additional technological effects can be recognized for non-routine processes of tracking and recording activities, preferences, and transactions within parking facilities. For example, entry and exit times can be collected and recorded on a blockchain and associated with vehicle identities. Additional identifying information about the driver or passenger of a vehicle using the parking facility (e.g., biometrics, facial recognition, or mobile phone) can be collected simultaneously with vehicle identities and used to verify parking payment transactions. Electronic wallets—including those for real or cryptocurrency, and credit or debit card account information received via a user interface prior to or close to a parking visit—can be securely associated with parking customers and used for fast and secure payment transactions using real-time tokenization. Additional information associated with periodic or recurring parking facility customers (e.g., multiple vehicle identifiers owned or otherwise used by a particular customer) can also be collected and stored on a blockchain and utilized to facilitate efficient parking operations and enhanced convenience for customers. In addition to manual data entry of information recorded on the blockchain, various devices located in or near parking facilities can be utilized to facilitate improved parking operations and customer experience, as described in more detail below by way of example. This data can be displayed in a customized view for parking facility staff and customers.

[0077] In another example, a blockchain of block entries requested by multiple users from a user device is maintained by maintaining separate block entries for one or more data portions associated with each access level. Additionally, in this scenario, the access code in the request is verified to view one or more block entries for one or more data portions associated with each access level. In some implementations, a blockchain of block entries requested by multiple users from a user device is maintained by maintaining separate blockchains for one or more data portions associated with each access level. Additionally, in this implementation, the access code in the request is verified to view one or more block entries for one or more data portions associated with each access level.

[0078] In some examples, the received request to view one or more data portions of a block entry includes an inventory tracking request related to a product or package or to the availability of parking spaces in the parking facility at any given time. In a parking industry context, such a request could be received by the owner or operator of the parking facility or by current or potential parking customers. In other examples, the received request to view one or more data portions of a block entry includes a financial audit request. In some scenarios, the received request to view one or more data portions of a block entry includes a game oversight request or a request related to an investigation involving a vehicle currently or in the past parked in the parking facility or the time of its entry or exit from the facility. In other scenarios, the access level associated with one or more data portions of a block entry includes at least one of a private access level, a permitted access level, and a public access level. However, in still other examples, the access level associated with a block entry includes at least one of a private access level, a permitted access level, and a public access level.

[0079] While this disclosure describes various implementations, it should be understood that additional examples may be included for technological improvements in additional industries. Example industries may include defense and security, finance and insurance, retail (e.g., firearms), sales and licensing, medical records, accounting, shipping and logistics, pharmaceuticals and drugs, cannabis and cannabidiol (CBD), oil and gas, energy and commodities, national security, etc.

[0080] Refer to the attached diagram. Figure 1 An exemplary operational architecture 100 is illustrated in relation to the processing of operations for managing an exemplary enhanced system, with which various aspects of this disclosure can be practiced. The operational environment 100 includes a blockchain network 101. The blockchain network 101 employs a view customization process 200 in the context of authorizing users to view data portions of blockchain entries based on their approved access levels. The blockchain network 101 may include various hardware and software elements in a support architecture suitable for executing the view customization process 200. Figure 28 The example of such an architecture is illustrated in the Controller 2800.

[0081] Server nodes 110-112 include one or more servers and devices capable of running blockchain applications. User equipment interacting with server nodes 110-112 may include, but is not limited to, personal computers, mobile phones, handheld devices, tablet computers, desktop computers, laptop computers, wearable computing devices, voting machines, gaming machines, electronic financial exchanges, security systems, transponders, cameras or other imaging devices, key fobs, sensors, access cards, etc., or any other form of element, including any combination or variation of computers.

[0082] More specifically, Figure 2 An example of view customization process 200 is illustrated. As mentioned, this view customization process can be adopted by blockchain network 101 to generate a customized view of restricted transactions recorded in the blockchain, as described herein. Some or all of the steps of view customization process 200 can be implemented as program instructions within the context of one or more components of an application used to execute the customized view features. The program instructions instruct blockchain network 101 to operate as follows, in Figure 1 References in the context of Figure 2 The steps in the process.

[0083] In operation, blockchain network 101 maintains blockchain 120, which contains block entries requested by multiple users from user devices. Each block entry comprises multiple parts, each associated with an access level (step 201). The blockchain database is maintained by numerous independent users distributed across blockchain network 101 on server nodes 110-112. Blockchain 120 is a digital ledger open to any user (e.g., a public blockchain), a specific group of users (e.g., a private blockchain), or a combination of private and public users (e.g., a hybrid blockchain) to input and record data into blocks 130 of the blockchain. Blockchain 120 can be added by multiple users and recorded by multiple nodes 110-112 in the distributed network.

[0084] In the context of the parking industry, parking facility operators can maintain certain records on the blockchain, such as the GPS location of publicly accessible parking facility entrances, identifiers of available parking spaces (e.g., alphanumeric), prices, and parking sales, special offers, or promotions. In some implementations, such records are publicly accessible to users who first perform one of the following actions: visit a website, subscribe to an email list, download a smartphone application, or park at the parking facility for the first time. Other records, such as customers' digital wallets, credit / debit card account information, usage history, vehicle identification information, and portrait images, can be maintained on the blockchain as private records accessible only to the respective customers and parking facility operators. In some implementations, on a limited basis—including on a subscription basis—vehicle recovery or repair service providers can access blockchain records such as the current parking location, vehicle identifier, and associated customer name. In this case, parking facilities experiencing a need for vehicle services (e.g., windshield replacement, dry cleaning, pet boarding) can schedule and receive services from providers, even during periods when the vehicle owner and vehicle are not in the same location at the parking facility. Customers of parking facilities can optionally grant permissions to the facility via a user interface, enabling the facility to process payments to service providers using the customer's payment account information recorded on the blockchain. In this case, instead of the subscription fees paid by vehicle service personnel to the facility operator, or in addition to the subscription fees paid by vehicle service personnel to the facility operator, the parking facility can collect a commission from the vehicle service payments to facilitate service and payment processing. Ancillary services in parking facilities utilizing blockchain in the same or similar manner may include, for example, car washing or car detailing, refueling, electric vehicle charging, ride-sharing or carpooling arrangements, valet parking, vending machines, cafes, newspapers, etc.

[0085] Block 130 includes block entries 140-142. Block entries 140-142 may include various types of data, including parking facility customer usage and transaction records, the number and location of available parking spaces in the parking facility, self-parking or valet parking, game inputs, inventory records, medical records, banking and financial records, smart contracts, and any other combination or variation thereof. For example, a user (e.g., a parking customer) can create block entry 140 by entering into a contract with another user (e.g., a parking facility operator) and then storing that contract as block entry 140 on blockchain 120 on nodes 110-112 in a distributed network environment. As another example, electronic devices (e.g., parking facility access control and payment processing devices and systems, sensors, beacons or other devices for detecting the availability status of parking spaces in the parking facility, electronic voting machines, competition machines, censorship software running on one or more servers, end-user devices, etc.) can automatically connect to the blockchain network and request data to be added to a block entry.

[0086] To add new block entries with data portions, blockchains can use consensus protocols such as Proof-of-Stake (PoS), Proof-of-Work (PoW), Delegated Proof-of-Stake (DPoS), etc. For example, in PoW, in order to elect server nodes 110-112 as leaders to select the next block entry 140 to be added to the blockchain, a particular server node must find a solution to a specific puzzle or mathematical problem (usually by brute force). Once a solution is found, the server node publishes it to other nodes for verification. When the nodes agree that the solution is correct, the new block entry can be added to the blockchain. Examples of Proof-of-Work are SHA-256, Blake-256, CryptoNight, Quark, SHA-256, SHA-3, 4crypt, scrypt-jane, HEFTY1, or others or combinations thereof. Conversely, PoS is based on the participation and risk value (e.g., stake) of server nodes. DPoS is a more efficient variant of PoS that provides a high level of scalability by limiting the number of validators on the network to a set of delegated representatives (e.g., voters) to vote on whether to add an entry to the blockchain.

[0087] Block entries 140-142 each also include data portions 150-155. Data portions 150-155 comprise the components that make up each of block entries 140-142 and can be broken down into multiple segments based on user requests or transaction formats (which are both standardized and customized). For example, if a user marks a portion of data from a transaction as confidential, that portion can be assigned as private. Data can also be assigned as private if it belongs to a category previously assigned as private. For example, a user could categorize all credit card numbers as private. Conversely, a portion of data can also be assigned as public or permitted by the user. In some implementations, a portion of data can be designated as accessible only to the receiving user if the originating or controlling user grants permission (e.g., the originator of a transaction assigns the block entry and all data portions as private, and the ability to view a portion of the data requires permission via signature terms and condition forms). This user permission feature can be included in platforms that allow users to grant permitted access through user permission segments.

[0088] Some implementations of this technology modify traditional protocols and workflows used to add data to a blockchain. For example, in some implementations, server nodes 110-112 are required to identify or classify portions of the data into one or more categories. This can be accomplished, for example, using artificial intelligence or machine learning to classify data into one or more categories (e.g., email addresses, vehicle identification numbers (VINs), license plate numbers, social security numbers, full or partial images of a face used for facial recognition algorithms, serial numbers associated with decoded radio frequency identification (RFID) or near field communication (NFC) signals, or customer account numbers, etc.). In some implementations, decentralized applications (DApps) may be responsible for the initial sorting and classification of the data. When block entries 140-142 are added, the starting line of the entry, which typically includes the hash and timestamp of the previous block, can be modified to include information about the data category within the entry, the access level for each data portion, access restrictions, etc. For example, some implementations may create an index and / or access level information stored within the block entry. This allows the data to be easily identified or associated with the appropriate access level when retrieved later. Furthermore, in some implementations, the server node responsible for adding data can organize the data and set different encryption levels for different data segments 150-155. In other implementations, middleware (e.g., on a data platform located between the blockchain network and the connected devices) can be used to decrypt encrypted data stored on the blockchain, classify information, and enforce access level permissions, thereby creating customized views.

[0089] In some scenarios, users can set a default setting to allocate all data in a transaction as public, and can selectively allocate individual segments of data as private, or vice versa. Similarly, in cases where data is not available to the general public but may be accessible to various groups of users (such as members of censorship boards, law enforcement officials, government regulators, medical workers, etc.), portions of the data can also be allocated as permissioned. In other examples, blockchain 120 may include default rules for allocating portions of data as private, permissioned, or public.

[0090] For example, Blockchain 120 can identify any driver's license number, RFID tag, or the person who parked the vehicle. Alternatively, NFC, parking space reservation identifiers, license plate numbers, vehicle identification numbers, or social security numbers should be automatically set to private access. While several examples and implementations included herein describe primary access levels that would be classified as private, permitted, or public, it should be understood that any number of access level categories can be recognized within the scope of this disclosure. Furthermore, the status of an access level can be automatically changed or updated based on the detection of certain events. For example, all data regarding a transaction may remain private for a period of time, at which point the system may change the access level to public for some or all of the relevant data.

[0091] In the next operation, blockchain network 101 receives a request from a user to view one or more data portions 150-155 of block entry 140, the request including an access code associated with at least one access level (step 202). The viewing request can be initiated by a user who is a party to a transaction stored in block entry 140, such as an operator of a parking facility receiving data requests from customers or a participant in a game investment. The user can also be someone who is only interested in business operations or transactions but does not directly participate in them, such as a driver looking for convenient parking, a tax auditor verifying income data, a transfer agent or third-party financial custodian holding stocks and bonds, a debt collection agency collecting debt payments on behalf of lenders, or a shareholder viewing recent company dividend transactions.

[0092] In the next step, the access code is evaluated against the blockchain of the block entry to identify one or more data portions associated with the access level (step 203). Access codes can be assigned to users based on user status such as government employees, package delivery employees, bank managers, parking garage customers, and operators. Access codes can be determined based on an encrypted code (e.g., a private key or hash) associated with the access level or data portion given to the user. Access codes can be further verified based on passwords, signatures, fingerprints, barcodes, processing chips, questionnaires, biometrics, tokens, and any other method that enables the user to verify authorization to access data portions 150-155 associated with the access level. In some example scenarios, data portions 150-155 can be divided into different blockchains or block entries based on the associated access level. In this scenario, access code 150 might be required to access the blockchain or block entry to view the data portion associated with the access level.

[0093] In the final operation, a custom view is generated that includes block entries of one or more data portions 150-155 associated with the access level (step 204). This custom view can be generated by the data access platform. The custom view can be modified to include only those data portions associated with the verified access level, or it can include all data portions 150-155, with unauthorized data portions crossed out in black from the record view. This custom view can be displayed in a blockchain application (e.g., a DApp) on a user's device, delivered to the user as a record message, or displayed to the user or user community in any other way.

[0094] According to the various implementation schemes, adding data to the blockchain, security level filtering, data classification, access level assignment, review, and / or other functions can all be completed autonomously. For example, when a vehicle enters a parking facility, including for... Sensors, cameras, or other imaging devices that receive other wireless signals, as well as access control systems such as door and access device readers, collect data to identify the vehicle, its driver, and possibly its passengers. Meanwhile, sensors such as motion, weight, distance, or proximity sensors collect data to monitor the availability status of parking spaces in parking facilities (e.g., occupied vs. unoccupied).

[0095] As another example, when a user enters a casino, data can be collected from various systems (e.g., surveillance cameras, parking garage cameras, loyalty card systems, room access systems, entertainment databases, etc.) and added to the blockchain. Given the volume of data, artificial intelligence and / or machine learning engines (e.g., using support vector machines, artificial neural networks, Bayesian networks, supervised learning, unsupervised learning, and / or other techniques) can be used to identify, correlate, and classify relevant data that can be added to the blockchain. The data itself can be indexed for search and / or future ingestion. In other implementations, data can be segmented and added to player profiles. Since different data segments can be assigned different access levels, those requesting data can be automatically supplied only with the appropriate data segment for their access level. Similarly, data can be automatically reviewed or audited to identify violations (e.g., security or safety considerations, unsafe driving or other undesirable customer behavior in the parking facility, violations of racing rules, cheating, collusion, prohibited racers, vehicles or people not permitted to enter or otherwise use the parking facility, etc.).

[0096] Similar to parking facility operations and casino surveillance, various implementations of this technology can be applied to vertical industries that can benefit from the disclosed systems and methods, which can automatically record, track, analyze, and review data without human oversight for executing transactions and gatherings, and for leveraging actionable intelligence to improve operations and customer experience. For example, some implementations can be coupled with secure datasets (possibly stored on a private blockchain) to obtain biometrics or data about individuals. In this way, government agencies (e.g., ICE or the Department of Homeland Security) can provide data that can be used to identify individuals and determine whether they should be granted access to specific data, activities, and / or locations. For example, various implementations of the system can be used to screen individuals for a trusted traveler program. For instance, when an individual enters an airport, surveillance cameras can collect video data that can be ingested by an artificial intelligence or machine learning engine. This data can be linked to license plates, travel records, biometrics, etc., to initially identify individuals and determine if a violation is in progress, pre-screen people (e.g., for faster screening), or determine whether a user can be denied entry to an aircraft or other mode of travel. In some implementations, each person can have their driver's license scanned, and the system can automatically classify the identification as legitimate or fraudulent and search records in the blockchain to help make a decision.

[0097] Figure 3 Various components of a blockchain data platform utilizing a distributed ledger architecture, according to various implementation schemes of this technology, are illustrated. For example... Figure 3As illustrated, the blockchain data platform can use one or more servers 305A-305N. Each server may include a blockchain interface 310, a monitoring agency 315, a client interface 320, a rules engine 325, an encryption / decryption module 330, an analysis module 335, an event module 340, a multi-factor authentication module 350, a report generator 355, and / or a database 360 ​​and / or 365 for storing logs, subscriber policies, transaction policies, location policies, etc. Additionally, the blockchain servers 305A-205N can connect to the blockchain 370, the client 375, the trusted data source 380, and / or the records 385.

[0098] Each of these modules, components, or databases may be embodied as dedicated hardware (e.g., one or more ASICs, PLDs, FPGAs, etc.), or as programmable circuitry appropriately programmed with software and / or firmware (e.g., one or more microprocessors, microcontrollers, etc.), or as a combination of dedicated hardware and programmable circuitry. Other embodiments of this technology may include some, all, or none of these modules and components, as well as other modules, applications, databases, and / or components. Furthermore, some embodiments may incorporate two or more of these modules and components into a single module, and / or associate a portion of the functionality of one or more of these modules with different modules. For example, in one embodiment, rule engine 325 and event module 340 may be combined into a single module for identifying and enforcing various rules and event policies on a user terminal.

[0099] Client 375 can connect to one of the blockchain servers 305A-305N using client interface 320. Client 375 may be able to download (or have pre-installed) firmware or software from the blockchain servers 305A-305N that allows client 375 to input and view block entries (or selected portions thereof). Block entries may include a wide variety of transactions (e.g., financial transactions, customer usage history and service preferences in parking garages, game inputs, medical records, inventory tracking, etc.) and a wide variety of access levels (private, permitted, public, etc.). In some implementations, blockchain servers 305A-305N process cryptographic codes to verify access to view one or more portions of each transaction.

[0100] In some implementations, blockchain servers 305A-305N may maintain pointers for each of a plurality of portions in a block entry, indicating at least one publication location for each of the plurality of portions in the block entry. A customized view of the block entry can then be generated by retrieving the portion associated with the access level using the pointers for each portion in the block entry. In other implementations, blockchain servers 305A-305N may maintain separate block entries for the data portion associated with each access level. Blockchain servers 305A-305N can evaluate the access code in the request using the block entry of blockchain 370 to identify the data portion associated with the access level. In some scenarios, blockchain servers 305A-305N may maintain separate blockchains for the data portion associated with each access level. Blockchain servers 305A-305N can then evaluate the access code in the request using blockchain 370 to identify the data portion associated with the access level.

[0101] In some examples, encryption / decryption module 330 can be used to encrypt information stored in blockchain 370. In some implementations, encryption / decryption module 330 can use various non-homomorphic and / or homomorphic encryption methods. While non-homomorphic encryption can provide stronger security properties, the use of homomorphic encryption allows computation on encoded data without decryption. Therefore, various components of parking facilities and customers' vehicles, or various components of a gaming system, can interact and operate on the data portion without exposing sensitive data.

[0102] Monitoring agency 315 can monitor transactions and user activity. This may include receiving information from external sources. In the parking facility example, said external sources include people, devices, or systems, such as customers using smartphone applications for parking facilities, facility managers and staff using various business information technology systems and client devices, and others. Receivers of other wireless signals, cameras, or other imaging devices, and access control systems such as door and access device readers that collect data for identifying the vehicle, its driver, and possibly also its drivers and passengers. Additional external data sources in parking facility situations may include sensors such as motion, weight, distance, or proximity sensors that collect data for monitoring the availability status of parking spaces in the parking facility (e.g., occupied vs. unoccupied). In the casino example, said external sources include people, devices, or systems such as, but not limited to, Client 375, video surveillance systems, loyalty card systems, key engines, biometric sensors, and other external systems. In some implementations, multi-factor authentication may be used before allowing users to enter or access monetary transactions, parking reservations, payment methods for parking, parking history, vehicle, driver and passenger personal identification information, medical records, game input, inventory activity logs, etc.

[0103] For example, when a parking facility customer accesses their credit / debit card records or verifies an account used for parking payments via a smartphone application, the multi-factor authentication module 350 can be used to request two different types of authentication (e.g., a password plus an alphanumeric code transmitted to the customer via a text message or telephone call to a phone number associated with the customer's account registration data). As another example, when a patient accesses medical records, the multi-factor authentication module 350 can be used to request various types of authentication (e.g., personal identification number, biometrics, tokens, etc.). The rules engine 325 can overlay rules onto the transaction interface being presented on the client 375. These rules can be based on various strategies stored in the database 365 (e.g., subscriber strategies, transaction strategies, location strategies, etc.). The analytics module 335 can generate various analyses on parking space usage trends, tiers, clients, games, medical diagnoses, payroll, package delivery, expenses, accounts, and / or other system components or activities. This information can be used by the report generator 355 to create customized views of transactions.

[0104] The restricted access module 340 can be used to create customized access requirements for different portions of the data in each transaction and for different users / user types. Rewards can be stored within blockchain 370, in record 385. Access requirements can be generated through user-input transactions, determined based on previously specified user preferences, or determined by policies required by other parties (e.g., permitted access to medical records required by the Health Insurance Portability and Accountability Act of 1996 (HIPAA), state laws regarding minimum age for competitions, etc.), and a customized view of the records can be presented based on those access policies. Databases 360 and / or 365 can be used to store logs, subscriber policies, transaction policies, location policies, etc. These can be local storage for data retrieved from record 385 associated with blockchain 370. Additionally, servers 305A-305N and blockchain 370 can connect to trusted data source 380 to verify external events (e.g., the outcome of a sporting event, reconciliation of seller / buyer journal entries, etc.) or information (e.g., authorized drivers other than registered users of the parking facility who have authorized the authorized drivers to use their parking accounts, or the status of security investigations) required to determine the data stored in record 385.

[0105] Figure 4 An example of a parking facility 400 is provided, for which the disclosed systems and methods can be used at least in part to implement relevant business operations. The parking facility 400 has at least one entrance 402 and at least one exit 404. Access control and payment portal consoles 422 are located at the entrance 402 and exit 404 of the parking facility 400. In some embodiments, the console 422 is divided into at least two separate and distinct structures. For example, a first console 422 for access control is located at the entrance 402, and a second console 422 for payment processing is located at the exit 404. In any case, the access control function of the console 422 can be implemented, for example, through automatically actuated entrance doors 424 and exit doors 426.

[0106] Parking facility 400 includes a plurality of parking spaces 408 located on a road surface 406. Each of the parking spaces 408 may be marked with numbers, letters, or alphanumeric identifiers, such as those drawn on the road surface 406 or marked on an adjacent wall, fence, or guardrail located at or near the parking space 408. At any given time, at least a portion of the parking spaces 408 may be occupied by a vehicle (e.g., the first vehicle 410). Parking spaces 408 that are not occupied are naturally available for customers to park their vehicles. In one example, each of the plurality of parking spaces 408 includes a sensor 418 or other device for monitoring the status of each parking space 408—such as whether it is currently occupied or currently available in the parking facility 400. In some embodiments, one of the plurality of such sensors 418 or other devices is located in the facility 400 and is configured to monitor the availability status of at least two parking spaces 408.

[0107] Sensor 418 may include a proximity sensor positioned on the road surface 406, within the area defined by the respective parking space 408 (e.g., at its center). In some embodiments, the proximity sensor may be positioned on a ramp, level surface, ceiling, wall, or other structure adjacent to the parking space 408. In any case, sensor 418 or other devices for monitoring the availability status of parking spaces 408 are configured to continuously or periodically transmit data indicating whether a particular individual parking space 408 or a finite group (e.g., several) of parking spaces 408 is occupied by a vehicle. Thus, the data transmitted by sensor 418 further represents and is associated with a specific parking space 408 identifier and its availability status. For example, a first vehicle 410 is currently parked in parking space 408, and at least several other vehicles are also parked in occupied parking spaces 416 (…). Figure 4 (Represented by "X" in the middle). Meanwhile, at least several parking spaces (408) are currently unoccupied, such as... Figure 4 The availability of parking spaces 414 is indicated by corresponding sensors 418 on the road surface 406. Among these currently available parking spaces 414, there is a parking space 408 from which a second vehicle 412 recently departed from the parking facility 400.

[0108] Current or potential customers of parking facility 400 can view the inventory of available parking spaces 414 before arriving at parking facility 400. Data provided by sensor 418 is recorded in a blockchain and can be communicated in real-time or near real-time to users, including customers, staff, and managers, enabling timely and informed decisions. A customized view of the availability status of parking spaces 408 in facility 400 can be provided to customers via a display on a personal computer, smartphone, or other suitable computing device. In some implementations, parking space 408 availability data may include information on whether one or more parking spaces can be reserved for use by a customer at a later time on the same day as the inquiry or on a later day. Therefore, parking system operators and their customers can utilize the disclosed systems and methods to facilitate hourly, daily, or monthly parking transactions and a convenient experience.

[0109] For example, in addition to or instead of the parking space availability data provided by sensor 418, customers may include their vehicle or personal identification information along with their account registration data for a smartphone application. Vehicle information may include a license plate number 440 or a vehicle identification number (VIN), while biometric or personal information may include a portrait image of the driver or passenger associated with the parking account registration or an ID number used to obtain access to the parking facility 400 (e.g., a key card or keychain).

[0110] Access control and payment console 422 may include one or more sensors or other devices for detecting or otherwise aggregating one or both of vehicle and personal identification information. For example, console 422 may include a radio frequency receiver 428 positioned in the field of vision of a portion of a vehicle, on which a corresponding radio frequency transmitter or transponder 432 is placed for use in parking facility 400. Transmitter 432 is configured to transmit wireless signals that encode data uniquely identifying the vehicle or its owner or authorized user. Transmitter 432 may also take the form of a keychain or key card carried by a parking customer and is manually positioned in the field of vision of receiver 428 upon entry into parking facility 400. In either case, like the aforementioned sensor 418, receiver 428 is an external source of data related to parking business operations recorded in the blockchain. Receiver 428 may relay this data to an intermediate transmitter or processor before it is recorded in the blockchain, or receiver 428 may directly relay or otherwise transmit this data to the computing and communication system that performs the recording of data into the blockchain.

[0111] In another example, console 422 includes camera 420 or other imaging device positioned within the vehicle's windshield or side window view as the vehicle approaches and is positioned on console 422. Still images or video streams acquired by camera 420 can be transmitted to a local or remote computing system or server for image processing analysis. Where a parking customer has previously provided a portrait image as part of account registration data recorded on a blockchain, image processing analysis can be used to determine the identity of the driver or passenger of the entering vehicle using one or more facial recognition technologies known to those skilled in the art. Additionally or alternatively, camera 420 can be positioned on console 422 and configured to acquire an image of at least one of the license plate 440 and vehicle identification number of the entering vehicle. Such image data can be transmitted to a local or remote computing system or server using known alphanumeric character recognition technologies for image processing analysis to determine the identity of the vehicle and the parking customer associated with it. In some embodiments, image or video data acquired by camera 420 is used to determine vehicle and customer identity using two or more of a portrait photograph, biometrics, mobile phone number, license plate 440 number, and vehicle identification number. For example, if a customer's facial appearance changes over time compared to a registered portrait image, such as due to natural aging, sun tanning or sunburn, wearing a hat, makeup, a wig, glasses, colored contact lenses, a scarf or mask, or facial hair growth, it may be advantageous for the customer and parking facility 400 operator to determine vehicle and customer identity based on a source different from or other than a complete or partial facial image.

[0112] To allow a vehicle to enter parking facility 400, data acquired by receiver 428 and / or camera 420 is verified against customer account registration data recorded in the blockchain. After a successful verification process confirming the customer and their vehicle are associated with a reputable parking account, entry gate 424 is automatically raised, and any other access control devices (e.g., a puncturable tire rail) are deactivated for a sufficient time to allow the vehicle to drive through entrance 402 and onto the main parking area defined by road surface 406. In a preferred implementation, while the driver's vehicle is still stationary at entrance 402 (e.g., just before entry gate 424 is raised), the driver receives a message informing them of the nearest available parking space 414, or another available parking space 414 determined based on their pre-recorded customer preferences. In one example, a display or LED array on console 420 positioned within the driver's field of vision displays the corresponding identifier for the available parking space 414. In another example, the available parking space 414 identifier is read aloud from the speaker of the console 420 at a volume level sufficient for the driver to hear through the closed glass window and taking into account the typical background noise of the parking facility 400.

[0113] Timestamps, including the time and date of vehicle entry, can be recorded in the blockchain and associated with the vehicle and / or the corresponding customer's identity. This timestamp data facilitates the determination of parking fees to be claimed and collected from customers when they leave the parking facility. In usage scenarios involving subscription-based parking at parking facilities (e.g., weekly or monthly), recording timestamp data in the blockchain allows customers and operators to perform trend forecasting and analysis of usage data as needed.

[0114] The disclosed system and method also facilitate improved operational efficiency and customer experience at parking facility 400 during the process of a vehicle (e.g., second vehicle 412) leaving facility 400. Receiver 428, transmitter 432, and camera 420 can each be used individually or in any combination, as described above, to identify vehicles or customers at or near console 422 before reaching exit 404 and leaving parking facility 400. After vehicle or customer identification, this data, along with their associated timestamps, is recorded in a blockchain. In the case of a prepaid subscription parking account plan, after identifying and verifying vehicle 412 or its associated customer, exit door 426 is automatically raised, and any other access control devices (e.g., pointed rails capable of puncturing tires) are deactivated for sufficient time to allow the vehicle to drive through exit 402 and leave parking facility 400. In this case, since the account is under a prepaid parking subscription, payment processing is not required. However, in the case of a non-subscription account, the aforementioned identification and verification of the vehicle and customer must be performed before payment processing.

[0115] To improve business operations and customer experience associated with leaving parking facility 400 in cases requiring payment processing (e.g., hourly or daily parking), data acquired by at least one of receiver 428 and camera 420 can be again recorded in the blockchain and used for automated, fast, and secure payment processing based on parking fees, entry and exit timestamps, and customer payment information (e.g., credit / debit card accounts, digital wallets, or cryptocurrency wallets), each of which is also recorded in the blockchain. Thus, in such a scenario, after successful identification and verification of the vehicle and associated customer, and upon successful payment, exit gate 426 is automatically raised, and any other access control devices are deactivated for a sufficient period to allow the vehicle to drive through exit 402 and leave parking facility 400. In some embodiments, console 422 may include devices and subsystems for accepting manual payments using cash, credit / debit cards, or digital wallets for physical or cryptocurrency payments via revenue control equipment or mobile phones, applications, or DApps. In one example, console 422 includes a payment acceptance device 430 (such as a credit / debit reader or cash / coin counter) and a display device 434 positioned within reach of the driver of vehicle 412 parked before exit gate 426. For example, customers without a pre-registered account with parking facility 400 can still pay for parking to leave facility 400. Even for such unregistered customers, business operations and customer experience can be improved by leveraging the systems and methods disclosed by blockchain, for example, by enabling driver or vehicle identification, automatically calculating elapsed time for fee determination based on data acquired by camera 420, and displaying relevant payment instructions and other helpful information to the driver on display device 434.

[0116] The revenue control equipment in parking facility 400 may include the aforementioned console 422 and associated devices and subsystems such as camera 420, receiver 428, and sensor 418. Alternatively or additionally, the revenue control equipment of parking facility 400 may include parking kiosks with credit card / bill acceptor / mobile payment capabilities to operate and allow people to enter / exit. Parking kiosks may be integrated into console 422, or they may be stand-alone devices located in various other convenient locations within facility 400. Revenue control functions include ticketing, access control, access cards, fees, taxes, statistics and analysis, performance management, parking control (access gates, e.g., 424, 426), screening functions, web and mobile payment interfaces, printers, etc.

[0117] In some implementations, customers of parking facilities 400 embodied in or including autonomous vehicles can be guided by an additional facility 400 subsystem, enabling these vehicles to safely park themselves upon entry and similarly return to a designated location before or after leaving facility 400. Figure 4 In the illustrated implementation, sensor 418 includes a beacon for transmitting a homecoming signal to a corresponding receiver in the autonomous vehicle. The beacon signal is paired with the receiver in the vehicle and generated upon completion of a parking transaction that enables the autonomous vehicle to enter facility 400 and have an available parking space 408 assigned to it. The autonomous vehicle may also include a transponder or other device that provides vehicle identification, which allows access control and is unique to the vehicle, company, owner, etc. In the case of an autonomous vehicle user, the means for identifying the autonomous vehicle may be one or more of a transmitter, transponder, license plate 440 identification, license plate 440 identity, etc., enabling entry and exit without human intervention. In one example, in the case of a non-subscribed parking account, the aforementioned identification and verification of vehicle and customer identities may be performed prior to payment processing.

[0118] In some implementations, one or more parking spaces 408 of parking facility 400 include electric vehicle charging stations 436. Charging stations 436 can be configured for either wired or wireless charging of electric vehicles. Charging stations 436 may include equipment and subsystems for identifying vehicles or customers utilizing charging stations 436 in parking spaces 408 occupied by the respective vehicles. In one example, a registered customer having a transmitter 432 in or on their vehicle can be used to associate charging usage statistics (e.g., on / off times or charging energy delivered to the electric vehicle) with the customer's account with parking facility 400. This charging station 436-related data can be recorded in a blockchain, and payments due for the use of charging stations 436 can be automatically determined and deducted from the customer's payment certificate recorded in the blockchain. This payment process for ancillary services such as electric vehicle charging can be initiated and completed after the use of charging stations 436 is completed, or can be added to the above-described process for completing payment before leaving parking facility 400. Based on the disclosed systems and methods, those skilled in the art can readily envision how ancillary services (e.g., windshield and other vehicle maintenance / repair services, car washes, detailing, dry cleaning machines, pet boarding, etc.) besides the use of charging station 436 can similarly benefit in terms of operational efficiency and improved customer experience.

[0119] By applying the disclosed systems and methods, the convenience and efficiency of parking operations and such ancillary services are further enhanced by associating vehicles and their owners with parking spaces and any other selected services, and storing information linked to transaction data on the blockchain. Customers and operators can easily access this data through customized views. As described above, data such as license plate 440 identification and identity are collected and stored on the blockchain, and identity management is facilitated using cameras 420, sensors 418, transmitters 432, beacons, transponders, Bluetooth, NFC, etc.

[0120] In some implementations, based on the disclosed systems and methods, parking facility 400 can offer membership programs to its customers for signing up when reserving parking spaces, making transactions, subscribing to recurring parking plans, etc. The blockchain and customized views of this technology can be used to facilitate membership rewards programs. In the context of the parking business, rewards that can be offered to customers who reach certain milestones, such as time spent as a member or the amount spent in US dollars, include, but are not limited to, free car washes, free parking days, or other special privileges. Rewards will also be associated with the corresponding customer and recorded and tracked on the blockchain. Rewards can be available to the company or individual. Such rewards programs can function in a manner similar to airline mileage programs, benefiting both customers and parking facility operators.

[0121] Figure 5 This illustrates a block graph 500 in an implementation of an enhanced application used for parking facility business operations and transactions including payment processing, to generate a customized view of restricted transactions recorded in the blockchain. Block graph 500 includes inventory block entries 501, a data platform 510, servers 520-522, blockchains 530-532, and records 502.

[0122] Block entry 501 represents any data transaction that will be permanently recorded to the blockchain, such as data received and recorded from customers, connected devices, parking facility 400, operators and staff, and external sources (e.g., sensors 418, receivers 428, and cameras 420). Block entry 501 is then processed by miners and added to the end of the blockchain via data platform 510. Block entry 501 also includes data portions already represented herein by parking spaces, parking facility customers, and parking fees. Parking spaces maintain the inventory and availability status of parking spaces 408 in parking facility 400. Parking facility customers include data related to the vehicle, driver, and possibly passenger identifiers associated with the customer, as well as their account and payment-related data. Parking fees include data specifying the cost of parking in parking facility 400, including by hour, week, or month. It should be noted that although each of the data portions is represented separately, the data portion is part of a transaction represented by block entry 501. Block entry 501 may include any transaction or contract that has been executed and recorded in the distributed ledger platform environment for the purpose of operating parking facility 400. In this example, block entry 501 may include a customer's order, reservation, or spontaneous purchase request for a parking space in the parking facility. In some implementations, the token may alternatively or in lieu of one or more of a customer's order, reservation, or spontaneous purchase request for a parking space in the parking facility.

[0123] Data platform 510 refers to any one or more computing systems capable of hosting blockchain applications, in which Figure 28 The controller 2800 in the example is representative. The data platform 510 provides a secure distributed ledger system for recording parking transactions and parking space availability status in a blockchain. The data platform 510 can be implemented on numerous distributed network nodes, accessible to a wide variety of users such as tax auditors, financial institutions, regulatory authorities, customers, company employees, parking facility owners, parking inspectors, managers and staff, marketing companies, advertisers, etc.

[0124] Data platform 510 may also include servers 520-522. Servers 520-522 may represent any one or more computing systems to which distributed network nodes can communicate. Examples include other devices on which corresponding applications or services are installed, enabling user devices to transmit transactions to be added to the blockchain and distributed among network nodes in the distributed network. Examples include media servers, web servers, and other types of endpoints that can transmit or receive transaction data to or from user devices and network nodes using communication protocols including, but not limited to, 5G, Wi-Fi, NFC, Miracast, etc. The aforementioned sensor and access control or payment processing devices and systems can automatically transmit transaction or business operation data to network nodes, as referenced above. Figure 3 and Figure 4 As described. In some implementations, data platform 510 can dynamically select which servers 520-522 are authorized to store data. For example, a company or government may have geographical restrictions, encryption standards, cybersecurity standards, or other restrictions on the server nodes storing the blockchain. Therefore, data platform 510 can manage the logistics of dynamically selected servers based on these restrictions. For example, if a particular server is deemed to be under attack or illegally accessed, data platform 510 can dynamically remove that server from the blockchain network and consider adding one or more additional servers if necessary. In this way, each data owner can set selection criteria for where the data should be stored and the minimum IT standards required for that group of servers.

[0125] Block diagram 500 also includes blockchains 530-532. Blockchains 530-532 can contain a continuously growing list of records—called blocks—that are linked and protected using cryptography. Each block in blockchains 530-532 contains a timestamp and a hash. The hash consists of both the cryptographic hash of the current block and the cryptographic hash of the previous block in the blockchain. Each block also contains data associated with the block entry. In this example scenario, each data component (parking space, customer, and fee) has been recorded separately in different blocks and in separate blockchains 530-532.

[0126] Furthermore, each of blockchains 530-532 is associated with a separate access level. For example, blockchain 530 is a public access blockchain, which allows any user interacting with the distributed ledger to view the blocks and the data portions stored in each block. A public user can be any user interested in viewing parking spaces in one or more parking facilities available for transaction in blockchain 530, and there is no privacy for this data portion. Conversely, blockchain 531 is a private blockchain where the data portions can only be accessed and viewed by authorized users, such as internal company personnel. In this example scenario, the customer has been stored separately on blockchain 531 and is private to all users interacting in the blockchain network except for users with exclusive access to the data (such as a manager within the company initiating the transaction). Blockchain 532 is a permissioned blockchain, meaning that a limited set of parties, but not all users, can view the data portions recorded in the blocks. Fees are stored within blockchain 532 and can be viewed by parties authorized to access the data (such as auditors or controllers).

[0127] Record 502 illustrates what a user can view when requesting to view transaction data stored in block entry 501. Record 502 may include all or excluding the data portion initially entered in block entry 501, and is generated based on the authorization provided by the requesting user and the access level associated with each data portion.

[0128] Figure 6 A flowchart illustrating an implementation of a customized view for parking facility 400 business operations and customer use, used to generate restricted transactions recorded in the blockchain, is provided. Some or all of the steps in the view customization process 600 can be implemented as program instructions within the context of one or more components of the application used to execute the customized view features.

[0129] In operation, data platform 510 receives block entry 501 to be maintained in blocks 530-532 (step 601). Block entry 501 is requested by a user from a user device in a distributed node network and contains a data portion. Data platform 510 then authorizes the entry (e.g., a miner verifies the hash in the block) (step 602). If the block is not verified, the transaction (block entry 501) is rejected (step 603). However, if the block is accepted, the access level of each data portion is evaluated, and each data portion is added to a block in each of blockchains 530-532 based on the identified access level (step 604).

[0130] In the next operation, data platform 510 receives a request to view one or more data portions of a block entry, wherein the request includes an access code associated with at least one access level (step 605). The access code may be associated with a public, permitted, or private access level. Data platform 510 then evaluates the access code in the request using each of blockchains 530-532, each of which maintains a separate block record for each data portion (step 606). If it is determined that the access code associated with the requesting user is public, a customized view (e.g., record 502) is generated for the requesting user indicating only the parking space from block entry 501 (step 607). If it is determined that the access code associated with the requesting user is permitted, a customized view is generated for the requesting user indicating the parking space and fees from block entry 501 (step 608). If it is determined that the access code associated with the requesting user is private, a customized view is generated for the requesting user indicating all data portions (i.e., parking spaces, customers, and fees) from block entry 501 (step 609).

[0131] In some implementations, block entry 501 also records additional data related to parking facility transactions, such as the location from which the customer initiated the transaction and the parking facility 400 involved, the time and date stamps of the transaction and vehicle entry and exit from facility 400, and photos and / or videos of the vehicle entering, leaving, and moving near facility 400. In one example, in addition to being stored in block entry 501, such imaging may also include live streaming to a security monitoring station located at or away from parking facility 400. Additionally or alternatively, in garages or parking facilities / parking lots, as a security measure, cameras may monitor the movement of vehicles in parking facility 400, and as a security measure, cameras may store this data in block entry 501 and / or elsewhere. For security purposes, these imaging systems may be integrated into or co-located with sensor 418. For example, a motion monitoring and imaging security protocol may be initiated if a parked vehicle exhibits movement outside of the expected timetable for the vehicle's stay at parking facility 400.

[0132] Figure 7 This illustration shows a block graph 700 in an implementation of an enhanced application used for hotel business operations and transactions including payment processing, to generate a customized view of restricted transactions recorded in the blockchain. Block graph 700 includes inventory block entries 701, a data platform 710, servers 720-722, blockchains 730-732, and records 702.

[0133] Block entry 701 represents any data transaction that will be permanently recorded to the blockchain, such as data received and recorded from hotel guests, connected devices, the hotel, operators and staff, and external sources (e.g., key card readers, loyalty cards, etc.). Block entry 701 is then processed by miners and added to the end of the blockchain as a block via data platform 710. Block entry 701 also includes data portions already represented herein by hotel rooms, hotel guests, and room fees. Hotel rooms maintain the inventory and availability status of hotel rooms in the hotel. Hotel guests include data associated with the identities of guests who have registered hotel rooms under their names, as well as identifiers of other guests who may also be associated with registered guests, and their account and payment-related data. Room fees include data specifying the cost of staying in a hotel room, including per night. It should be noted that although each of the data portions is represented separately, the data portion is part of a transaction represented by block entry 701. Block entry 701 may include any transactions or contracts that have been executed and recorded in the distributed ledger platform environment for the purpose of hotel operations. In this example, block entry 701 may include a customer's order, reservation, or spontaneous purchase request for the use of a hotel room or related goods or services in the hotel. In some implementations, the token may alternatively or in lieu of one or more of a customer's order, reservation, or spontaneous purchase request for the use of a hotel room or related goods or services in the hotel.

[0134] Data platform 710 refers to any one or more computing systems capable of hosting blockchain applications, in which Figure 28 The controller 2800 is representative. The data platform 710 provides a secure distributed ledger system for recording hotel transactions and room availability status in a blockchain. The data platform 710 can be implemented on numerous distributed network nodes, accessible to a wide variety of users such as tax auditors, financial institutions, regulatory authorities, guests and other hotel customers, hotel employees, hotel owners, hotel auditors, managers and staff, marketing companies, advertisers, etc.

[0135] Data platform 710 may also include servers 720-722. Servers 720-722 may represent any one or more computing systems to which distributed network nodes can communicate. Examples include other devices on which corresponding applications or services are installed, enabling user devices to transmit transactions to be added to the blockchain and distributed among network nodes in the distributed network. Examples include media servers, web servers, and other types of endpoints that can transmit or receive transaction data to or from user devices and network nodes using communication protocols including, but not limited to, 5G, Wi-Fi, NFC, Miracast, etc. Hotel room key card readers, loyalty card receivers, and other useful devices and subsystems including sensors and access control or payment processing devices and systems can automatically transmit transaction or business operation data to network nodes, as referenced above. Figure 3 As described. In some implementations, the data platform 710 can dynamically select which servers 720-722 are authorized to store data. For example, a company or government may have geographical restrictions, encryption standards, cybersecurity standards, or other restrictions on the server nodes storing the blockchain. Therefore, the data platform 710 can manage the logistics of dynamically selected servers based on these restrictions. For example, if a particular server is deemed to be under attack or illegally accessed, the data platform 710 can dynamically remove that server from the blockchain network and consider adding one or more additional servers if necessary. In this way, each data owner can set selection criteria for where the data should be stored and the minimum IT standards required for that group of servers.

[0136] Block diagram 700 also includes blockchains 730-732. Blockchains 730-732 can contain a continuously growing list of records—called blocks—that are linked and protected using cryptography. Each block in blockchains 730-732 contains a timestamp and a hash. The hash consists of both the cryptographic hash of the current block and the cryptographic hash of the previous block in the blockchain. Each block also contains data associated with the block entry. In this example scenario, each data component (room, guest, and fee) has been recorded separately in different blocks and in separate blockchains 730-732.

[0137] Furthermore, each of blockchains 730-732 is associated with a separate access level. For example, blockchain 730 is a public access blockchain, which allows any user interacting with the distributed ledger to view the blocks and the data portions stored in each block. A public user could be any user interested in viewing hotel rooms in one or more hotels available for transaction in blockchain 730, and there is no privacy for this data portion. Conversely, blockchain 731 is a private blockchain where the data portions can only be accessed and viewed by authorized users, such as internal company personnel. In this example scenario, guests have been stored separately on blockchain 731, and it is private to all users interacting in the blockchain network except for users with exclusive access to the data (such as managers within the company initiating the transaction). Blockchain 732 is a permissioned blockchain, meaning that a limited set of parties, but not all users, can view the data portions recorded in the blocks. Fees are stored within blockchain 732 and can be viewed by parties authorized to access the data (such as auditors or controllers).

[0138] Record 702 illustrates what a user can view when requesting to view transaction data stored in block entry 701. Record 702 may include all or no of the data portions initially entered into block entry 701, and is generated based on the authorization provided by the requesting user and the access level associated with each data portion.

[0139] Figure 8 A flowchart illustrating an implementation of a custom view used for hotel business operations and guest use to generate restricted transactions recorded in a blockchain is provided. Some or all of the steps in the view customization process 800 can be implemented as program instructions within the context of one or more components of the application used to execute the custom view features.

[0140] In operation, data platform 710 receives block entry 701 to be maintained in blocks 730-732 (step 801). Block entry 701 is requested by a user from a user device in a distributed node network and contains a data portion. Data platform 710 then authorizes the entry (e.g., miners verify the hash in the block) (step 802). If the block is not verified, the transaction (block entry 701) is rejected (step 803). However, if the block is accepted, the access level of each data portion is evaluated, and each data portion is added to a block in each of blockchains 730-732 based on the identified access level (step 804).

[0141] In the next operation, data platform 710 receives a request to view one or more data portions of a block entry, wherein the request includes an access code associated with at least one access level (step 805). The access code may be associated with a public, permitted, or private access level. Data platform 710 then evaluates the access code in the request using each of blockchains 730-732, each of which maintains a separate block record for each data portion (step 806). If it is determined that the access code associated with the requesting user is public, a customized view (e.g., record 702) is generated for the requesting user indicating only the room from block entry 701 (step 807). If it is determined that the access code associated with the requesting user is permitted, a customized view is generated for the requesting user indicating the room and fees from block entry 701 (step 808). If it is determined that the access code associated with the requesting user is private, a customized view is generated for the requesting user indicating all data portions (i.e., rooms, guests, and fees) from block entry 701 (step 809).

[0142] In some implementations, block entry 701 also records additional data related to hotel room transactions, such as the location from which the customer initiated the transaction and the hotel building involved, the time and date stamps of the transaction and the guest's and / or vehicle's entry and exit from the hotel, and photos and / or videos of the guest and / or vehicle entering, leaving, and moving around the hotel. In one example, in addition to being stored in block entry 701, such imaging may also include live streaming to security monitoring stations located at or away from the hotel building. Additionally or alternatively, for the benefit of guests and hotel staff, as a security measure, cameras may monitor the movement of guests and / or their vehicles in and around the hotel, and as a security measure, cameras may store this data in block entry 701 and / or elsewhere. For security purposes, these imaging systems may be integrated into devices such as room key readers and access points for parking, swimming pools, fitness centers, casinos, and other hotel facilities, or co-located with said devices and said access points. For example, a motion surveillance and imaging security protocol can be initiated if someone other than a registered guest attempts to gain access to a guest room or other areas of the hotel intended for use only by registered hotel guests.

[0143] Figure 9 This illustrates block graph 900 in an implementation of an enhanced application for autonomous vehicle fleet operations and transactions, including payment processing, to generate a customized view of restricted transactions recorded in a blockchain. Block graph 900 includes inventory block entries 901, a data platform 910, servers 920-922, blockchains 930-932, and records 902.

[0144] Block entry 901 represents any data transaction that will be permanently recorded to the blockchain, such as data received and recorded from passengers requesting a ride, connected devices, autonomous vehicle fleet managers and staff, and external sources (e.g., GPS transceivers, keychains, loyalty cards, etc.). Block entry 901 is then processed by miners and added to the end of the blockchain as a block via data platform 910. Block entry 901 also includes data portions already represented herein by vehicle IDs, passengers, and ride prices or fees. Vehicle IDs maintain the inventory and availability status of autonomous vehicles in a geographic area. Passengers include data associated with an identifier of the passenger requesting the autonomous vehicle by their name, as well as their account and payment-related data. In some implementations, passengers also include data identifying the passenger's requested destination. Fees include data specifying the cost for the passenger to utilize the autonomous vehicle. In some implementations, the fee to be charged is based on miles from the passenger's current location to the requested destination. It should be noted that while each of the data portions is represented separately, the data portion is part of a transaction represented by block entry 901. Block entry 901 may include any transaction or contract that has been executed and recorded in the distributed ledger platform environment for the purpose of operating an autonomous vehicle fleet. In this example, block entry 901 may include a passenger's order, reservation, or ride hailing request for using an autonomous vehicle or the related services of an autonomous vehicle fleet operator. In some implementations, the token may alternatively or in lieu of one or more of the passenger's order, reservation, or ride hailing request for using an autonomous vehicle or the related services of an autonomous vehicle fleet operator.

[0145] Data platform 910 refers to any one or more computing systems capable of hosting blockchain applications, in which Figure 28 The controller 2800 in the example is representative. The data platform 910 provides a secure distributed ledger system for recording autonomous vehicle fleet transactions, as well as the location and availability status of autonomous vehicles, into a blockchain. The data platform 910 can be implemented across numerous distributed network nodes, accessible to a wide variety of users such as tax auditors, financial institutions, regulatory authorities, passengers and other autonomous vehicle fleet customers or service providers, fleet employees, fleet owners, fleet auditors, managers and staff, marketing companies, advertisers, etc.

[0146] Data platform 910 may also include servers 920-922. Servers 920-922 may represent any one or more computing systems to which distributed network nodes can communicate. Examples include other devices on which corresponding applications or services are installed, enabling user devices to transmit transactions to be added to the blockchain and distributed among network nodes in the distributed network. Examples include media servers, web servers, and other types of endpoints that can transmit or receive transaction data to or from user devices and network nodes using communication protocols including, but not limited to, 5G, Wi-Fi, NFC, Miracast, etc. Vehicle keychains, key card readers, loyalty card receivers, and other useful devices and subsystems including location (e.g., GPS) sensors and access control or payment processing devices and systems can automatically transmit transaction or business operation data to network nodes, as referenced above. Figure 3 As described.

[0147] In some implementations, the data platform 910 can dynamically select which servers 920-922 are authorized to store data. For example, a company or government may impose geographical, encryption, cybersecurity, or other restrictions on the server nodes storing the blockchain. Therefore, the data platform 910 can manage the logistics of dynamically selected servers based on these restrictions. For instance, if a particular server is deemed compromised or illegally accessed, the data platform 910 can dynamically remove that server from the blockchain network and consider adding one or more additional servers if necessary. In this way, each data owner can set selection criteria for where the data should be stored and the minimum IT standards required for that group of servers.

[0148] Block Graph 900 also includes blockchains 930-932. Blockchains 930-932 can contain a continuously growing list of records—called blocks—that are linked and protected using cryptography. Each block in blockchains 930-932 contains a timestamp and a hash. The hash consists of both the cryptographic hash of the current block and the cryptographic hash of the previous block in the blockchain. Each block also contains data associated with the block entry. In this example scenario, each data component (vehicle, passengers, and fare) has been recorded separately in different blocks and in separate blockchains 930-932.

[0149] Furthermore, each of Blockchains 930-932 is associated with a separate access level. For example, Blockchain 930 is a public access blockchain, allowing any user interacting with the distributed ledger to view blocks and portions of data stored within each block. For instance, a public user could be any user interested in viewing the current location of autonomous vehicles in a fleet of currently available ride-hailing vehicles that are available for transactions in Blockchain 930, as well as any usage restrictions a particular vehicle might have at any given time, and there is no privacy associated with this data portion. Conversely, Blockchain 931 is a private blockchain where data portions can only be accessed and viewed by authorized users, such as internal company personnel. In this example scenario, passengers are stored separately on Blockchain 931 and are private to all users interacting within the blockchain network except for those with exclusive access to the data (such as a manager within the company initiating the transaction). Blockchain 932 is a permissioned blockchain, meaning that a limited set of parties, but not all, can view portions of data recorded in blocks. Fees are stored within Blockchain 932 and can be viewed by parties authorized to access the data (such as censors or controllers).

[0150] Record 902 illustrates what a user can view when requesting to view transaction data stored in block entry 901. Record 902 may include all or no of the data portions initially entered into block entry 901, and is generated based on the authorization provided by the requesting user and the access level associated with each data portion.

[0151] Figure 10 A flowchart illustrating an implementation of a customized view for generating restricted transactions recorded in a blockchain, used in the business operations of an autonomous vehicle fleet and for customer use. Some or all of the steps in the view customization process 1000 can be implemented as program instructions within the context of one or more components of the application used to execute the customized view features.

[0152] In operation, data platform 910 receives block entry 901 to be maintained in blocks 930-932 (step 1001). Block entry 901 is requested by a user from a user device in a distributed node network and contains a data portion. Data platform 910 then authorizes the entry (e.g., a miner verifies the hash in the block) (step 1002). If the block is not verified, the transaction (block entry 901) is rejected (step 1003). However, if the block is accepted, the access level of each data portion is evaluated, and each data portion is added to a block in each of blockchains 930-932 based on the identified access level (step 1004).

[0153] In the next operation, data platform 910 receives a request to view one or more data portions of a block entry, wherein the request includes an access code associated with at least one access level (step 1005). The access code may be associated with a public, permitted, or private access level. Data platform 910 then evaluates the access code in the request using each of blockchains 930-932, each maintained for each individual block record for each data portion (step 1006). If it is determined that the access code associated with the requesting user is public, a customized view (e.g., record 902) is generated for the requesting user indicating only the vehicle from block entry 901 (step 1007). If it is determined that the access code associated with the requesting user is permitted, a customized view is generated for the requesting user indicating the vehicle and fare from block entry 901 (step 1008). If it is determined that the access code associated with the requesting user is private, a customized view is generated for the requesting user indicating all data portions (i.e., vehicle, passenger, and fare) from block entry 901 (step 1009).

[0154] In some implementations, block entry 901 also records additional data related to autonomous vehicle fleet transactions, such as time and date stamps of passengers entering and leaving the corresponding vehicles from their transaction initiation location and the vehicles involved, the transaction and passenger and / or their assigned vehicle IDs, as well as photos and / or videos of passengers entering, leaving, and being transported by the assigned autonomous vehicles. In one example, in addition to being stored in block entry 901, such imaging may also include live streaming from security monitoring stations located at or away from the autonomous vehicle fleet's building or facility. Additionally or alternatively, for the benefit of passengers and fleet staff members, as a safety measure, cameras may monitor the movement of autonomous vehicles carrying passengers en route to the passengers' destination, and as a safety measure, cameras may store this data in block entry 901 and / or elsewhere. For safety purposes, these imaging systems may be useful in the event of vehicle accidents or other incidents involving passengers or assigned autonomous vehicles. In such cases, customized views can be provided to police or insurance investigators to offer useful data for resolving post-incident issues.

[0155] Figure 11 Block graph 1100 is illustrated in an implementation of an enhanced application used to generate a custom view of restricted transactions recorded in a blockchain. Block graph 1100 includes inventory block entries 1101, a data platform 1110, servers 1120-1122, blockchains 1130-1132, and records 1102.

[0156] Block entry 1101 represents any data transaction that will be permanently recorded in the blockchain. Block entry 1101 is then processed by miners and added to a block at the end of the blockchain via data platform 1110. Block entry 1101 also includes data portions already represented in this document by product, buyer, and price. It should be noted that although each of the data portions is represented individually, the data portion is part of a transaction represented by block entry 1101. Block entry 1101 can include any transaction or contract that has already been executed and recorded in the distributed ledger platform environment. In this example, block entry 1101 could include a purchase order for inventory.

[0157] Data platform 1110 refers to any one or more computing systems capable of hosting blockchain applications, in which Figure 28 The controller 2800 in the example is representative. Data platform 1110 provides a secure distributed ledger system for recording transactions into a blockchain. Data platform 1110 can be implemented on numerous distributed network nodes, accessible to a wide variety of users such as tax auditors, financial institutions, game regulatory committees, customers, company employees, etc.

[0158] Data platform 1110 may also include servers 1120-1122. Servers 1120-1122 can represent any one or more computing systems that distributed network nodes can communicate with. Examples include other devices on which corresponding applications or services are installed, enabling user devices to transmit transactions to be added to the blockchain and distributed among network nodes in the distributed network. Examples include media servers, web servers, and other types of endpoints that can transmit or receive transaction data to or from user devices and network nodes. In some implementations, the data platform can dynamically select which servers 1120-1122 are authorized to store data. For example, a company or government may impose geographical, encryption, cybersecurity, or other restrictions on the server nodes storing the blockchain. Therefore, data platform 1110 can manage the logistics of dynamically selected servers based on these restrictions. For example, if a particular server is deemed to be under attack or illegally accessed, data platform 1110 can dynamically remove that server from the blockchain network and consider adding one or more additional servers if necessary. In this way, each data owner can set selection criteria for where the data should be stored and the minimum IT standards required for that server group.

[0159] Block diagram 1100 also includes blockchains 1130-1132. Blockchains 1130-1132 can contain a continuously growing list of records—called blocks—that are linked and protected using cryptography. Each block in blockchains 1130-1132 contains a timestamp and a hash. The hash consists of both the cryptographic hash of the current block and the cryptographic hash of the previous block in the blockchain. Each block also contains data associated with the block entry. In this example scenario, each data component (product, buyer, and price) has been recorded separately in different blocks and in separate blockchains 1130-1132.

[0160] Furthermore, each of blockchains 1130-1132 is associated with a separate access level. For example, blockchain 1130 is a public access blockchain, which allows any user interacting with the distributed ledger to view the blocks and the data portions stored in each block. Public users can be any user interested in viewing transactions in blockchain 1130, and there is no privacy regarding this data portion. Conversely, blockchain 1131 is a private blockchain where the data portions can only be accessed and viewed by authorized users, such as internal company personnel. In this example scenario, the buyer has been stored separately on blockchain 1131 and is private to all users interacting in the blockchain network except for users with exclusive access to the data (such as a manager within the company initiating the transaction). Blockchain 1132 is a permissioned blockchain, meaning that a limited set of parties, but not all users, can view the data portions recorded in the blocks. The price has been stored within blockchain 1132 and can be viewed by parties authorized to access the data (such as censors or controllers).

[0161] Record 1102 illustrates what a user can view when requesting to view transaction data stored in block entry 1101. Record 1102 may include all or no of the data portions initially entered into block entry 1101, and is generated based on the authorization provided by the requesting user and the access level associated with each data portion.

[0162] Figure 12 A flowchart illustrating an implementation of a custom view for generating restricted transactions recorded in a blockchain is provided. Some or all of the steps in the view customization process 1200 can be implemented as program instructions within the context of one or more components of the application used to execute the custom view features.

[0163] In operation, data platform 1110 receives block entry 1101 to be maintained in blocks 1130-1132 (step 1201). Block entry 1101 is requested by a user from a user device in a distributed node network and contains a data portion. Data platform 1110 then authorizes the entry (e.g., a miner verifies the hash in the block) (step 1202). If the block is not verified, the transaction (block entry 1101) is rejected (step 1203). However, if the block is accepted, the access level of each data portion is evaluated, and each data portion is added to a block in each of blockchains 1130-1132 based on the identified access level (step 1204).

[0164] In the next operation, data platform 1110 receives a request to view one or more data portions of a block entry, wherein the request includes an access code associated with at least one access level (step 1205). The access code may be associated with a public, permitted, or private access level. Data platform 1110 then evaluates the access code in the request using each of blockchains 1130-1132, each of which maintains a separate block record for each data portion (step 1206). If it is determined that the access code associated with the requesting user is public, a customized view (e.g., record 1102) indicating only the product from block entry 1101 is generated for the requesting user (step 1207). If it is determined that the access code associated with the requesting user is permitted, a customized view indicating the product and price from block entry 1101 is generated for the requesting user (step 1208). If it is determined that the access code associated with the requesting user is private, a custom view will be generated for the requesting user that indicates all data portions (i.e., product, buyer, and price) from block entry 1101 (step 1209).

[0165] Another implementation of flowchart 1200 could be within the context of a competition verification process. For example, a user betting on a high threshold might require approval from the casino manager. In this example scenario, when a bet is placed, access to the user's data in the blockchain might be required to ensure that the casino manager has approved the bet for the user.

[0166] Figure 13 This illustrates a block graph in an alternative implementation of an enhanced application used to generate a custom view of restricted transactions recorded in the blockchain. Block graph 1300 includes game input block entries 1301, data platform 1310, servers 1320-1322, blockchain 1330, access platform 1340, and record 1302.

[0167] Block entry 1301 represents any data transaction that will be permanently recorded in the blockchain. Block entry 1301 is then processed by miners and added to the end of the blockchain as a block via data platform 1310. Block entry 1301 also includes data portions represented herein by the amount invested, credit card number, and age. It should be noted that although each of the data portions is represented individually, the data portion is part of a transaction represented by block entry 1301. Block entry 1301 can include any transaction or contract that has already been executed and recorded in the distributed ledger platform environment. However, in this example, block entry 1301 includes contest investments. It should also be noted that while a requesting user (such as a third-party observer who is not a direct participant in the investment) may be able to view some data in blockchain 1330, viewing block entry 1301 may require an access code. The access code may be in the form of biometric verification.

[0168] Data platform 1310 refers to any one or more computing systems capable of hosting blockchain applications, in which Figure 28 The controller 2800 is representative. The data platform 1310 provides a secure distributed ledger system for recording transactions into a blockchain. The data platform 1310 can be implemented on numerous distributed network nodes, accessible to a wide variety of users such as auditors, financial institutions, game regulatory committees, customers, company employees, etc.

[0169] Data platform 1310 also includes servers 1320-1322. Servers 1320-1322 can represent any one or more computing systems that distributed network nodes can communicate with. Examples include other devices on which corresponding applications or services are installed, enabling users of user devices to transmit transactions to be added to the blockchain and distributed among network nodes in the distributed network. Examples include media servers, web servers, and other types of endpoints that can transmit or receive transaction data to or from user devices and network nodes.

[0170] Block diagram 1300 also includes blockchain 1330. Blockchain 1330 contains a continuously growing list of records—called blocks—that are linked and protected using cryptography. Each block in blockchain 1330 contains a timestamp and a hash. The hash consists of both the cryptographic hash of the current block and the cryptographic hash of the previous block in the blockchain. Each block also contains data associated with the block entry. In this example scenario, each data component (investment amount, credit card number, and age) has been recorded in blockchain 1330 with a separate cryptographic code.

[0171] Furthermore, each cryptographic code associated with each data segment in Blockchain 1330 is associated with a separate access level. For example, the amount invested is associated with a public access cryptographic code, which allows any user interacting with the distributed ledger to view the data segment in the block. A public user can be any user interested in viewing the investment amount, and there is no privacy associated with this data segment. Conversely, a credit card number is associated with a private cryptographic code, which can only be accessed and viewed by authorized users, such as those in an internal accounting department. Age is associated with a permissioned cryptographic code, which can be viewed by a limited set of parties, but not all users. For example, a game committee might request to see ages to ensure all players are of legal age to invest in the next competition. However, other players or observers of the investments may not be able to see the age of each player.

[0172] Access platform 1340 refers to any one or more computing systems capable of verifying user requests to access blockchain entry data, where Figure 28 The controller 2800 is representative. Access platform 1340 provides a secure cryptographic intermediary between the data portion recorded in blockchain 1330 and the record 1302 generated for the requesting user. Access platform 1340 can be implemented on numerous distributed network nodes, accessible by a variety of users such as tax auditors, financial institutions, game regulatory committees, customers, company employees, etc. Record 1302 illustrates what a user can view when requesting to view transaction data stored in block entry 1301. Record 1302 may contain all or no of the data portion initially entered into block entry 1301 and is generated based on authorization provided by the requesting user and the access level associated with each data portion.

[0173] Figure 14 A flowchart illustrating an implementation of a custom view for generating restricted transactions recorded in a blockchain is provided. Some or all of the steps in the view customization process 1400 can be implemented as program instructions within the context of one or more components of the application used to execute the custom view features.

[0174] In operation, data platform 1310 receives block entry 1301 to be maintained in the blocks of blockchain 1330 (step 1401). Block entry 1301 is requested by the user from the user device in the distributed node network and contains a data portion. Data platform 1310 then authorizes the entry (e.g., miners verify the hash in the block) (step 1402). If the block is not verified, the transaction (block entry 1301) is rejected (step 1403). However, if the block is accepted, the access level of each data portion is evaluated, and each data portion is added to blockchain 1330 based on the identified access level (step 1404) along with the cryptographic code added to blockchain 1330 (step 1405).

[0175] In the next operation, data platform 1340 receives a request to view one or more data portions of a block entry, wherein the request includes an encryption code associated with at least one access level (step 1406). The encryption code may be associated with a public, permitted, or private access level. Data platform 1340 then evaluates the encryption code in the request for each data portion in blockchain 1330 (step 1407). If it is determined that the encryption code associated with the requesting user is public, a customized view (e.g., record 1302) indicating only the amount invested from block entry 1301 is generated for the requesting user (step 1408). If it is determined that the encryption code associated with the requesting user is permitted, a customized view indicating the amount invested and age from block entry 1301 is generated for the requesting user (step 1409). If it is determined that the encryption code associated with the requesting user is private, a customized view indicating all data portions from block entry 1301 (i.e., amount invested, credit card number, and age) is generated for the requesting user (step 1410).

[0176] Figure 15 This illustrates a block graph in an alternative implementation of an enhanced application used to generate a custom view of restricted transactions recorded in the blockchain. Block graph 1500 includes currency transfer block entry 1501, data platform 1500, servers 1520-1522, blockchain 1530, access platform 1540, and record 1502.

[0177] Block entry 1501 represents any data transaction that will be permanently recorded in the blockchain. Block entry 1501 is then processed by miners and added to the end of the blockchain as a block via data platform 1510. Block entry 1501 also includes data portions that have already been represented in this document by the transaction parties, bank account numbers, and available funds. It should be noted that although each of the data portions is represented individually, the data portion is part of a transaction represented by block entry 1501. Block entry 1501 can include any transaction or contract that has already been executed and recorded in the distributed ledger platform environment. However, in this example, block entry 1501 includes a banking transaction that transfers money from one user's bank account to another user's bank account.

[0178] Data platform 1510 refers to any one or more computing systems capable of hosting blockchain applications, in which Figure 28 The controller 2800 is representative. The data platform 1510 provides a secure distributed ledger system for recording transactions into a blockchain. The data platform 1510 can be implemented on numerous distributed network nodes, accessible to a wide variety of users such as tax auditors, financial institutions, game regulatory committees, customers, company employees, etc.

[0179] Data platform 1510 also includes servers 1520-1522. Servers 1520-1522 can represent any one or more computing systems that distributed network nodes can communicate with. Examples include other devices on which corresponding applications or services are installed, enabling user devices to transmit transactions to be added to the blockchain and distributed among network nodes in the distributed network. Examples include media servers, web servers, and other types of endpoints that can transmit or receive transaction data to or from user devices and network nodes.

[0180] Block Graph 1500 also includes Blockchain 1530. Blockchain 1530 contains a continuously growing list of records—called blocks—that are linked and protected using cryptography. Each block in Blockchain 1530 contains a timestamp and a hash. The hash consists of both the cryptographic hash of the current block and the cryptographic hash of the previous block in the blockchain. Each block also contains data associated with the block entry. In this example scenario, each data component (party, account number, and available funds) has been recorded in Blockchain 1530 with a separate access level tag.

[0181] Furthermore, each access level token associated with each data segment in Blockchain 1530 is linked to a separate access level. For example, parties are associated with a public access token, which allows any user interacting with the distributed ledger to view the data segment within a block. A public user can be any user interested in viewing the transaction parties, and there is no privacy associated with this data segment. Conversely, account numbers are associated with private access tokens, which can be accessed and viewed only by authorized users, such as the transferring bank for each party. Available funds are associated with a permitted access token, which can be viewed by a limited set of parties, but not all users. For example, a receiving bank might request to see available funds to ensure there are funds available in the transferring account to complete a monetary transaction.

[0182] Access platform 1540 refers to any one or more computing systems capable of verifying user requests to access blockchain entry data, where Figure 28 The controller 2800 is representative. Access platform 1540 provides a secure access token intermediary between the data portion recorded in blockchain 1530 and the record 1502 generated for the requesting user. Access platform 1540 can be implemented on numerous distributed network nodes, accessible by a variety of users such as tax auditors, financial institutions, game regulatory committees, customers, company employees, etc. Record 1502 illustrates what a user can view when requesting to view transaction data stored in block entry 1501. Record 1502 may contain all or no of the data portion initially entered into block entry 1501 and is generated based on authorization provided by the requesting user and the access level associated with each data portion.

[0183] Figure 16 A flowchart illustrating an implementation of a custom view for generating restricted transactions recorded in a blockchain is provided. Some or all of the steps in the view customization process 1600 can be implemented as program instructions within the context of one or more components of the application used to execute the custom view features.

[0184] In operation, data platform 1510 receives block entry 1501 to be maintained in the blocks of blockchain 1530 (step 1601). Block entry 1501 is requested by a user from a user device in a distributed node network and contains a data portion. Data platform 1510 then authorizes the entry (e.g., a miner verifies the hash in the block) (step 1602). If the block is not verified, the transaction (block entry 1501) is rejected (step 1603). However, if the block is accepted, the access level of each data portion is evaluated, and each data portion is added to blockchain 1530 based on the identified access level (step 1604) along with an access token added to blockchain 1530 (step 1605).

[0185] In the next operation, access platform 1540 receives a request to view one or more data portions of a block entry, wherein the request includes an access code associated with at least one access level (step 1606). This access code may be associated with a public, permitted, or private access level. Access platform 1540 then evaluates the access code in the request for each data portion in blockchain 1530 (step 1607). If it is determined that the access code associated with the requesting user is public, a customized view (e.g., record 1502) is generated for the requesting user that indicates only the parties from block entry 1501 (step 1608). If it is determined that the access code associated with the requesting user is permitted, a customized view is generated for the requesting user that indicates the parties from block entry 1501 and available funds (step 1609). If it is determined that the access code associated with the requesting user is private, a customized view is generated for the requesting user that indicates all data portions from block entry 1501 (i.e., parties, account numbers, and available funds) (step 1610).

[0186] Figure 17 An exemplary operational architecture 1700 is illustrated in one implementation of a financial audit scenario used to generate a customized view of restricted transactions recorded in a blockchain. In this operation, user 1710 transfers salary 1730 to user 1720 in exchange for services. A transaction record indicating the service name and cost is transmitted from user 1710 to database 1740. This record is then maintained in blockchain 1760 via server 1750. It should be noted that in this scenario, the transaction is also recorded by user 1720 on the receiving end, where transaction records indicating profits and services are transmitted to database 1742 and maintained in blockchain 1760 via server 1750.

[0187] In the next operation, government tax auditor 1770 requests to view the profits recorded for user 1720. User 1770 may not be authorized to view the services recorded in the record or the fees from user 1710. Server 1750 can receive the request and process an access code indicating that at this point in time user 1770 is only authorized to view user 1720's profits. Server 1750 then generates a customized view of the record for user 1770 that only indicates user 1720's profits. Although user 1770 cannot see the complete record of transactions, user 1770 can trust that the portion of the record indicating user 1720's profits is valid because it has been maintained in blockchain 1760.

[0188] Figure 18 An alternative operational architecture 1800 is illustrated in one implementation of a parking customer account and transaction tracking scenario for generating a customized view of restricted transactions recorded in the blockchain. In this operation, users 1810 who log into their accounts on a smartphone application submit information about... Figure 4 An inquiry 1830 is made regarding whether there are parking spaces available for vehicle 1820 in parking facility 400. User 1810 enters their estimated arrival time at entrance 402 of parking facility 400 and the estimated time they will need to park their vehicle 1820. Based on the customer's account data, for example, the application associates vehicle 1820 with its license plate number. Records of the estimated entry and exit times and vehicle 1820's license plate number are transmitted from user 1810 to database 1840, indicating the predicted duration of the parking transaction. This record is then maintained in blockchain 1860 via server 1850. It should be noted that in this scenario, the arrival time transaction for vehicle 1820 is also recorded by user 1880 on the receiving end, where transaction records indicating the estimated and actual arrival times of vehicle 1820 are transmitted to database 1842 and maintained in blockchain 1860 via server 1850. In some implementations, if the actual arrival time of vehicle 1820 occurs after a predetermined threshold time (e.g., 5 minutes) following the expected arrival time of vehicle 1820, user 1810 must re-initiate an inquiry to be assigned any available parking space in parking facility 400.

[0189] In the next operation, another parking customer, such as user 1870, requests to view the departure and arrival times of vehicle 1820 parked in user 1870's preferred parking space. User 1870 may not be authorized to view vehicle 1820's license plate number. Server 1850 can receive this request and process it, indicating that at this point in time, user 1870 is only authorized to view the predicted duration and available parking spaces recorded for vehicle 1820 and parking facility 400, respectively. Server 1850 then generates a customized view of the records for user 1870, which only indicates the predicted duration and available parking spaces.

[0190] Figure 19 An alternative operational architecture 1900 is illustrated in one implementation of a hotel guest account and transaction tracking scenario used to generate a customized view of restricted transactions recorded in the blockchain. In this operation, a guest 1910, logged into their account on a smartphone application, submits an inquiry 1930 regarding room availability at hotel 1920. Guest 1910 enters their desired check-in dates at hotel 1920 and the number of nights they intend to stay at hotel 1920. Based on the customer's account data, for example, the application associates the length of stay data with the name of the guest who made the inquiry 1930. Records of check-in times and the number of nights stayed at hotel 1920 are transmitted from guest 1910 to database 1940. This record is then maintained in blockchain 1960 via server 1950. It should be noted that in this scenario, the check-in time transaction for Hotel 1920 is also recorded on the receiving end by User 1980, wherein the transaction record indicating the expected and actual arrival times of Guest 1910 at Hotel 1920 is transmitted to Database 1942 and maintained in Blockchain 1960 via Server 1950. In some implementations, if the actual check-in time at Hotel 1920 occurs after a predetermined threshold time (e.g., 18 hours) following the expected arrival time at Hotel 1920, Guest 1910 must re-initiate an inquiry 1930 to be assigned any available hotel room at Hotel 1920.

[0191] In the next operation, another hotel customer, such as guest 1970, requests to view the departure date and time of a room in hotel 1920 currently occupied by guest 1910 but preferred by guest 1970. Guest 1970 may not be authorized to view guest 1910's name. Server 1950 can receive this request and process it, indicating that at this point in time, guest 1970 is only authorized to view the predicted check-out date and time, as well as the access codes for other available rooms in hotel 1920. Server 1950 then generates a custom view of the record for guest 1970 that only indicates this data and not guest 1910's name. Figure 20An alternative operational architecture 2000 is illustrated in one implementation of a scenario involving passenger accounts and transaction tracking for an autonomous vehicle fleet, used to generate a customized view of restricted transactions recorded in the blockchain. In this operation, a passenger 2010, logged into their account on a smartphone application, submits an inquiry 2030 regarding whether the fleet 2032 has autonomous vehicles 2020 available for a ride at a specified time to their desired destination. The passenger 2010 enters their desired pick-up date and time at a designated location provided by the autonomous vehicle fleet 2032, along with their requested destination. Based on the customer's account data, for example, the application associates the ride request-related data with the name of the passenger making the inquiry 2030. This ride request data record is transmitted from the passenger 2010 to a database 2040. This record is then maintained in the blockchain 2060 via a server 2050. It should be noted that in this scenario, the ride request data of the autonomous vehicle 2020 is also recorded by the user 2080 on the receiving end of the fleet 2032. The transaction record indicating the requested vehicle 2020, the pick-up time and location, and the passenger 2010's destination is transmitted to the database 2042 and maintained in the blockchain 2060 via the server 2050. In some implementations, if the passenger 2010 does not appear at the pre-arranged pick-up location and a predetermined time period has elapsed (e.g., 10 minutes after the pre-arranged pick-up time), the passenger 2010 must re-initiate an inquiry 2030 to be assigned any available autonomous vehicle 2020 from the fleet 2032.

[0192] In the next operation, another fleet 2032 customer, such as passenger 2070, requests to see the time and date when autonomous vehicle 2020, currently serving passenger 2010 but preferred by passenger 2070, will again be available for rental. Passenger 2070 may not be authorized to view passenger 2010's name. Server 2050 can receive this request and process an access code indicating that at this point in time, passenger 2070 is only authorized to view the predicted availability date and time of vehicle 2020, as well as access codes for other available vehicles in fleet 2032. Server 2050 then generates a custom view of the records for passenger 2070 that only indicates this data and not passenger 2010's name.

[0193] Figure 21An alternative operational architecture 2100 in one implementation of a game regulation scenario is illustrated for generating a customized view of restricted transactions recorded in the blockchain. In this operation, user 2110 signs a sports betting wager 2130 with user 2120. The record of the sports betting wager 2130 is transmitted from the user to database 2140, indicating the prediction team and the driver's license numbers of users 2110 to 2120. This record is then maintained in blockchain 2160 via server 2150. It should be noted that in this scenario, a transaction also initiates a transmission from the sports scoring committee 2132 to database 2142, indicating the official score of the game. The official score of the game is transmitted to database 2142 and maintained in blockchain 2160 via server 2150.

[0194] In the next operation, sports betting management user 2170 can request to view the prediction results and official scores of the game from blockchain 2160. User 2170 may not be authorized to view the driving licenses of each of users 2110-2120. Server 2150 can receive the request and process an access code indicating that at this point in time user 2170 is only authorized to view the prediction results and official scores of each of users 2110-2120. Server 2150 then generates a customized view of the records, which only indicates the prediction results and official scores to user 2170. Although user 2170 cannot see the complete record of the transaction, user 2170 can trust that the portion of the record indicating users 2110-2120 has an archived valid driving license, because this data has been maintained in blockchain 2160.

[0195] Figure 22 An alternative operational architecture 2200 is illustrated in one implementation of an inventory tracking scenario for generating a customized view of restricted transactions recorded in the blockchain. In this operation, user 2210 transfers the goods of package 2230 to user 2220 for delivery to various users—including user 2270 tracking package A. A record of the departure time transaction for the goods of package 2230 is transferred from user 2210 to database 2240, indicating the departure times of packages A and B. This record is then maintained in blockchain 2260 via server 2250. It should be noted that in this scenario, the arrival time transaction for the goods of package 2230 is also recorded by user 2220 at the receiving end, with records of transactions indicating the arrival times of packages A and B being transmitted to database 2242 and maintained in blockchain 2260 via server 2250.

[0196] In the next operation, user 2270, who is tracking package A, requests to view the departure and arrival times recorded for package A. User 2270 may not be authorized to view the departure and arrival times recorded for package B. Server 2250 can receive the request and process an access code indicating that at this point in time, user 2270 is only authorized to view the departure and arrival times recorded for package A. Server 2250 then generates a customized view for user 2270 that only indicates the departure and arrival times recorded for package A.

[0197] Refer again Figure 18 , Figure 22 Inventory tracking scenarios can be implemented in a manner similar to parking facility scenarios or otherwise utilize blockchain and the disclosed systems and methods. In the latter case, the product is a parking space in the parking facility, and the tracked inventory is the number and location of available parking spaces. Where the delivery time of a product or service is important to both the customer and the provider of the product or service, blockchain can be leveraged based on the disclosed systems and methods to improve the efficiency of business operations and customer experience. For example, in Figure 18 In the parking scenarios presented, the predicted duration of a customer's parking request, based on the expected time of entry into and exit from parking facility 400, allows the operator to meet customer needs while effectively utilizing parking space inventory to maximize revenue. For example, in a city where an operator has more than one parking facility, the inventory of those facilities can be utilized to achieve the same purpose. Similarly, for... Figure 22 In inventory tracking scenarios (e.g., retail storage operations with multiple storage locations in a region), the disclosed systems and methods, operators, and their customers can access real-time data on the current location and available quantity of specific products (including when they are in transit), thereby enjoying the resulting increased convenience and sales flow.

[0198] Figure 23 An exemplary custom view of restricted transactions recorded in the blockchain is shown. Figure 23 The system includes computing system 2301, comprising one or more devices capable of running blockchain applications, streaming applications, or executing applications in any other way, either natively or in the context of a web browser. Computing system 2301 may include various hardware and software elements in a supporting architecture suitable for generating customized views of parking transaction records. Figure 28 The example of the controller 2800 illustrates such a representative architecture.

[0199] The computing system 2301 also includes a blockchain application component 2302 capable of maintaining a complete record of blockchain transactions according to the process described herein. The user interface 2303 includes a custom view 2310 that can be generated by the blockchain application component. The user interface 2303 can display, in the custom view 2310, data portions from block entries that the user is authorized to view. Initially, the user may only have access to view the public portions of the block entries (such as license plate numbers of a subset of vehicles parked or planned to be parked at parking facility 400).

[0200] An encrypted code can then be transmitted in the request to view the permitted data portion. Once the computing system 2301 verifies the encrypted code, the permitted data portion can be added to the customized view 2310. The permitted data portion includes the name and portrait image of each customer associated with the vehicles in the subset. However, parking spaces currently occupied by each customer in the subset may remain private, and therefore the user will not be able to view the parking space data in the customized view 2310.

[0201] Figure 24 An alternative exemplary custom view 2400 is shown, illustrating restricted transactions recorded in the blockchain. Figure 24 This includes server node 2401, which stores a copy of blockchain 2402. Blockchain 2402 stores blocks that have been linked using hash codes, such as blocks 2410 and 2412. Each block contains transactions that can be further broken down into data portions. For example, block 2412 is stored... Figure 4 The latest, real-time parking transaction tally 2420 for parking facility 400. Tally 2420 includes each customer's name, each customer's vehicle license plate number, the monthly accumulated amount spent on parking by each customer (or an indication of the parking subscription plan maintained), and an identifier of the parking space in parking facility 400 where the customer's vehicle is currently parked. It should be noted that additional data, such as the monthly accumulated ancillary services used and the amount spent on such services at parking facility 400, may also be included in block 2412.

[0202] In Figure 24In the example usage instance illustrated, one of the customers in billing 2420 (e.g., Mary) is the parking account owner, and the remaining customers shown in billing 2420 are authorized users of Mary's account. In this usage instance, Mary and Ed are divorced ex-spouses, and Mary is responsible for paying all of Ed's parking fees at parking facility 400, for whatever reason. Mary pays parking fees for her daughter Jess, for the purpose of attending college classes near parking facility 400. For each user's access to restricted parking records, checkboxes are included to indicate which data portions can be viewed by each user (e.g., Mary, Ed, and Jess). For example, Mary is using mobile device 2430 to access the monthly cumulative parking transaction history. In this example scenario, Mary is authorized to view the names of the authorized users (Ed and Jess) and the amount used in US dollars for each, as Mary is responsible for paying those amounts to parking facility 400. Mary is also allowed private access to her own and Jess's license plate numbers, usage amounts, and occupied parking space IDs. However, according to Mary and Ed's divorce agreement, Mary may not have any ability to track Ed's whereabouts. Therefore, Mary cannot access Ed's license plate number or the parking space he currently occupies in parking facility 400. As can be seen in the customized view displayed on mobile device 2430, Mary can view authorized data section 2440 and is blocked from viewing unauthorized data section 2441.

[0203] Figure 25 An exemplary custom view of restricted transactions recorded in the blockchain is shown. Figure 25 The system includes computing system 2501, comprising one or more devices capable of running blockchain applications, streaming applications, or executing applications in any other way, either natively or in the context of a web browser. Computing system 2501 may include various hardware and software elements in a supporting architecture suitable for generating customized views of payroll transaction records. Figure 28 The example of the controller 2800 illustrates such a representative architecture.

[0204] The computing system 2501 also includes a blockchain application component 2502 capable of maintaining a complete record of blockchain transactions according to the process described herein. The user interface 2503 includes a custom view 2510 that can be generated by the blockchain application component. The user interface 2503 can display, in the custom view 2510, data portions from block entries that the user is authorized to view. Initially, the user may only have access to view the public portions of the block entries (such as the name of each employee on a payslip).

[0205] An encrypted code can then be sent in the request to view the permitted data portion. Once the computing system 2501 verifies the encrypted code, the permitted data portion can be added to the custom view 2510. The permitted data portion includes each employee's salary and date of birth on the payslip transaction. However, each employee's Social Security number may remain private, and therefore users will not be able to view the Social Security data in the custom view 2510.

[0206] Figure 26 An alternative exemplary custom view of restricted transactions recorded in the blockchain is shown. Figure 26 This includes server node 2601, which stores a copy of blockchain 2602. Blockchain 2602 stores blocks linked using hash codes, such as blocks 2610 and 2612. Each block contains transactions that can be further broken down into data portions. For example, block 2612 stores betting entries 2620 for an online poker game. Betting entry 2620 includes each player's name, the amount bet for each player, the amount of money each player has available for betting, and the player's ranking index. It should be noted that additional data, such as game statistics, win / loss percentages, etc., can also be included in block 2612.

[0207] For each user accessing a betting entry, checkboxes are included to indicate which data sections can be viewed by each user. For example, Sue is accessing poker betting entries using mobile device 2630. In this example scenario, Sue is authorized to view each player's name and betting amount, as names and betting amounts are publicly accessible. Sue is also allowed private access to her own bankroll and ranking. However, Sue does not have access to other players' available bankroll and rankings. As can be seen in the customized view displayed on mobile device 2630, Sue views authorized data section 2640 and is blocked from viewing unauthorized data section 2641.

[0208] Figure 27 This illustrates an alternative operational architecture in one implementation of a data access system capable of providing a customized view of restricted or sensitive data recorded in the blockchain. For example... Figure 27 As illustrated, users 2710A-2710N can use various electronic devices to request access to documents, electronic records, physical locations (e.g., safes, rooms, buildings, areas, etc.), or information. For example, depending on the implementation, users 2710A-2710N can have different access levels, such as granting the user a security investigation to access confidential information (e.g., national or organizational secrets) or restricted areas. Typically, a security investigation (e.g., confidential, secret, top secret, etc.) is insufficient to obtain access to all documents and / or data. Instead, the individual must also have the need to know specific information.

[0209] The request can be submitted to access control framework 2720, which can translate and verify requests from various systems (e.g., applications, key card systems, fingerprint readers, biometric devices, passwords, multi-factor authentication, etc.). Once verified, the access control framework can submit the request to security applicator 2730, which can process the request using various security protocols. For example, the security level of a requested document or location may require additional verification (e.g., passwords and hardware devices, biometrics, location verification, PINs, passwords, etc.). In some implementations, the security application may extract this information from fields or metadata in blocks on the blockchain associated with the data.

[0210] Documents or data 2750A-2750B stored in blockchain 2740 may have different fields or sections that can be accessed by different individuals with different "needs to know" or access levels (e.g., compliance officers versus lower-level company employees, individuals with higher security investigation levels versus individuals with lower security investigation levels, etc.). For example, in some implementations, various editing maps may be stored in the blockchain and applied by document generator 2760 before being presented to users 2710A-2710N. This allows different results to be presented to two users requesting the same document or data.

[0211] As an example, a Freedom of Information (FOIA) request can produce edited documents already deemed publicly available, with individuals conducting security investigations and those with a "need to know" requirement presented with different access levels. Depending on the implementation, an initial request from a user can be received. The system can identify information matching the request and set a timer period (e.g., 30 days) for responding to the request based on the FOIA request. The system can then determine whether each piece of information matching the request has any classification restrictions. If any information is determined to be unrestricted (e.g., without a classification level), the system can respond to the user who made the request with a response including information that requires no further review. This type of feature reduces the workload of government employees and ensures that the timeframe for response is met (e.g., by prioritizing among employees and reassigning review). In some implementations, if sufficient time remains, the system can request human review and approval of the included information before sending it.

[0212] When the system identifies confidential information, it will then assess access and investigation. For example, if the person requesting the data has higher access / investigation authority than the administrator, the information will be automatically sent. If editing is required to comply with a security investigation, the document generator 2760 can apply any necessary edits and / or remove documents that should not be included in the response. While in Figure 27 Not illustrated, but some implementations may include machine learning / artificial intelligence components to review data and / or metadata and identify portions that should not be included.

[0213] Other implementations may involve other types of individuals seeking information about changes (e.g., people seeking information about competitors, banking clients, regulators performing reviews, etc.). Numerous such use cases exist. Furthermore, some implementations may utilize decentralized applications (DApps) with backend code running on a decentralized peer-to-peer network to submit requests, retrieve information from the blockchain, and communicate with other applications (e.g., other DApps).

[0214] The security applicator 2730 can also verify a user's certificate status or security level. User records can be stored on the blockchain 2745. For example, information such as background checks, bank account information, travel information, user-related projects (past and present), family history, medical history, certificates, biometrics, passwords, signatures, etc., can be stored on the user's records. The security applicator 2730 can retrieve this information and utilize it in customized views of generated data or documents.

[0215] Figure 28 A block diagram illustrating an example machine representing a computer systematized host computer system is shown. Controller 2800 can communicate with entities including one or more user 2825 client / terminal devices 2820, user input devices 2805, peripheral devices 2810, optional coprocessor devices (e.g., cryptographic processor devices) 2815, and a network 2830. A user can establish a relationship with controller 2800 via terminal device 2820 through network 2830. In some embodiments, all or part of the communication between terminal device 2820 and controller 2800 can be encrypted. Various laws, standards, or best practices may require cryptography for storing, transmitting, and / or utilizing various types of data, information, codes, signaling, etc.

[0216] A computer may employ a central processing unit (CPU) or processor to process information. A processor may include a programmable general-purpose or special-purpose microprocessor, a programmable controller, an application-specific integrated circuit (ASIC), a programmable logic device (PLD), embedded components, combinations of such devices, etc. The processor executes program components in response to requests generated by the user and / or the system. One or more of these components may be implemented in software, hardware, or both. The processor delivers instructions (e.g., operation and data instructions) to enable various operations.

[0217] The controller 2800 may include a clock 2865, a CPU 2870, memory (such as read-only memory (ROM) 2885 and random access memory (RAM) 2880), and a coprocessor 2875. These controller components can be connected to the system bus 2860 and, through the system bus 2860, to the interface bus 2835. Additionally, user input devices 2805, peripheral devices 2810, coprocessor devices 2815, etc., can be connected to the system bus 2860 via the interface bus 2835. The interface bus 2835 can be connected to various interface adapters, such as a processor interface 2840, an input / output interface (I / O) 2845, a network interface 2850, and a storage interface 2855.

[0218] The processor interface 2840 facilitates communication between the coprocessor device 2815 and the coprocessor 2875. In one implementation, the processor interface 2840 can accelerate the encryption and decryption of requests or data. The input / output interface (I / O) 2845 uses protocols such as those used for handling audio, data, video interfaces, wireless transceivers, etc. (e.g., protocols for audio, data, video interfaces, wireless transceivers, etc.). The controller 2800 uses various communication protocols, including IEEE 894a-b, serial, Universal Serial Bus (USB), Digital Video Interface (DVI), 802.11a / b / g / n / x, and cellular, to facilitate communication between user input devices 2805, peripheral devices 2810, coprocessor devices 2815, and other components. A network interface 2850 can communicate with a network 2830. Through the network 2830, the controller 2800 can be accessible to remote terminal devices 2820. The network interface 2850 can use various wired and wireless connection protocols, such as direct connection, Ethernet, and wireless connections such as IEEE 802.11ax and Miracast. Some components of the interactive gaming system may include various protocols or conform to various standards or certifications proposed by different associations or regulatory authorities. For example, some implementations may use the Time Slot Accounting System (SAS) protocol or conform to the Game-to-System (G2S) standard.

[0219] Examples of network 2830 include the Internet, Local Area Network (LAN), Metropolitan Area Network (MAN), Wide Area Network (WAN), Wireless Network (e.g., using Wireless Application Protocol WAP), secure custom connections, etc. Network interface 2850 may include a firewall that can, in some respects, govern and / or manage permissions for accessing / proxying data within the computer network and track changing trust levels between different machines and / or applications. The firewall can be any number of modules having any combination of hardware and / or software components capable of enforcing a predetermined set of access rights, for example, between a specific set of machines and applications, between machines, and / or between applications, to regulate traffic flows and resource sharing between these changing entities.

[0220] The firewall may additionally manage access control lists and / or have access to such lists, which detail permissions, including, for example, the access and operation rights of individuals, machines, and / or applications to objects, and the circumstances under which those permissions are granted. Other network security functions performed or included in the firewall's functionality without departing from the novel technology of this disclosure may be, for example, but not limited to, intrusion prevention, intrusion detection, next-generation firewalls, personal firewalls, etc. It should be understood that the controller 2800 may be able to use the network interface 2850 to transmit and receive payment amounts. Payments can be made through applications executed by the controller 2800 (such as using...). The National Fighting Club (NFC) application is clickable to drive it. The 2855 can communicate with many storage devices such as the 2890 storage device and removable disk drives. The 2855 storage interface can use various connection protocols, such as Serial Advanced Technology Attachment (SATA), IEEE 894, Ethernet, Fiber optic, Universal Serial Bus (USB), etc.

[0221] User input device 2805 and peripheral device 2810 can be connected to I / O interface 2845 and may be connected to other interfaces, buses, and / or components. User input device 2805 may include card readers, fingerprint readers, joysticks, keyboards, microphones, mice, remote controls, retinal readers, touchscreens, sensors, etc. Peripheral device 2810 may include antennas, audio devices (e.g., microphones, speakers, etc.), cameras, external processors, communication devices, radio frequency identification (RFID) devices, scanners, printers, storage devices, transceivers, etc. Coprocessor device 2815 can be connected to controller 2800 via interface bus 2835 and may include microcontrollers, processors, interfaces, or other devices.

[0222] Computer-executable instructions and data can be stored in processor-accessible memory (e.g., registers, cache memory, random access memory, flash memory, etc.). These stored instruction codes (e.g., programs) can establish relationships between processor components, motherboard, and / or other system components to perform desired operations. Controller 2800 can employ various forms of memory, including on-chip CPU memory (e.g., registers), RAM 2880, ROM 2885, and storage device 2890. Storage device 2890 can employ any number of tangible, non-transitory storage devices or systems, such as fixed or removable disk drives, optical drives, solid-state memory devices, and other processor-readable storage media. Computer-executable instructions stored in memory can include an interactive game platform having one or more program modules, such as routines, programs, objects, components, data structures, etc., that perform specific tasks or implement specific abstract data types. For example, memory can contain operating system (OS) components 2895, modules and other components, database tables, etc. These modules / components can be stored and accessed from storage devices—including external storage devices accessible via interface bus 2835.

[0223] Database components can store programs executed by a processor to process the stored data. Database components can be implemented as relational databases, scalable databases, and secure databases. Examples of such databases include DB2, MySQL, Oracle, Sybase, etc. Alternatively, databases can be implemented using various standard data structures such as arrays, hashes, lists, stacks, structured text files (e.g., XML), tables, etc. Such data structures can be stored in memory and / or in structured files.

[0224] The controller 2800 can be implemented in a distributed computing environment where tasks or modules are executed by remote processing devices linked via communication networks such as a local area network (“LAN”), a wide area network (“WAN”), or the Internet. In a distributed computing environment, program modules or subroutines can reside on both local and remote storage devices. Distributed computing can be employed to load balance and / or aggregate resources used for processing. Alternatively, aspects of the controller 2800 can be electronically distributed via the Internet or other networks, including wireless networks. Those skilled in the art will recognize that portions of an interactive game system can reside on a server computer, while corresponding portions can reside on client computers. Specific data structures and data transmissions of the various aspects of the controller 2800 are also included within the scope of this disclosure.

[0225] Certain aspects of the invention can be understood from the aforementioned disclosures, among which several examples are provided below.

[0226] The functional block diagrams, operational scenarios and sequences, and flowcharts provided in the accompanying drawings illustrate exemplary systems, environments, and methodologies for performing novel aspects of this disclosure. While for the purpose of simplifying explanation, the methods included herein may be in the form of functional diagrams, operational scenarios, sequences, or flowcharts and may be described as a series of actions, it should be understood and appreciated that the methods are not limited by the order of actions, as some actions may occur accordingly in a different order and / or simultaneously with other actions shown and described herein. Those skilled in the art will understand and appreciate that methods may alternatively be represented as a series of interconnected states or events, such as in a state diagram. Furthermore, a novel implementation may not require all actions exemplified in a methodology.

Claims

1. A system for tracking, managing, and implementing hotel room-related transactions in one or more hotels, comprising: A node network, communicatively coupled to endpoints in a distributed network. The node network mentioned above maintains a distributed ledger using entries from one or more endpoints. The entries include: entries from customers relating to at least one hotel room provided by the operator of the one or more hotels, and entries from the operator regarding the availability status of the at least one hotel room. Each of those entries is associated with at least one access level required for the entry corresponding to the review; A communication component for receiving requests to view at least a portion of one or more entries stored in the distributed ledger. The request includes an access code associated with the at least one access level; An access control layer is configured to: evaluate the access code in the request and identify segments within the one or more entries stored on the distributed ledger that are accessible via the at least one access level provided in the request; and A means for generating a customized view of the segment as identified by the access control layer. Each of the entries also includes a data portion, which is decomposed into multiple segments.

2. The system of claim 1, wherein the one or more endpoints include at least one of the following: a monitoring device, a security device, an imaging device or a video device, and an access control device.

3. The system of claim 2, wherein the one or more endpoints include the access control device, wherein the access control device or system includes a key card reader, and wherein the system further includes: Payment processing system; as well as A device for charging a customer using the payment processing system after the customer has entered at least one hotel room for the first time using a key card at one or more of the hotels.

4. The system of claim 3 further includes means for automatically updating the availability status of the at least one hotel room after the customer first enters the at least one hotel room.

5. The system of claim 3 further includes means for automatically crediting or debiting the customer's reward points after the customer first enters the at least one hotel room.

6. The system of claim 1 further includes an artificial intelligence engine for: reviewing entries in the distributed ledger and assigning the at least one required access level for reviewing each of the entries.

7. The system of claim 6, wherein the artificial intelligence engine categorizes the data within each of the entries into one or more categories.

8. The system of claim 7, wherein the access control layer further sets a different encryption level for each of the one or more categories of data classified by the artificial intelligence engine.

9. The system of claim 8, wherein the one or more categories include email address, account number, loyalty points, balance, hotel guest name, mailing address, vehicle identification number, license plate number, biometrics, driver's license number, photo, or social security number.

10. The system of claim 1, wherein the access level associated with a segment within the one or more entries includes at least one of the following: private access level, permitted access level, and public access level.

11. The system according to claim 10, wherein: The entries from customers include data representing: one or more identifiers of the customer who registered the at least one hotel room by their name, the customer's payment account, and the customer's loyalty points; and The entry from the operator includes data representing the room rate, availability status, and inventory of the at least one hotel room.

12. The system of claim 11, wherein one of the following: The customer's one or more identifiers are associated with the private access level; The room rate for the at least one hotel room is associated with the permitted access level; and The availability status of the at least one hotel room is associated with the public access level.

13. A method for generating a customized view of blockchain data related to transactions involving hotel rooms in one or more hotels, the method comprising: Receive a request to view at least a portion of one or more entries stored in a distributed ledger maintained by a network of nodes in a distributed network. The node network maintains the distributed ledger using entries from one or more endpoints. The entries include: entries from customers relating to at least one hotel room provided by the operator of the one or more hotels, and entries from the operator regarding the availability status of the at least one hotel room. Each of those entries is associated with at least one access level required for the entry corresponding to the review, and The request includes an access code associated with the at least one access level; Evaluate the access code in the request to identify a segment within one or more entries stored in the distributed ledger that is accessible via the at least one access level provided in the request; and Generate a customized view of the segments identified within the one or more entries. Each of the entries also includes a data portion, which is decomposed into multiple segments.

14. The method of claim 13, wherein the at least one access level required to review the entry includes a security investigation level.

15. The method of claim 14, further comprising applying an edit map to the entry based on the security investigation level.

16. The method of claim 13, further comprising separately recording at least a portion of the entries from the customer and at least a portion of the entries from the operator into the distributed ledger.

17. The method of claim 13, further comprising receiving or transmitting payment or refund information related to transactions involving the hotel room.

18. The method of claim 17, wherein the payment or refund information includes cryptocurrency account data of the customers of the at least one hotel.

19. The method of claim 18, further comprising automatically converting cryptocurrency into real currency according to an exchange rate.

20. The method of claim 13, wherein receiving a request to view at least a portion of one or more entries stored in the distributed ledger comprises receiving the request from at least one of the one or more endpoints operable by at least one of the operator or the customer.

21. The method of claim 13, further comprising obscuring the identification information of the user who made the request to view at least a portion of the one or more entries.

22. The method of claim 13, further comprising applying editing to any segment within one or more entries in the distributed ledger that is not accessible by the at least one access level provided in the request.

23. One or more non-volatile computer-readable media having program instructions stored thereon, which, when executed by at least one processor, cause the machine to: Receive a request to view at least a portion of one or more entries stored in a distributed ledger maintained by a network of nodes in a distributed network. The node network maintains the distributed ledger using entries from one or more endpoints. The entries mentioned above include: Entries from customers relating to at least one hotel room provided by the operator of the one or more hotels, and entries from the operator regarding the availability status of the at least one hotel room. Each of those entries is associated with at least one access level required for the entry corresponding to the review, and The request includes an access code associated with the at least one access level; Evaluate the access code in the request to identify a segment within one or more entries stored in the distributed ledger that is accessible through the at least one access level provided in the request; as well as Generate a customized view of the segments identified within the one or more entries. Each of the entries also includes a data portion, which is decomposed into multiple segments.

24. One or more non-volatile computer-readable media according to claim 23, wherein the at least one access level required to review the entry includes a security investigation level.

25. One or more non-volatile computer-readable media according to claim 24, wherein when executed by the at least one processor, the program instructions further cause the machine to apply an edit mapping to the entry based on the security survey level.

26. The one or more non-volatile computer-readable media of claim 23, wherein when executed by the at least one processor, the program instructions further cause the machine to separately record at least a portion of the entries from the client and at least a portion of the entries from the operator into the distributed ledger.

27. One or more non-volatile computer-readable media according to claim 23, wherein when executed by the at least one processor, the program instructions further cause the machine to receive or transmit payment or refund information related to the hotel room transaction.

28. One or more non-volatile computer-readable media according to claim 27, wherein the payment or refund information includes cryptocurrency account data of customers of the at least one hotel.

29. One or more non-volatile computer-readable media according to claim 28, wherein when executed by the at least one processor, the program instructions further cause the machine to automatically convert cryptocurrency into real currency according to the exchange rate.

30. One or more non-volatile computer-readable media according to claim 23, wherein when executed by the at least one processor to receive the request, the program instructions further cause the machine to receive the request from at least one of the one or more endpoints operable by at least one of the operator or the customer.

31. One or more non-volatile computer-readable media according to claim 23, wherein when executed by the at least one processor, the program instructions further cause the machine to obscure the identification information of a user who has made a request to view at least a portion of the one or more entries.

32. The one or more non-volatile computer-readable media of claim 23, wherein when executed by the at least one processor, the program instructions further cause the machine to edit any segments within one or more entries stored in the distributed ledger that are not accessible by the at least one access level provided in the request.

Images