Patent ID: 12218947

DETAILED DESCRIPTION

Blockchains have become a commonplace in generating a blockchain of data and sharing the data among users in a distributed network. Unlike previous database structures, the blockchain database is maintained by a multitude of independent nodes spread across a large distributed network of nodes. A public blockchain is a digital ledger that is open to any user to enter and record data (also referred to herein as transactions or block entries) into a block of the blockchain. When a transaction is recorded into the blockchain database, it is very difficult, if not impossible, to change or remove the transaction data from the database since the data is stored in more than one node in the distributed network. Therefore, data is added into the blockchain database by multiple users and changing the recorded data by adding, editing, or removing data would require a majority of the users or a master controller supervising changes and a cosigner (e.g., manager and employee, auditor and pit boss, etc.) to agree to the change.

Additionally, each block contains the data, the hash of the current block, and the hash of the previous block. The blockchain may also store additional details about the transaction in the block, such as the username initiating the transaction, other usernames of parties associated with the transaction, a timestamp, executable code, among other information that relates to the transaction. The hash identifies the block and the transaction data stored within the block. The hash is unique from all other hashes and changes whenever a change is made to the block. Since each block contains the hash of the previous block, the blocks form what is known as a blockchain. Any tampering with a block will cause a change in the hash of that block. Therefore, all other blocks in the blockchain will become invalid since they no longer contain a valid hash of the previous block.

While it may be possible to change the hash of each subsequent block in the blockchain, it would be nearly impossible to change each blockchain stored on each node in the distributed network, for both private and public networks. This combination of storing previous hashes to form the blockchain and distributing a full copy of the blockchain to each node in the distributed network (private, permissive, and public) creates a system of trust amongst users and the stored transactions in the network, especially when users are not familiar with one another (i.e., public network).

Examples of the present disclosure describe a system, process, and application for generating a customized view of a blockchain transaction. A blockchain of block entries requested by a plurality of users from user devices is maintained in a distributed network of nodes. The block entries each comprise a plurality of data portions that are each associated with an access level. A request to view one or more data portions of a block entry is received which includes an access code (e.g., hash, private key, biometric, password, PIN, etc.) associated with at least one access level. The access code in the request is evaluated with the blockchain of block entries to identify one or more data portions associated with the access level. A customized view of the block entry is generated which includes the one or more data portions associated with the access level. In some embodiments, the portions of the data stored in the blockchain may be individually encrypted. As such, depending on the level of access associated with the access code, decryption of only a portion of the data may be authorized or available while other portions would remain secure.

A technical effect that may be appreciated from the present discussion is the increased efficiency in identifying entry data that a user is authorized to access (e.g., financial records in a banking institution, parking facility customer and associated transaction data, a customer/supplier tracking inventory, vehicle fleet passenger usage, route and location information, compliance data for a gaming regulation committee, classified documents from a governmental or semi-governmental agency, health records for a medical institution, Protected Critical Infrastructure Information (PCII), data needed for a government auditor/inspector, and the like) and providing a customized view of the data that was recorded in the blockchain transaction. Some of the embodiments described herein also improve security by only allowing access to the user if the user has authorization to access the portion of data from the blockchain entry. In addition, some embodiments can provide an immutable log showing when and who accessed various data. In addition, in some embodiments, automatic review (e.g., by an artificial intelligence or machine learning engine) can occur to detect specific events (e.g., theft of user account access credentials or facility access devices, insider trading, money laundering, cheating, voter fraud, etc.).

For PCII in particular, the present technology addresses issues affecting protecting of customer information, along with customer's respective credit card or payment information. The present technology utilizes the blockchain for payment transactions via a blockchain, while obfuscating user information to maintain the privacy of the transaction. Application of the present technology enables some of the respective transaction information to be made available in either a hybridly private, or even public, form may, as the case may be, while still allowing for some information of the transaction stored in the blockchain to be sent about a user via the disclosed customized view. This enables customers to keep their information private while getting the benefit of transparent payment/pricing based on their usage or purchase a unit of commercial inventory. In the parking facility context, for instance, electric vehicle charging stations are made available in some of the parking spaces as added convenience and commercial service. The efficiency and convenience of such services that are ancillary to the main inventory transaction is improved for the customers and the operator where all information (e.g., pricing, rates and availability) related to both the main inventory (parking) and all available ancillary services are stored and updated on the blockchain and made available to all interested parties via the customized view.

More specifically, one implementation may provide a non-routine process of generating a customized view of a banking transaction that limits user sensitive information (e.g., Anti-Money Laundering (AML) or Know Your Customer (KYC) policy documents, (ADD) account numbers, account balances, account statements), but allows an external banking institution or user to verify that an account has available funds for a transaction. Another scenario provides a non-routine process of auditing a transaction in the blockchain while not enabling an auditor to view a full version of the transaction. For example, the Internal Revenue Service (IRS) may require an audit of all monetary transactions performed within the previous tax year. However, the company being audited may not be required to provide a full list of customer names and addresses for each transaction. By providing a customized view of the transaction, the IRS may have confidence in the accuracy of the transaction amounts and the company may maintain anonymity of its customers.

An additional technical effect of the present discussion may be appreciated in the gaming regulation industry. For example, one implementation described herein provides a non-routine process of viewing the outcome of a gaming bet while concealing a betting amount. This may be useful when monitoring a gaming community for advantage players (e.g., card counters, etc.) while allowing the players to maintain privacy of their money pot. In another example, a gaming committee may require a customized view of a transaction to view some personal information about each player (e.g., verification that each player is of a legal age to gamble, verification that each player has not been blacklisted, player handles/nicknames) but not enable other personal information to be viewable (e.g., credit card numbers used to buy into the game, legal names of each player, etc.).

In some embodiments, third parties may view a game, associated statistics of the game, and the winner or loser of the game. In an example, users may select the game to watch from a selection of viewable games and then place their bets (e.g., micro bets or parimutuel bets) based on what they are watching. In another example, a game engine for is hosted and operated entirely using the disclosed blockchain-based systems and methods. For instance, a random number generator (RNG) may dictate the outcome of games of chance instead of real world games with bet winners dictated by an external validation source. Games functions including the RNG may be held on the blockchain, or on a shard in cases where the blockchain is partitioned for spreading out the computational and storage workload for running the game. In another example, in the event that a bet is cancelled, then all the bets may be voided. The disclosed systems and method may also be utilized with the blockchain to facilitate people betting on events that may occur in the future. In such cases, given a date that an event may occur, if the event never occurs on any of the dates comprising players' wagers, the bets may be cancelled as it was a prerequisite in the bet that the event may never happen. In that instance, the bettor would lose their money to the bookmaker, bot or person taking the bet.

Another example may include the Nevada Gaming Commission requiring disclosure documents of previous business relationships, employment history, criminal records, and financial stability from an applicant seeking a license for a gaming establishment. However, the applicant may not be required to provide expunged records of criminal behavior. Therefore, the view of the documents would be customized to display only those portions of the documents required by the Nevada Gaming Commission and omit, redact, or otherwise obfuscate data that is not deemed relevant or needed for seeking the license. In some embodiments, taxation of betting transactions and winnings may be carried out online automatically at the appropriate rate based on a bettor's location, as determined by the IP address or GPS location of the bettor's device. In an example, the blockchain according to the disclosure provides interoperability to the blockchain to communicate on the platform or between bets.

In some embodiments, the system may ingest the private information and generate a publicly viewable score, rating, or other indicator that may be used in making a decision without disclosing the underlying confidential information. In some embodiments, the system can connect to additional public and private data sources to collected additional information. For example, public information like FBI reports, credit reports, background reports, and the like. This additional information can be stored in the blockchain as part of the record or profile of an individual. This could be done off of a social security number, driver's license, facial recognition or fingerprint as a second factor for verification. As such, once a person enters the casino and registers a card to play it is possible that big data would be collected on who the person really is and that information would only be available to the casino, auditor and regulator to make sure the person is who the person says he is, is legal and allowed on property or able to play. It is possible that commercial and government buildings like office buildings and airports are able to have camera systems which read the license plates for cars coming into a parking facility or monitoring facial recognition of the driver and passengers. This information can be compared and scored to see if the car or the person is safe to enter a facility. Cameras can also be used to capture images of a vehicle begore it enters a parking facility to ascertain if there is any pre-existing damage on the vehicle, which would enable facility operators/owners to avoid liability for property damage claims where there was preexisting damage to the vehicle.

In an example, a casino may host or maintain one node on a distributed network of nodes. This gives the casino their own irrefutable record of events that they can access and control. If the network goes down, the casino would still be able to manage all of its activities from bets, game play, stakes, rewards, etc. Once the network comes back on line, any necessary updates may be made with ease by the casino's node to the distributed network of nodes. This backup functionality and independent node scenario provides a casino with continuity of business operations, and such benefits may be enjoyed in an analogous fashion in the retail and parking space examples.

In yet another embodiment, a technical effect may be recognized for a non-routine process of tracking package deliveries and inventory transit. For example, one or more packages may be scanned at origin, then once again as the packages begin transit in one cargo unit. The transit company may want to allow a recipient of one of the packages to view data associated with their box but not allow the recipient to view all other data stored in the transaction associated with the other packages in the cargo unit. Therefore, a customized view of the transaction for the recipient user describing the location, departure time, and estimated arrival time for their package only would be enabled. Additional information associated with the product may also be collected and stored in a blockchain detailing product logistics, such as manufacturer, vendor, checkpoint location, checkpoint employee, quality control manager, testing center, as well as a chain of custody through the shipping process as well as individuals that accessed the cargo unit during its shipment. At any time or upon receipt, the receiving party may be enabled to see parts of this information but not all depending on the status of the recipient. For example, a gambling establishment or regulator may be able to view selective product information regarding manufactured dice along with a chain of custody to verify that the dice have not been tainted with while routed from the trusted dice manufacturer. This data may be displayed in a customized view.

Further, examples herein describe that the access code in the request with the blockchain of block entries may be evaluated by processing an encryption code to validate access to view the one or more data portions associated with the access level. In other examples, a pointer is also maintained for each of the plurality of data portions in the block entries indicating at least one published location for each of the plurality of data portions in the block entries. Further in this example, the customized view is generated by retrieving the one or more data portions associated with the access level using the pointer for each of the plurality of data portions in the block entries. The access of the portions of data require the use of a pin code, password, fingerprint, barcode, retinal scan, token, questionnaire, or any other type of access determination method including two-factor, multi-factor, or additional security authenticators.

In still other embodiments, additional technical effects may be recognized for a non-routine process of tracking and recording activities, preferences and transactions in parking facilities. For example, entry and exit times may be collected and recorded in the blockchain and associated with vehicle identities. Additional identity information of vehicle drivers or passengers (e.g., biometrics, facial recognition or mobile phone) using the parking facility may be collected contemporaneously with vehicle identities, and used to validate parking payment transactions. Electronic wallets, including for real or cryptocurrency, and credit or debit card account information received via a user interface either prior to or proximate in time to the parking visit may be securely associated with parking customers and utilized for fast and secure payment transactions using real time tokenization. Additional information associated with periodic or recurrent parking facility customers (e.g., multiple vehicle identifiers owned or otherwise used by a particular customer) may also be collected and stored in a blockchain and utilized to facilitate efficient parking business operations and enhanced convenience for customers. In addition to manual data entry of information for recording in the blockchain, various devices positioned in or near parking facilities may be utilized to facilitate improved parking business operations and customer experiences as described in greater detail, below, by way of examples. These data may be displayed to parking facility staff and customers in a customized view.

In a further example, the blockchain of block entries requested by the plurality of users from the user devices is maintained by maintaining a separate block entry for the one or more data portions associated with each of the access levels. Further in this scenario, the access code in the request is validated to view the one or more block entry for the more or more data portions associated with each of the access levels. In some implementations, the blockchain of block entries requested by the plurality of users from the user devices is maintained by maintaining a separate blockchain for the one or more data portions associated with each of the access levels. Further in this implementation, the access code in the request is validated to view the one or more block entry for the more or more data portions associated with each of the access levels.

In some examples, the received request to view the one or more data portions of the block entry comprises an inventory tracking request pertaining to products or packages, or to available parking spaces at any given time in a parking facility. In the parking industry context, such requests may be received by either an owner or operator of the parking facility, or by a current or potential parking customer. In other examples, the received request to view the one or more data portions of the block entry comprises a financial auditing request. In some scenarios, the received request to view the one or more data portions of the block entry comprises a gaming regulation request or a request pertaining to an investigation involving a vehicle parked in a parking facility presently or at some past time or when it entered or left the facility. In other scenarios, the access level associated with the one or more data portions of the block entry comprises at least one of a private access level, a permissive access level, and a public access level. However, in even further examples, the access level associated with the block entry comprises at least one of a private access level, a permissive access level, and a public access level.

While the present disclosure describes various embodiments, it should be appreciated that additional examples may be included for technical improvement 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, drugs and pharmaceuticals,cannabisand CBD, oil and gas, energy and commodities, national security, and the like.

Referring to the drawings,FIG.1illustrates an exemplary operational architecture100related to processing operations for management of an exemplary enhanced system with which aspects of the present disclosure may be practiced. Operational environment100includes blockchain network101. Blockchain network101employs a view customization process200in the context of authorizing a user to view a portion of data in a blockchain entry based on the user's approved access level. Blockchain network101may include various hardware and software elements in a supporting architecture suitable for performing view customization process200. One such representative architecture is illustrated inFIG.28with respect to controller2800.

Server nodes110-112comprise one or more servers and devices capable of running a blockchain application. User devices interacting with server nodes110-112may include, but are not limited to, personal computers, mobile phones, handheld device, tablet computers, desktop computers, laptop computers, wearable computing devices, voting machines, gaming machines, electronic financial exchanges, security systems, transponder, cameras or other imaging devices, key fobs, sensors, access cards, and the like capable of transmitting or receiving wireless data signals encoding information for accessing parking facilities for parking and providing payment for the same, or any other form factor, including any combination of computers or variations thereof.

More particularly,FIG.2illustrates view customization process200which, as mentioned, may be employed by blockchain network101to generate a customized view of restricted transactions recorded into a blockchain as described herein. Some or all of the steps of view customization process200may be implemented in program instructions in the context of a component or components of the application used to carry out the customized view feature. The program instructions direct blockchain network101to operate as follows, referring parenthetically to the steps inFIG.2in the context ofFIG.1.

In operation, blockchain network101maintains blockchain120of block entries requested by a plurality of users from user devices, wherein the block entries each comprise a plurality of portions that are each associated with an access level (step201). The blockchain database is maintained by a multitude of independent users spread across blockchain network101of server nodes110-112. Blockchain120is a digital ledger that is open to any user (e.g., a public blockchain), a specific set of users (e.g., a private blockchain), or combination of private and public users (e.g., a hybrid blockchain) to enter and record data into block130of the blockchain. Blockchain120may be added by multiple users and recorded by multiple nodes110-112in the distributed network.

In the parking industry context, parking facility operators may maintain certain records on the blockchain such as GPS locations of parking facility entrances, identifiers (e.g., alphanumeric) of available parking spaces, rates, and parking sales, specials, or promotions as publicly accessible. In some embodiments, such records are publicly accessible for users who first do one of the following actions: access a website, subscribe to an email list, download a smartphone app, park at a parking facility for the first time, and the like. Other records, such as customers' digital wallets, credit/debit card account information, usage history, vehicle identification information, portrait images, and the like may be maintained on the blockchain as private records accessible only by the respective customers and the parking facility operator. In some embodiments, blockchain records such as a present parking location, vehicle identifier, and the associated customer name may be made available on a limited basis to a vehicle recovery or repair service provider, including on a subscription basis. In this case, a parking facility experiencing a need for vehicle service (e.g., windshield replacement, dry cleaning, pet boarding) may schedule and receive the service with the provider even during such times when the vehicle owner is not co-located with the vehicle in the parking facility. The customer of the parking facility may optionally grant permission to the parking facility via the user interface to have the parking facility process a payment to the service provider using the customer's payment account information recorded on the blockchain. In such cases, the parking facility may, instead of or in addition to a subscriber fee paid to the facility operator by the vehicle servicer, collect a commission from the vehicle service payment for facilitating the service and the payment processing. Related ancillary services in parking facilities utilizing the blockchain in the same or similar manner may include, for example, car washing or detailing, refueling, electric vehicle charging, arranging carpools or rideshares, valet parking, vending machines, coffee bars, newspapers and the like.

Parking reservations can be made via a customer's mobile phone. With this feature, a parking facility knows that a customer is coming. Payment information or payment can be stored and paid in advance or upon arrival at the facility and can be based on the duration of parking that can be determined upon exiting of the facilities. Once a customer shows up to the facility entry, their vehicle license plate, their mobile phone number, or a barcode/hashtag displayed on their mobile device screen can be used to identify them to any of a camera, a kiosk, valet or a facility operator. A customer may have already chosen to pay for valet service or self-parking service. A customer can change their mind and chose valet parking upon arrival, which could change the service charge. A customer could also choose to self-park and save money so the service charge to the customer could also change. Lot attendants, valets can access the system and amend the booking/reservation and charge for the change in services.

Block130includes block entries140-142. Block entries140-142may include various types of data including parking facility customer usage and transaction records, number and locations of available spaces in a parking facility, self-park or valet, gaming bets, inventory records, medical records, banking and financial records, smart contracts, and any other type of combination or variation thereof. For instance, the user (e.g., parking customer) may create block entry140by entering into a contract with another user (e.g., parking facility operator) and then storing the contract as block entry140in blockchain120on nodes110-112in the 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 an availability status of parking spaces in a parking facility, electronic voting machines, gambling machines, auditing software running on one or more servers, end-user devices, and the like) may connect automatically to blockchain network and request data be added in block entries.

In order to add a new block entry with data portions, blockchain may use consensus protocols like proof of stake (PoS), or proof of work (PoW), delegated proof of stake (DPoS), or the like. For example, in PoW, in order for server node110-112to be elected as a leader to select the next block entry140to be added to the blockchain, a particular server node has to find a solution (typically by brute force) to a particular puzzle or mathematical problem. Once the solution is found, the server node publishes the solution to the other nodes for validation. When a consensus of the nodes agrees 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. In contrast, PoS is based on the involvement and value at risk (e.g., the stake) of the server node. DPoS is efficient variation of PoS that provides a high level of scalability by limiting the number of validators on the network to set of delegates (e.g., voters) to vote on whether to add an entry to the blockchain.

Block entries140-142also each include data portions150-155. Data portions150-155comprise the components which make up each of block entries140-142and may be broken into segments based on a user request or a transaction format (both standardized and customized). For example, a portion of data from a transaction may be allocated as private if a user flags the portion of data as confidential. The portion of data may also be allocated as private if the data is of a category which was previously allocated as private. For example, a user may categorize all credit card numbers as private. Conversely, a portion of data may also be allocated as public or permissive by the user. In some implementations, the portion of data may only be designated as accessible to a receiving user if the originating or controlling user provides permission (e.g., originating party of a transaction allocates the block entry and all data portions as private and ability to view a portion of data requires consent via signature terms and condition form). This user consent feature may be included in an access platform allowing users to provide consent through a user consent section.

Some embodiments of the present technology modify the traditional protocols and workflow for adding data to the blockchain. For example, in some embodiments, the server node110-112is required to identify or classify portions of the data into one or more categories. This can be done, for example, using artificial intelligence or machine learning to classify the data into one or more categories (e.g., e-mail address, VIN, license plate number, social security number, full or partial images of human faces for facial recognition algorithms, serial numbers or customer account numbers associated with decoded radio frequency identification (RFID) or near field communication (NFC) signals, etc.). In some embodiments, a decentralized application (DApp) may be responsible for the initial sorting and categorization of the data. When a block entry140-142is added, the initial line of the entry that typically includes the hash of previous blocks and a time stamp may be amended to include information regarding the data categories within the entry, access level for each data portion, access restrictions, or the like. For example, some embodiments may create an index and/or access level information that stored within the block entry. As such, when the data is later retrieved it can easily be identified or associated with an appropriate access level. Still yet, in some embodiments, the server node responsible for adding the data may organize the data and set different encryption levels for the different data portions150-155. In other embodiments, a middleware may be used (e.g., on a data platform sitting between the blockchain network and the connecting devices) to decrypt encrypted data stored on the blockchain, classify information, and enforce access level permissions thereby creating the customized view.

In some scenarios, the user may set a default setting allocating all of the data in the transaction as public and selectively allocate individual segments of data as private, and vice versa. Likewise, a portion of the data may also be allocated as permissive where the data is not available to the general public but may be accessible to users of various groups, such as auditing committee members, law enforcement officers, government regulation personnel, medical staff, and the like. In other examples, blockchain120may include default rules to allocate portions of data as private, permissive, or public.

For example, blockchain120may determine that any driver's license number, RFID, Bluetooth® or NFC of parker, parking facility reserved parking space identifier, license plate number, VIN or social security number should be automatically set to private access. While several examples and embodiments included herein describe the main access levels to be categorized as private, permissive, or public, it should be understood that any number of access level categories may be recognized within the scope of the present disclosure. Moreover, the status of the access levels may automatically change or be updated based on detection of certain events. For example, all data regarding a deal 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 related data.

In a next operation, blockchain network101receives a request to view one or more data portions150-155of block entry140from a user which includes an access code associated with at least one access level (step202). The request to view may be initiated by a user who is a party to the transaction stored in block entry140, such as an operator of a parking facility receiving a data request from a customer or one participant in a gaming bet. The user may also be a user merely having interest in the business operations or transaction but not directly involved with the transaction, such as a driver looking for a convenient place to park, a tax auditor verifying income data, a transfer agent or third party financial custodian holdings stocks and bonds, a servicer that collects debt payments on behalf of a lender or a stockholder viewing recent company dividend transactions.

In a next operation, the access code is evaluated with the blockchain of block entries to identify one or more data portions associated with the access level (step203). The access code may be designated to the user based on a user status, such as a government employee, package delivery employee, bank manager, parking garage customers and operators, etc. The access code may be determined based on an encrypted code (e.g., a private key or hash) given to user which is associated with an access level or data portion. The access code may further be validated based on a password, signature, fingerprint, barcode, processing chip, questionnaire, biometric, token, and any other method which may enable a user to verify authorization to access data portions150-155associated with an access level. In some example scenarios, data portions150-155may be separated into different blockchains or block entries based on their associated access level. In this scenario, access code150may be required to access the blockchain or block entry to view the portion of data associated with the access level.

In a final operation, a customized view of the block entry is generated which includes one or more data portions150-155associated with the access level (step204). The customized view may be generated by a data access platform. The customized view may be modified to incorporate only those data portions associated with the validated access level or may include all data portions150-155with unauthorized data portions blacked out from the record view. The customized view may be surfaced in a blockchain application (e.g., a DApp) on a user device, transferred to a user in the form of a record message, or displayed in any other manner to a user or user group.

In accordance with various embodiments, the addition of data to the blockchain, security level screening, data categorization, access level assignments, auditing and/or other functionality may all be done autonomously. For example, as a vehicle enters a parking facility, sensors including receivers for Bluetooth® or other wireless signals, cameras or other imaging devices, and access control systems such as gates and access device readers collect data used for identifying the vehicle, a vehicle's condition, its driver, and possibly also its passengers. Meanwhile, sensors such as motion, weight, distance or proximity sensing devices collect data for monitoring an availability status (e.g., occupied vs. unoccupied) of parking spaces in the parking facility.

As another example, as a user enters a casino data can be collected added to the blockchain from various systems (e.g., surveillance cameras, parking garage cameras, loyalty card systems, room access systems, entertainment databases, and the like). 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, associate and classify relevant data that can be added to a blockchain. The data itself may be indexed for searching and/or future ingestion. In other embodiments, the data may be segmented and added to a profile of a player. Since various portions of the data can be assigned different access levels, the person requesting the data may be automatically served only the portions of data that are appropriate for their access level. Similarly, the data may be automatically reviewed or audited to identify violations (e.g., security or safety concerns, unsafe driving or other disfavored customer behavior in the parking facility, gambling rule violations, cheating, collusion, people banned from gambling, vehicles or people who are not permitted to enter or otherwise use the parking facility, etc.).

Similar to parking facility business operations and casino monitoring, various embodiments of the present technology can be applied to verticals that may enjoy benefits of the disclosed systems and methods that can record, track, analyze and review data automatically without humans overseeing the review for performing transactions and gathering and utilizing actionable intelligence to improve business operations and customer experiences. For example, some embodiments may interface with secure data sets (possible stored on a private blockchain) to gain biometrics or data about an individual. As such, government agencies (e.g., ICE or Department of Homeland Security) can provide data that can be used to identify individuals and make determinations whether they should be granted to access to particular data, activities, and/or locations. For example, various embodiments of the system may be used to screen individuals for a trusted traveler program. As the individual enters the airport, for example, surveillance cameras can collect video data which can be ingested by artificial intelligence or machine learning engines. This data can be linked with license plates, travel records, biometric data, and the like to initially identify the individual and determine if a violation is in progress, prescreen the person (e.g., for faster screening), or determine whether the user can be denied entry to the airplane or other travel method. In some embodiments, each person may have their driver's license scanned and the system can automatically classify the identification as legitimate or a fraud and search for records in the blockchain to assist in making decisions.

FIG.3illustrates various components of a blockchain data platform utilizing a distributed ledger architecture according to various embodiments of the present technology. As illustrated inFIG.3, the blockchain data platform may use one or more servers305A-305N. Each server can include blockchain interface310, monitoring mechanism315, client interface320, rules engine325, encryption/decryption module330, analytics module335, event module340, multifactor authentication module350, report generator355, and/or databases360and/or365for storing logs, subscriber policies, transaction policies, location policies, and/or the like. In addition, blockchain servers305A-205N can connect with blockchain370, clients375, trusted data sources380, and/or records385.

Each of these modules, components, or databases can be embodied as special-purpose hardware (e.g., one or more ASICS, PLDs, FPGAs, or the like), or as programmable circuitry (e.g., one or more microprocessors, microcontrollers, or the like) appropriately programmed with software and/or firmware, or as a combination of special purpose hardware and programmable circuitry. Other embodiments of the present technology may include some, all, or none of these modules and components along with other modules, applications, databases, and/or components. Still yet, 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 a different module. For example, in one embodiment, rules engine325and event module340can be combined into a single module for identifying and enforcing various rules and event policies on a user terminal.

Clients375may connect to one of blockchain servers305A-305N using client interface320. Clients375may be able to download (or have preinstalled) firmware or software from blockchain servers305A-305N that allows clients375to enter and view block entries (or selected portions thereof). The block entries may comprise a variety of transactions (e.g., financial transactions, customer usage history and preferences of services in a parking garage, gaming bets, medical records, inventory tracking, etc.) and a variety of access levels (private, permissive, public, etc.). In some embodiments, blockchain servers305A-305N process an encryption code to validate access to view the one or more portions of each transaction.

In some embodiments blockchain servers305A-305N may maintain a pointer for each of the plurality of portions in the block entries indicating at least one published location for each of the plurality of portion in the block entries. The customized view of the block entry may then be generated by retrieving the portions associated with the access level using the pointer for each of the portions in the block entries. In other embodiments, blockchain servers305A-305N may maintain a separate block entry for the data portions associated with each of the access levels. Blockchain servers305A-305N may evaluate the access code in the request with the block entries of blockchain370to identify the data portions associated with the access level. In some scenarios, blockchain servers305A-305N may maintain a separate blockchain for the data portions associated with each of the access levels. Blockchain servers305A-305N may then evaluate the access code in the request with blockchain370to identify the data portions associated with the access level.

In some examples, information stored in blockchain370may be encrypted using encryption/decryption module330. In some embodiments, encryption/decryption module330may use various non-homomorphic encryption and/or homomorphic encryption. While the non-homomorphic encryption may provide stronger security properties, the use of homomorphic encryption would allow computation on encoded data without decryption. As a result, various components of the parking facility and customers' vehicles, or of a gaming system, can interact and operate on portions of the data without exposure of sensitive data.

Monitoring mechanism315can monitor transactions and user activities. This can include receiving information from external sources. In the parking facility example, the external sources include people, devices, or systems, such as customers using smartphone apps for the parking facility, facility management and staff using various business information technology systems and client devices, receivers for Bluetooth® or other wireless signals, cameras or other imaging devices, and access control systems such as gates and access device readers collect data used for identifying the vehicle, its driver, and possibly also its driver and passengers. Additional external data sources in the parking facility case may include sensors such as motion, weight, distance or proximity sensing devices collect data for monitoring an availability status (e.g., occupied vs. unoccupied) of parking spaces in the parking facility. In the casino example, the external sources include people, device, or systems, such as, but not limited to, clients375, video surveillance systems, loyalty card systems, key engines, biometric sensors, and other external systems. In some embodiments, multifactor authentication may be used before allowing a user to enter or to access a monetary transaction, parking reservations, payment methods for parking, parking history, vehicle, driver and passenger personally identifying information, medical record, gaming bet, inventory activity log, and the like.

For example, when a parking facility customer access a record of their credit/debit card, or checking, account for parking payments via a smartphone app, multifactor authentication module350may be used to required two different types of authentication (e.g., a password plus an alphanumeric code transmitted to the customer by text message or phone call to the phone number associated with their account registration data. As another example, when a patient accesses a medical record, multifactor authentication module350may be used to require various types of authentications (e.g., personal pin, biometric, token, etc.). Rules engine325can superimpose rules on the transaction interfaces being presented on clients375. These rules can be based various policies (e.g., subscriber policies, transaction policies, location policies, etc.) stored in database365. Analytics module335can generate various analytics about parking space usage trends, layers, clients, games, medical diagnosis, payrolls, package deliveries, payouts, accounts, and/or other system components or activity. This information can be used by report generator355to create customized view of the transactions.

Restricted access module340can be used to create customized access requirements for different portions of data in each transaction and for different users/user types. The rewards may be stored within blockchain370in records385. The access requirements may be generated by a user entering the transaction, determined based on previously designated user preferences, or by policies required by other parties (e.g., permissive access for medical records required by the Health Insurance Portability and Accountability Act of1996(HIPAA), state laws for minimum age to gamble, etc.) and present customized view of records based on those access policies. Databases360and/or365can be used for storing logs, subscriber policies, transaction policies, location policies, and/or the like. These may be local stores of data retrieved from records385associated with blockchain370. In addition, servers305A-305N and blockchain370can connect with trusted data sources380for validation of external events (e.g., outcome of sporting events, reconciliation of vender/buyer journal entries, etc.) or information (e.g., an authorized driver other than the registered user of the parking facility who the registered user has authorized to use their parking account, or status of a security clearance) that are needed to determine data stored within records385.

FIG.4illustrates a parking facility400for which related business operations may be implemented at least in part using the disclosed systems and methods. The parking facility400has at least one entrance402and at least one exit404. An access control and payment portal console422is positioned at the entrance402and exit404of the parking facility400. In some embodiments, the console422is divided into at least two separate and distinct structures. For example, a first console422for access control is positioned at the entrance402and a second console422for payment processing is positioned at the exit404. In any event, the access control functionality of the console422may be accomplished, for instance, by automatically actuatable entry424and egress426gates.

Parking facility400contains a plurality of parking spaces408situated on a road surface406. Each of the parking spaces408may be marked with a numerical, alphabetical or alphanumeric identifier, such as painted on the road surface406or marked on an adjacent wall, fence, or guardrail at or proximal the space408. At any given time, at least a portion of the parking spaces408may be occupied by vehicles (e.g., a first vehicle410). Spaces408that do not have a vehicle parked in them are naturally available for a customer to park their vehicle in. In an example, each space408of the plurality of spaces408includes a sensor418or other device for monitoring the status of each space408as either presently occupied or presently available in parking facility400. In some embodiments, one of a plurality of such sensors418or other devices is positioned in facility400and configured to monitor the availability statuses of at least two spaces408.

The sensors418may include proximity sensors positioned on the road surface406within the area defined by respective parking spaces408(e.g., in the center thereof). In some embodiments, the proximity sensors may be positioned on ramp, level, a ceiling, a wall, or other structure adjacent to a parking space408. In any event, the sensors418or other devices for monitoring parking space408availability status are configured to continuously or periodically transmit data representative of whether or not a respective single space408, or finite set (e.g., several) of spaces408, are occupied by vehicle(s). As such, the data transmitted by the sensors418are further representative of and associated with the particular parking space408identifiers and their availability status. For instance, the first vehicle410is presently parked in a space408, and at least several more vehicles are also parked in occupied spaces416(denoted by “X” inFIG.4). Meanwhile, at least several spaces408are currently unoccupied by vehicles, as shown inFIG.4by the respective sensors418of available spaces414being visible on the road surface406. Among these presently available spaces414is a space408from which a second vehicle412had recently departed to leave the parking facility400.

A current or potential customer of the parking facility400may view an inventory of available parking spaces414prior to arriving at the parking facility400. The data provided by the sensors418are recorded in the blockchain and may be communicated to users including customers, staff and management at or near real time so that informed decisions may be made in a timely manner. A customized view of the availability status of parking spaces408in the facility400may be provided to customers via a display of a personal computer, smartphone, or other suitable computing device. In some embodiments, the parking space408availability data may include statuses of one or more parking spaces regarding whether or not they may be reserved for use by customers at a later time on the same day as the inquiry, or at some later date. Thus, use of the disclosed systems and methods may be employed by parking system operators and their customers to facilitate related transactions and convenient experiences for hourly, daily, or monthly parking.

In addition to, or instead of, the parking space availability data provided by the sensors418, customers may include their vehicle or personal identifying information with their account registration data for the smartphone app, for instance. Vehicle information may include license plate440number or vehicle identification number (VIN), while biometrics or personal information may include a portrait image of a driver or passenger associated with the parking account registration, or an ID number of a access device (e.g., key card or key fob) used for gaining entry to the parking facility400.

The access control and payment console422may include one or more sensors or other devices for detecting or otherwise gathering one or both of the vehicle and personal identifying information. For example, the console422may include a radio frequency receiver428positioned in view of a portion of a vehicle upon which a corresponding radio frequency transmitter or transponder432is placed for use in the parking facility400. The transmitter432is configured to transmit wireless signals encoding data that uniquely identifies the vehicle, or its owner or authorized user. The transmitter432may also take the form of a key fob or key card carried by a parking customer and manually positioned to be in view of the receiver428upon entering the parking facility400. In either case, the receiver428, like the aforementioned sensors418, are external sources of parking business operations-related data that are recorded in the blockchain. The receiver428may relay these data to an intermediate transmitter or processor prior to their being recorded in the blockchain, or the receiver428may relay or otherwise transmit these data directly to computing and communication systems carrying out the recording of the data to the blockchain.

In another example, the console422includes a camera420or other imaging device positioned in view of a windshield or side window of a vehicle when the vehicle is positioned proximal the console422. A still image or video stream acquired by the camera420may be transmitted to a local or remote computing system or server for image processing analysis. In cases where a parking customer has previously provider a portrait image as a part of the account registration data recorded on the blockchain, the image processing analysis may be used to determine the identity of an entering vehicle's driver or passenger by using one or more facial recognition techniques known to persons skilled in the art. Additionally, or instead, the camera420may be positioned on console422and configured to acquire an image of at least one of the entering vehicle's license plate440, and VIN. Such image data may be transmitted to a local or remote computing system or server for image processing analysis by known letter and number character recognition techniques to determine the identity of the vehicle and the parking customer associated with it. In some embodiments, the image or video data acquired by camera420is used to determine the vehicle and customer identities using two or more of the portrait photographs, biometrics, mobile phone, the license plate440number, and the VIN. Basing the determination of vehicle and customer identities on sources other than, or in addition to, full or partial facial images may be advantageous to customers and parking facility400operators in cases where, for instance, the appearance of a customer's face changes over time as compared to the registration portrait image, as by natural aging, sun tanning or burning, wearing hats, wearing makeup, wearing wigs, wearing glasses, wearing colored contact lenses, wearing a scarf or mask, and growing facial hair.

To gain entry into the parking facility400by the vehicle, the data acquired by the receiver428and/or the camera420is validated against the customer account registration data recorded in the blockchain. Upon a successful validation process to verify that the customer and their vehicle area associated with a parking account in good standing, the entry gate424is automatically raised and any other access control device (e.g., a spiked rail capable of puncturing tires) is disengaged for a time sufficient to permit the vehicle to drive through the entrance402and onto the main parking area defined by the roadway surface406. In a preferred implementation, the vehicle driver will receive a message while their vehicle is still stationary at the entrance402(e.g., just prior to the entry gate424being raised) informing them of the nearest available parking space414, or another available parking space414determined according to their pre-recorded customer preference(s). In an example, a display or array of LED lamps on the console420positioned in view of the driver displays the respective identifier of the available space414. In another example, the available space414identifier is read aloud from a speaker of the console420at a volume level sufficient to be heard by the driver through a closed glass window and accounting for typical background noise of the parking facility400.

The time stamp including the time of day and the date of the entry of a vehicle may be recorded in the blockchain in association with the identity of the vehicle and/or the respective customer. The timestamp data facilitates determination of the parking rate to be charged and collected from the customer upon their exit from the parking facility. In use cases including subscription parking use of the parking facility400(e.g., weekly or monthly), recording the timestamp data in the blockchain facilitates trending and analysis of usage data by customers and operators, as desired.

The disclosed systems and methods likewise facilitate improved parking facility400business operations and customer experiences during the course of vehicles (e.g., second vehicle412) exiting the facility400. Receiver428, transmitter432, and camera420may each be used individually or any combination, as described above, to identify the vehicle or the customer at or on approach to the console422prior to reaching the exit404and leaving the parking facility400. Upon determining the vehicle or customer identity, these data are recorded in the blockchain along with their associated timestamp. In the case of a prepaid subscription parking account plan, upon determining and validating the vehicle412or its associated customer, the egress gate426is automatically raised and any other access control device (e.g., a spiked rail capable of puncturing tires) is disengaged for a time sufficient to permit the vehicle to drive through the exit402and out of parking facility400. In that case, no payment processing needs to be performed since the account is under a prepaid parking subscription. However, in the case of non-subscription accounts, the aforementioned identification and validation of the vehicle and customer identities must be performed prior to payment processing.

To improve business operations and customer experiences associated with exiting the parking facility400in cases requiring payment processing (e.g., hourly or daily parking) the data acquired by at least one of the receiver428, and the camera420, may be again recorded in the blockchain and used for automatic, fast and secure payment processing according to the parking rate, the entry and egress timestamps, and the customer payment information (e.g., credit/debit card account, digital wallet, or cryptocurrency wallet), each of which are also recorded in the blockchain. Thus, in such cases, the egress gate426is raised automatically and any other access control device is disengaged from a time sufficient to permit the vehicle to drive through the exit402and out of the parking facility400upon the identification and validation of the vehicle and the associated customer, along with successful completion of the payment due. In some embodiments, the console422may include devices and subsystems for accepting manual payments using cash, credit/debit cards, or digital wallets for real- or cryptocurrency via revenue control equipment or a mobile or Application or Dapp. In an example, console422includes a payment acceptance device430such as a credit/debit reader or a cash/coin counter and a display device434positioned in reach of a driver of vehicle412stopped before the egress gate426. For instance, a customer without a pre-registered account with the parking facility400may still deliver payment for parking in order to exit the facility400. Even for such non-registered customers, business operations and customer experiences may be improved by the disclosed systems and methods utilizing the blockchain by, for instance, enabling driver or vehicle identifications, automatically computing elapsed times for rate determination based on data acquired by cameras420, and displaying the pertinent payment instructions and other useful information to the driver on the display device434. Cameras420can also be used to capture images of a vehicle begore it enters a facility400to ascertain if there is any pre-existing damage on the vehicle, which would enable facility operators to avoid liability for property damage claims where there was preexisting damage on the vehicle.

Revenue control equipment in parking facility400may include the aforementioned console422and associated devices and subsystems such as camera(s)420, receiver(s)428and sensors418. Additionally, or instead, parking facility400revenue control equipment may include kiosks with credit card/bill accepters/mobile payment capability to run and allow people to enter/exit. Kiosk(s) may be integrated into console422, or they may be standalone devices positioned at various other convenient locations in facility400. Revenue control controls ticketing, access control, access cards, rates, taxes, statistics and analytics, performance, parking controls (access gates, e.g.,424,426), auditing functions, web and mobile payment interfaces, printers, and the like.

In some embodiments, a customer of parking facility400embodied in, or including, an autonomous vehicle may be guided by additional facility400subsystems such that these vehicles may safely park themselves upon entry and likewise return to a designated location prior to or after exiting facility400. In the illustrated embodiment ofFIG.4, the sensors418include beacons for transmitting a homing signal to a corresponding receiver in an autonomous vehicle. The beacon signal is paired to the receiver in the vehicle and is generated upon completion of the parking transaction that enabled the autonomous vehicle to enter facility400and have an available space408assigned to it. Autonomous vehicles may also include transponders or other devices providing vehicle identification that allows access control and is unique to that car, company, owner of vehicle etc. In the autonomous vehicle user case, the means for identifying the autonomous vehicle may be one or more of a transmitter, transponder, license plate440recognition, license plate440identity, and the like, enabling entry and exit without human involvement. In one example, in the case of non-subscription parking accounts, the aforementioned identification and validation of the vehicle and customer identities may be performed prior to payment processing.

In some embodiments, one or more spaces408of parking facility400includes an electric vehicle charging station436. Charging station436may be configured for either or both of wired and wireless charging of electric vehicles. The charging station(s)436may include devices and subsystems for identifying the vehicle or customer utilizing the charging station436in the space408being occupied by the respective vehicle. In an example, a registered customer having a transmitter432in or on their vehicle may be used to associate charging usage statistics (e.g., time on/off or charging energy delivered to the electric vehicle) with the customer's account with the parking facility400. These charging station436-related data may be recorded in the blockchain and the payment due for use of the charging station436may be automatically determined and deducted from the customer's payment credentials recorded in the blockchain. This payment process for ancillary services like electric vehicle charging, and the like, may be initiated and completed upon completion of use of the charging station436or added to the above-described processes for completing payment prior to exiting the parking facility400. A person of ordinary skill in the art may readily contemplate how ancillary services other than use of charging stations436(e.g., windshield and other vehicle maintenance/repair services, car washing, detailing, dry cleaner, pet boarding etc.) may similarly benefit in terms of business operational efficiency and customer experience improvements according to the disclosed systems and methods.

Convenience and efficiency for parking operations, as well as for such ancillary services, is further enhanced by application of the disclosed systems and methods by way of associating vehicle and their owners with parking spaces and any selected other services and storing the information in association with transaction data on the blockchain. These data are readily available to customers and operators via the customized views. As described above, identity management is facilitated by collection and storage on the blockchain of data such as license plate440recognition, license plate440identity, and using cameras420, sensors418, transmitters432, beacons, transponders, Bluetooth, NFC and the like.

In some embodiments, parking facilities400may provide their customers with a membership program for signing up to upon making parking reservations, conducting transactions, subscribing to a period parking program, and the like, according to the disclosed systems and methods. The blockchain and customized view of the present technology may be used to facilitate a rewards program for members. In the parking business context, rewards that may be provided to customers that attain certain milestones like time as members or dollars spent include for example, and without limitation, free carwashes, free days of parking or other perks. The rewards would also be associated with the respective customers and recorded and tracked on a blockchain. Rewards may be available for companies or individuals. Such rewards programs may function for the benefit of customers and parking facility operators in an analogous manner as with airline mileage programs.

FIG.5illustrates block diagram500in an implementation of an enhanced application to generate a customized view of restricted transactions recorded into a blockchain for parking facility business operations and transactions including payment processing. Block diagram500includes inventory block entry501, data platform510, servers520-522, blockchains530-532, and record502.

Block entry501is representative of any data transaction that will be permanently recorded into the blockchain, such as those data received and recorded from customers, connected devices, parking facility400, operators and staff, and external sources (e.g., sensors418, receivers428, and cameras420). Block entry501is subsequently processed by miners and added to a block at the end of the blockchain by data platform510. Block entry501further comprises portions of data which have been represented herein by Parking Space, Parking Facility Customer, and Parking Rate. Parking Space maintains the inventory, and availability status, of parking spaces408in parking facility400. Parking Facility Customer includes data relating to the identifiers of the vehicle, driver(s) and possibly also passenger(s) associated with the customer, along with their account- and payment-related data. Parking Rate includes data specifying the cost to parking in the parking facility400, including on an hourly, weekly, or monthly basis. It should be noted that while each of the data portions is represented separately, the portions of data are part of one transaction represented by block entry501. Block entry501may comprise any transaction or contract which has been executed and recorded in a distributed ledger platform environment for purposes of conducting parking facility400operations. In this example, block entry501may comprise an order, reservation, or spontaneous purchase request by a customer for use of a parking space in the parking facility. In some embodiments, a token may alternatively or instead comprise one or more of an order, reservation, or spontaneous purchase request by a customer for use of a parking space in the parking facility.

Data platform510represents any computing system or systems capable of hosting a blockchain application, of which controller2800inFIG.28is representative. Data platform510provides a secure distributed ledger system for recording parking transactions and parking space availability statuses into the blockchains. Data platform510may be implemented across a multitude of distributed network nodes which may be accessed by a variety of users, such as tax auditors, financial institutions, regulatory authorities, customers, company employees, parking facility400owners, parking auditors, management and staff, marketing companies, advertisers and the like.

Data platform510can also include servers520-522. Servers520-522may be representative of any computing system or systems with which the distributed network nodes may communicate. Examples include other devices having corresponding applications or services installed thereon, such that an operating user of a user device may be able to transfer a transaction to be added to a blockchain and distributed amongst the network nodes of the distributed network. Examples include media servers, web servers, and other types of end-points that may transmit transaction data to or receive transaction data from user devices and network nodes using communication protocols including for example, and without limitation, 5G, WIFI, NFC, miracast, among others. The aforementioned sensors and access control or payment processing devices and systems may automatically transfer transaction- or business operational data to the network nodes, as described above with reference toFIGS.3and4. In some embodiments, data platform510can dynamically select which servers520-522are authorized to store the data. For example, companies or governments may have geographical restrictions, encryption standards, network security standards, or other restrictions on the server nodes on which the blockchain is stored. Data platform510can therefore manage the logistics of dynamically selected servers based on these restrictions. For example, if a particular server is deemed to be under attack or hacked, then data platform510can dynamically remove that server from the blockchain network and consider adding one or more additional servers if needed. As such, each owner of the data can set selection criteria for where the data should be stored and the minimum IT standards needed for that server group.

Block diagram500further includes blockchains530-532. Blockchains530-532can contain a continuously growing list of records, called blocks, which are linked and secured using cryptography. Each of the block in blockchains530-532contains a timestamp and a hash. The hash includes both a cryptographic hash of the current block and a cryptographic hash of the previous block in the blockchain. Each block also contains data associated with a block entry. In this example scenario, each portion of data (Space, Customer, and Rate) have been separately recorded into a different block and in a separate blockchain530-532.

Additionally, each of blockchains530-532is associated with a separate access level. For example, blockchain530is a public access blockchain which allows any user interacting with the distributed ledger to view the blocks and data portions stored within each block. A public user may be any user interested in viewing parking spaces in one or more parking facilities that are available for the transaction in blockchain530and no privacy exists for this portion of data. Conversely, blockchain531is a private blockchain which data portions may only be accessed and viewed by authorized users, such as internal company personnel. In this example scenario, Customer has been separately stored on blockchain531and is private from all users interacting in the blockchain network except those with exclusive access to the data, such as managers within a company initiating the transaction. Blockchain532is a permissive blockchain meaning that a limited set of parties may view the data portions recorded in the block but not all users. Rate has been stored within blockchain532and may be view by parties who are allowed access to the data, such as auditors or controllers.

Record502is illustrative of what a user may view when requesting to view the transaction data stored in block entry501. Record502may contain all or none of the data portions originally entered in block entry501and is generated based on the authorization provided by the requesting user and access level each portion of data is associated with.

FIG.6illustrates a flow diagram in an implementation to generate a customized view of restricted transactions recorded into a blockchain for parking facility400business operations and customer usage. Some or all of the steps of view customization process600may be implemented in program instructions in the context of a component or components of the application used to carry out the customized view feature.

In operation, data platform510receives block entry501which is to be maintained in blocks of blockchains530-532(step601). Block entry501is requested by a user from a user device in the distributed network of nodes and contains the data portions. Data platform510then authorizes the entry (e.g., miners validate the hash in the block) (step602). If the block is not validated, the transaction (block entry501) is rejected (step603). However, if the block is accepted, each of the portions of data is evaluated for an access level and added to a block in each of blockchains530-532based on the identified access level (step604).

In a next operation, data platform510receives a request to view one or more data portions of a block entry wherein the request comprises an access code associated with at least one access level (step605). The access code may be associated with a public, permissive, or private access level. Data platform510then evaluates the access code in the request with each of blockchains530-532maintaining each of the separate block records for each of the data portions (step606). If the access code associated with the requesting user is determined to be public, a customized view (e.g., record502) will be generated for the requesting user indicating only Space from block entry501(step607). If the access code associated with the requesting user is determined to be permissive, a customized view will be generated for the requesting user indicating Space and Rate from block entry501(step608). If the access code associated with the requesting user is determined to be private, a customized view will be generated for the requesting user indicating all portions of the data from block entry501(i.e., Space, Customer, and Rate) (step609).

In some embodiments, block entry501further records additional data related to the parking facility transaction such as locations from where the customer initiated the transaction and the involved parking facility400, time and date stamps for transactions and vehicle entry and exit from facility400, and photos and/or videos of the vehicle entering, exiting, and moving about the facility400. In an example, in addition to being stored in block entry501, such imaging may include live streaming to a security monitoring station positioned at or remote from parking facility400. Additionally, or instead, cameras may monitor motion of vehicles in parking facility400as a security measure and store these data in block entry501and/or elsewhere as a security measure in a garage or parking facility/lot. These imaging systems for security purposes may be integrated in, or co-positioned with, sensors418. For example, a motion monitoring and imaging security protocol may be initiated in cases where a parked vehicle exhibits motion outside of the expected timeframe of the parking facility400stay of the vehicle.

FIG.7illustrates block diagram700in an implementation of an enhanced application to generate a customized view of restricted transactions recorded into a blockchain for hotel business operations and transactions including payment processing. Block diagram700includes inventory block entry701, data platform710, servers720-722, blockchains730-732, and record702.

Block entry701is representative of any data transaction that will be permanently recorded into the blockchain, such as those data received and recorded from hotel guests, connected devices, hotel, operators and staff, and external sources (e.g., key card readers, loyalty cards, and the like). Block entry701is subsequently processed by miners and added to a block at the end of the blockchain by data platform710. Block entry701further comprises portions of data which have been represented herein by Hotel Room, Hotel Guest, and Room Rate. Hotel Room maintains the inventory, and availability status, of hotel rooms in hotel. Hotel Guest includes data relating to the identifiers of the guest under whose name hotel room is registered and possibly also other guests associated with the registered guest, along with their account- and payment-related data. Room Rate includes data specifying the cost to staying in the hotel room, including on a nightly basis. It should be noted that while each of the data portions is represented separately, the portions of data are part of one transaction represented by block entry701. Block entry701may comprise any transaction or contract which has been executed and recorded in a distributed ledger platform environment for purposes of conducting hotel operations. In this example, block entry701may comprise an order, reservation, or spontaneous purchase request by a guest for use of a hotel room or related goods and services in the hotel. In some embodiments, a token may alternatively or instead comprise one or more of an order, reservation, or spontaneous purchase request by a guest for use of a hotel room or related goods or services in the hotel.

Data platform710represents any computing system or systems capable of hosting a blockchain application, of which controller2800inFIG.28is representative. Data platform710provides a secure distributed ledger system for recording hotel transactions and room availability statuses into the blockchains. Data platform710may be implemented across a multitude of distributed network nodes which may be accessed by a variety of users, such as tax auditors, financial institutions, regulatory authorities, guests and other hotel customers, hotel employees, hotel owners, hotel auditors, management and staff, marketing companies, advertisers and the like.

Data platform710can also include servers720-722. Servers720-722may be representative of any computing system or systems with which the distributed network nodes may communicate. Examples include other devices having corresponding applications or services installed thereon, such that an operating user of a user device may be able to transfer a transaction to be added to a blockchain and distributed amongst the network nodes of the distributed network. Examples include media servers, web servers, and other types of end-points that may transmit transaction data to or receive transaction data from user devices and network nodes using communication protocols including for example, and without limitation, 5G, WIFI, NFC, miracast, among others. 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 may automatically transfer transaction- or business operational data to the network nodes, as described above with reference toFIG.3. In some embodiments, data platform710can dynamically select which servers720-722are authorized to store the data. For example, companies or governments may have geographical restrictions, encryption standards, network security standards, or other restrictions on the server nodes on which the blockchain is stored. Data platform710can therefore manage the logistics of dynamically selected servers based on these restrictions. For example, if a particular server is deemed to be under attack or hacked, then data platform710can dynamically remove that server from the blockchain network and consider adding one or more additional servers if needed. As such, each owner of the data can set selection criteria for where the data should be stored, and the minimum IT standards needed for that server group.

Block diagram700further includes blockchains730-732. Blockchains730-732can contain a continuously growing list of records, called blocks, which are linked and secured using cryptography. Each of the block in blockchains730-732contains a timestamp and a hash. The hash includes both a cryptographic hash of the current block and a cryptographic hash of the previous block in the blockchain. Each block also contains data associated with a block entry. In this example scenario, each portion of data (Room, Guest, and Rate) have been separately recorded into a different block and in a separate blockchain730-732.

Additionally, each of blockchains730-732is associated with a separate access level. For example, blockchain730is a public access blockchain which allows any user interacting with the distributed ledger to view the blocks and data portions stored within each block. A public user may be any user interested in viewing hotel rooms in one or more hotels that are available for the transaction in blockchain730and no privacy exists for this portion of data. Conversely, blockchain731is a private blockchain which data portions may only be accessed and viewed by authorized users, such as internal company personnel. In this example scenario, Guest has been separately stored on blockchain731and is private from all users interacting in the blockchain network except those with exclusive access to the data, such as managers within a company initiating the transaction. Blockchain732is a permissive blockchain meaning that a limited set of parties may view the data portions recorded in the block but not all users. Rate has been stored within blockchain732and may be view by parties who are allowed access to the data, such as auditors or controllers.

Record702is illustrative of what a user may view when requesting to view the transaction data stored in block entry701. Record702may contain all or none of the data portions originally entered in block entry701and is generated based on the authorization provided by the requesting user and access level each portion of data is associated with.

FIG.8illustrates a flow diagram in an implementation to generate a customized view of restricted transactions recorded into a blockchain for hotel business operations and guest usage. Some or all of the steps of view customization process800may be implemented in program instructions in the context of a component or components of the application used to carry out the customized view feature.

In operation, data platform710receives block entry701which is to be maintained in blocks of blockchains730-732(step801). Block entry701is requested by a user from a user device in the distributed network of nodes and contains the data portions. Data platform710then authorizes the entry (e.g., miners validate the hash in the block) (step802). If the block is not validated, the transaction (block entry701) is rejected (step803). However, if the block is accepted, each of the portions of data is evaluated for an access level and added to a block in each of blockchains730-732based on the identified access level (step804).

In a next operation, data platform710receives a request to view one or more data portions of a block entry wherein the request comprises an access code associated with at least one access level (step805). The access code may be associated with a public, permissive, or private access level. Data platform710then evaluates the access code in the request with each of blockchains730-732maintaining each of the separate block records for each of the data portions (step806). If the access code associated with the requesting user is determined to be public, a customized view (e.g., record702) will be generated for the requesting user indicating only Room from block entry701(step807). If the access code associated with the requesting user is determined to be permissive, a customized view will be generated for the requesting user indicating Room and Rate from block entry701(step808). If the access code associated with the requesting user is determined to be private, a customized view will be generated for the requesting user indicating all portions of the data from block entry701(i.e., Room, Guest, and Rate) (step809).

In some embodiments, block entry701further records additional data related to the hotel room transaction such as locations from where the customer initiated the transaction and the involved hotel building, time and date stamps for transactions and guest(s) and/or their vehicle(s) entering and exiting hotel, and photos and/or videos of guest(s) and or their vehicle(s) entering, exiting, and moving about the hotel. In an example, in addition to being stored in block entry701, such imaging may include live streaming to a security monitoring station positioned at or remote from the hotel building. Additionally, or instead, cameras may monitor motion of guest(s) and/or their vehicle(s) in and around hotel as a security measure and store these data in block entry701and/or elsewhere as a security measure for the benefit of guests and hotel staff members. These imaging systems for security purposes may be integrated in or co-positioned with devices such as room key readers and entry and exit ways of parking, pool, fitness, casino, and other facilities of the hotel. For example, a motion monitoring and imaging security protocol may be initiated in cases where a person other than a registered guest attempts to gain entry to a guest room or other area of hotel that is intended for use only by registered hotel guests.

FIG.9illustrates block diagram900in an implementation of an enhanced application to generate a customized view of restricted transactions recorded into a blockchain for autonomous vehicle fleet business operations and transactions including payment processing. Block diagram900includes inventory block entry901, data platform910, servers920-922, blockchains930-932, and record902.

Block entry901is representative of any data transaction that will be permanently recorded into the blockchain, such as those data received and recorded from passengers requesting a ride, connected devices, autonomous vehicle fleet managers and staff, and external sources (e.g., GPS transceivers, key fobs, loyalty cards, and the like). Block entry901is subsequently processed by miners and added to a block at the end of the blockchain by data platform910. Block entry901further comprises portions of data which have been represented herein by Vehicle ID, Passenger, and Ride Price or Rate. Vehicle ID maintains the inventory, and availability status, of autonomous vehicles in a geographical area. Passenger includes data relating to the identifiers of the passenger under whose name an identified autonomous vehicle is requested, along with their account- and payment-related data. In some embodiments, Passenger further includes data to identify the requested destination of the passenger. Rate includes data specifying the cost of utilizing the autonomous vehicle by the passenger. In some embodiments, the rate to be charged is based on the mileage from a current location of passenger to the requested destination. It should be noted that while each of the data portions is represented separately, the portions of data are part of one transaction represented by block entry901. Block entry901may comprise any transaction or contract which has been executed and recorded in a distributed ledger platform environment for purposes of conducting autonomous vehicle fleet operations. In this example, block entry901may comprise an order, reservation, or spontaneous ride hailing request by a passenger for use of an autonomous vehicle or related services of the autonomous vehicle fleet operator. In some embodiments, a token may alternatively or instead comprise one or more of an order, reservation, or spontaneous ride hailing request by a passenger for use of an autonomous vehicle or related services of the autonomous vehicle fleet operator.

Data platform910represents any computing system or systems capable of hosting a blockchain application, of which controller2800inFIG.28is representative. Data platform910provides a secure distributed ledger system for recording autonomous vehicle fleet transactions along with autonomous vehicle locations and availability statuses into the blockchains. Data platform910may be implemented across a multitude of distributed network nodes which may be accessed by a 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, management and staff, marketing companies, advertisers and the like.

Data platform910can also include servers920-922. Servers920-922may be representative of any computing system or systems with which the distributed network nodes may communicate. Examples include other devices having corresponding applications or services installed thereon, such that an operating user of a user device may be able to transfer a transaction to be added to a blockchain and distributed amongst the network nodes of the distributed network. Examples include media servers, web servers, and other types of end-points that may transmit transaction data to or receive transaction data from user devices and network nodes using communication protocols including for example, and without limitation, 5G, WIFI, NFC, miracast, among others. Vehicle key fobs, key card readers, loyalty card receivers, and other useful devices and subsystems including locational (e.g., GPS) sensors and access control or payment processing devices and systems may automatically transfer transaction- or business operational data to the network nodes, as described above with reference toFIG.3.

In some embodiments, data platform910can dynamically select which servers920-922are authorized to store the data. For example, companies or governments may have geographical restrictions, encryption standards, network security standards, or other restrictions on the server nodes on which the blockchain is stored. Data platform910can therefore manage the logistics of dynamically selected servers based on these restrictions. For example, if a particular server is deemed to be under attack or hacked, then data platform910can dynamically remove that server from the blockchain network and consider adding one or more additional servers if needed. As such, each owner of the data can set selection criteria for where the data should be stored, and the minimum IT standards needed for that server group.

Block diagram900further includes blockchains930-932. Blockchains930-932can contain a continuously growing list of records, called blocks, which are linked and secured using cryptography. Each of the block in blockchains930-932contains a timestamp and a hash. The hash includes both a cryptographic hash of the current block and a cryptographic hash of the previous block in the blockchain. Each block also contains data associated with a block entry. In this example scenario, each portion of data (Vehicle, Passenger, and Rate) have been separately recorded into a different block and in a separate blockchain930-932.

Additionally, each of blockchains930-932is associated with a separate access level. For example, blockchain930is a public access blockchain which allows any user interacting with the distributed ledger to view the blocks and data portions stored within each block. For instance, a public user may be any user interested in viewing current locations of autonomous vehicles in the fleet currently available for ride hailing, along with any use restrictions particular vehicles may have at any point in time, that are available for the transaction in blockchain930and no privacy exists for this portion of data. Conversely, blockchain931is a private blockchain which data portions may only be accessed and viewed by authorized users, such as internal company personnel. In this example scenario, Passenger has been separately stored on blockchain931and is private from all users interacting in the blockchain network except those with exclusive access to the data, such as managers within a company initiating the transaction. Blockchain932is a permissive blockchain meaning that a limited set of parties may view the data portions recorded in the block but not all users. Rate has been stored within blockchain932and may be view by parties who are allowed access to the data, such as auditors or controllers.

Record902is illustrative of what a user may view when requesting to view the transaction data stored in block entry901. Record902may contain all or none of the data portions originally entered in block entry901and is generated based on the authorization provided by the requesting user and access level each portion of data is associated with.

FIG.10illustrates a flow diagram in an implementation to generate a customized view of restricted transactions recorded into a blockchain for autonomous vehicle fleet business operations and guest usage. Some or all of the steps of view customization process1000may be implemented in program instructions in the context of a component or components of the application used to carry out the customized view feature.

In operation, data platform910receives block entry901which is to be maintained in blocks of blockchains930-932(step1001). Block entry901is requested by a user from a user device in the distributed network of nodes and contains the data portions. Data platform910then authorizes the entry (e.g., miners validate the hash in the block) (step1002). If the block is not validated, the transaction (block entry901) is rejected (step1003). However, if the block is accepted, each of the portions of data is evaluated for an access level and added to a block in each of blockchains930-932based on the identified access level (step1004).

In a next operation, data platform910receives a request to view one or more data portions of a block entry wherein the request comprises an access code associated with at least one access level (step1005). The access code may be associated with a public, permissive, or private access level. Data platform910then evaluates the access code in the request with each of blockchains930-932maintaining each of the separate block records for each of the data portions (step1006). If the access code associated with the requesting user is determined to be public, a customized view (e.g., record902) will be generated for the requesting user indicating only Vehicle from block entry901(step1007). If the access code associated with the requesting user is determined to be permissive, a customized view will be generated for the requesting user indicating Vehicle and Rate from block entry901(step1008). If the access code associated with the requesting user is determined to be private, a customized view will be generated for the requesting user indicating all portions of the data from block entry901(i.e., Vehicle, Passenger, and Rate) (step1009).

In some embodiments, block entry901further records additional data related to the autonomous vehicle fleet transaction such as locations from where the passenger initiated the transaction and the involved vehicle, time and date stamps for transactions and passenger(s) and/or their assigned vehicle ID(s) entering and exiting the respective vehicle, and photos and/or videos of passenger(s) entering, exiting, and being transported by the assigned autonomous vehicle. In an example, in addition to being stored in block entry901, such imaging may include live streaming to a security monitoring station positioned at or remote from a building or facility of the autonomous vehicle fleet. Additionally, or instead, cameras may monitor motion of the autonomous vehicles carrying passengers en-route to their destinations as a security measure and store these data in block entry901and/or elsewhere as a security measure for the benefit of passengers and fleet staff members. These imaging systems for security purposes may be useful in the case of vehicle accidents or other incidents that involve the passengers or the assigned autonomous vehicles. In such cases, the customized view may be provided to police or insurance company investigators to provide useful data for resolving post-incident issues.

FIG.11illustrates block diagram1100in an implementation of an enhanced application to generate a customized view of restricted transactions recorded into a blockchain. Block diagram1100includes inventory block entry1101, data platform1110, servers1120-1122, blockchains1130-1132, and record1102.

Block entry1101is representative of any data transaction that will be permanently recorded into the blockchain. Block entry1101is subsequently processed by miners and added to a block at the end of the blockchain by data platform1110. Block entry1101further comprises portions of data which have been represented herein by Product, Buyer, and Price. It should be noted that while each of the data portions is represented separately, the portions of data are part of one transaction represented by block entry1101. Block entry1101may comprise any transaction or contract which has been executed and recorded in a distributed ledger platform environment. In this example, block entry1101may comprise a purchase order for inventory.

Data platform1110represents any computing system or systems capable of hosting a blockchain application, of which controller2800inFIG.28is representative. Data platform1110provides a secure distributed ledger system for recording transactions into the blockchains. Data platform1110may be implemented across a multitude of distributed network nodes which may be accessed by a variety of users, such as tax auditors, financial institutions, gaming regulation committees, customers, company employees, and the like.

Data platform1110can also include servers1120-1122. Servers1120-1122may be representative of any computing system or systems with which the distributed network nodes may communicate. Examples include other devices having corresponding applications or services installed thereon, such that an operating user of a user device may be able to transfer a transaction to be added to a blockchain and distributed amongst the network nodes of the distributed network. Examples include media servers, web servers, and other types of end-points that may transmit transaction data to or receive transaction data from user devices and network nodes. In some embodiments, data platform can dynamically select which servers1120-1122are authorized to store the data. For example, companies or governments may have geographical restrictions, encryption standards, network security standards, or other restrictions on the server nodes on which the blockchain is stored. Data platform1110can therefore manage the logistics of dynamically selected servers based on these restrictions. For example, if a particular server is deemed to be under attack or hacked, then data platform1110can dynamically remove that server from the blockchain network and consider adding one or more additional servers if needed. As such, each owner of the data can set selection criteria for where the data should be stored and the minimum IT standards needed for that server group.

Block diagram1100further includes blockchains1130-1132. Blockchains1130-1132can contain a continuously growing list of records, called blocks, which are linked and secured using cryptography. Each of the block in blockchains1130-1132contains a timestamp and a hash. The hash includes both a cryptographic hash of the current block and a cryptographic hash of the previous block in the blockchain. Each block also contains data associated with a block entry. In this example scenario, each portion of data (Product, Buyer, and Price) have been separately recorded into a different block and in a separate blockchain1130-1132.

Additionally, each of blockchains1130-1132is associated with a separate access level. For example, blockchain1130is a public access blockchain which allows any user interacting with the distributed ledger to view the blocks and data portions stored within each block. A public user may be any user interested in viewing the transaction in blockchain1130and no privacy exists for this portion of data. Conversely, blockchain1131is a private blockchain which data portions may only be accessed and viewed by authorized users, such as internal company personnel. In this example scenario, Buyer has been separately stored on blockchain1131and is private from all users interacting in the blockchain network except those with exclusive access to the data, such as managers within a company initiating the transaction. Blockchain1132is a permissive blockchain meaning that a limited set of parties may view the data portions recorded in the block but not all users. Price has been stored within blockchain1132and may be view by parties who are allowed access to the data, such as auditors or controllers.

Record1102is illustrative of what a user may view when requesting to view the transaction data stored in from block entry1101. Record1102may contain all or none of the data portions originally entered in block entry1101and is generated based on the authorization provided by the requesting user and access level each portion of data is associated with.

FIG.12illustrates a flow diagram in an implementation to generate a customized view of restricted transactions recorded into a blockchain. Some or all of the steps of view customization process1200may be implemented in program instructions in the context of a component or components of the application used to carry out the customized view feature.

In operation, data platform1110receives block entry1101which is to be maintained in blocks of blockchains1130-1132(step1201). Block entry1101is requested by a user from a user device in the distributed network of nodes and contains the data portions. Data platform1110then authorizes the entry (e.g., miners validate the hash in the block) (step1202). If the block is not validated, the transaction (block entry1101) is rejected (step1203). However, if the block is accepted, each of the portions of data is evaluated for an access level and added to a block in each of blockchains1130-1132based on the identified access level (step1204).

In a next operation, data platform1110receives a request to view one or more data portions of a block entry wherein the request comprises an access code associated with at least one access level (step1205). The access code may be associated with a public, permissive, or private access level. Data platform1110then evaluates the access code in the request with each of blockchains1130-1132maintaining each of the separate block records for each of the data portions (step1206). If the access code associated with the requesting user is determined to be public, a customized view (e.g., record1102) will be generated for the requesting user indicating only Product from block entry1101(step1207). If the access code associated with the requesting user is determined to be permissive, a customized view will be generated for the requesting user indicating Product and Price from block entry1101(step1208). If the access code associated with the requesting user is determined to be private, a customized view will be generated for the requesting user indicating all portions of the data from block entry1101(i.e., Product, Buyer, and Price) (step1209).

Another implementation for flow diagram1200may be in the context of a gambling validation process. For example, a user placing a bet on a large threshold win may require approval from casino managers. In this example scenario, access to the user's data in a blockchain may be required when a payout of the bet occurs to ensure that the bet was approved for the user by the casino manager.

FIG.13illustrates a block diagram in an alternative implementation of an enhanced application to generate a customized view of restricted transactions recorded into a blockchain. Block diagram1300includes gaming bet block entry1301, data platform1310, servers1320-1322, blockchain1330, access platform1340, and record1302.

Block entry1301is representative of any data transaction that will be permanently recorded into the blockchain. Block entry1301is subsequently processed by miners and added to a block at the end of the blockchain by data platform1310. Block entry1301further comprises portions of data which have been represented herein by a Bet Amount, Credit Card Number, and Age. It should be noted that while each of the data portions is represented separately, the portions of data are part of one transaction represented by block entry1301. Block entry1301may comprise any transaction or contract which has been executed and recorded in a distributed ledger platform environment. However, in this example, block entry1301comprises a gambling bet. It should also be noted that although requesting users, such as a third-party observer who is not a direct participant of the bet, may be able to view some data of blockchain1330, an access code may be required to view block entry1301. The access code may be in the form of a biometric validation.

Data platform1310represents any computing system or systems capable of hosting a blockchain application, of which controller2800inFIG.28is representative. Data platform1310provides a secure distributed ledger system for recording transactions into the blockchains. Data platform1310may be implemented across a multitude of distributed network nodes which may be accessed by a variety of users, such as auditors, financial institutions, gaming regulation committees, customers, company employees, and the like.

Data platform1310also includes servers1320-1322. Servers1320-1322may be representative of any computing system or systems with which the distributed network nodes may communicate. Examples include other devices having corresponding applications or services installed thereon, such that an operating user of a user device may be able to transfer a transaction to be added to a blockchain and distributed amongst the network nodes of the distributed network. Examples include media servers, web servers, and other types of end-points that may transmit transaction data to or receive transaction data from user devices and network nodes.

Block diagram1300further includes blockchain1330. Blockchain1330contains a continuously growing list of records, called blocks, which are linked and secured using cryptography. Each of the block in blockchain1330contains a timestamp and a hash. The hash includes both a cryptographic hash of the current block and a cryptographic hash of the previous block in the blockchain. Each block also contains data associated with a block entry. In this example scenario, each portion of data (Bet Amount, Credit Card Number, and Age) have been recorded into blockchain1330with a separate encryption code.

Additionally, each of the encryption codes associated with each of the data portions in blockchain1330is associated with a separate access level. For example, Bet Amount is associate with a public access encryption code which allows any user interacting with the distributed ledger to view the portion of data in the block. A public user may be any user interested in viewing the Bet Amount and no privacy exists for this portion of data. Conversely, Credit Card Number is associated with a private encryption code which may only be accessed and viewed by authorized users, such as the internal accounting department. Age is associated with a permissive encryption code which may be view by a limited set of parties but not all users. For example, Age may be required to be view by the gaming committee to ensure that all players are of a legal age to place the gambling bet. However, other players or observers of the bets may not be able to view the age of each player.

Access platform1340represents any computing system or systems capable of validating user request to access blockchain entry data, of which controller2800inFIG.28is representative. Access platform1340provides a secure encryption mediator between the portions of data recorded in blockchain1330and the generation of record1302for a requesting user. Access platform1340may be implemented across a multitude of distributed network nodes which may be accessed by a variety of users, such as tax auditors, financial institutions, gaming regulation committees, customers, company employees, and the like. Record1302is illustrative of what a user may view when requesting to view the transaction data stored in from block entry1301. Record1302may contain all or none of the data portions originally entered in block entry1301and is generated based on the authorization provided by the requesting user and access level each portion of data is associated with.

FIG.14illustrates a flow diagram in an implementation to generate a customized view of restricted transactions recorded into a blockchain. Some or all of the steps of view customization process1400may be implemented in program instructions in the context of a component or components of the application used to carry out the customized view feature.

In operation, data platform1310receives block entry1301which is to be maintained in blocks of blockchain1330(step1401). Block entry1301is requested by a user from a user device in the distributed network of nodes and contains the data portions. Data platform1310then authorizes the entry (e.g., miners validate the hash in the block) (step1402). If the block is not validated, the transaction (block entry1301) is rejected (step1403). However, if the block is accepted, each of the portions of data are evaluated for an access level and added to blockchain1330(step1404) along with an encryption code based on the identified access level (step1405).

In a next operation, access platform1340receives a request to view one or more data portions of a block entry wherein the request comprises an encryption code associated with at least one access level (step1406). The encryption code may be associated with a public, permissive, or private access level. Access platform1340then evaluates the encryption code in the request with each of the portion of data in blockchain1330(step1407). If the encryption code associated with the requesting user is determined to be public, a customized view (e.g., record1302) will be generated for the requesting user indicating only Bet Amount from block entry1301(step1408). If the encryption code associated with the requesting user is determined to be permissive, a customized view will be generated for the requesting user indicating Bet Amount and Age from block entry1301(step1409). If the encryption code associated with the requesting user is determined to be private, a customized view will be generated for the requesting user indicating all portions of the data from block entry1301(i.e., Bet Amount, Credit Card Number, and Age) (step1410).

FIG.15illustrates a block diagram in an alternative implementation of an enhanced application to generate a customized view of restricted transactions recorded into a blockchain. Block diagram1500includes monetary transfer block entry1501, data platform1500, servers1520-1522, blockchain1530, access platform1540, and record1502.

Block entry1501is representative of any data transaction that will be permanently recorded into the blockchain. Block entry1501is subsequently processed by miners and added to a block at the end of the blockchain by data platform1510. Block entry1501further comprises portions of data which have been represented herein by Parties to the Transaction, Bank Account Number, and Available Funds. It should be noted that while each of the data portions is represented separately, the portions of data are part of one transaction represented by block entry1501. Block entry1501may comprise any transaction or contract which has been executed and recorded in a distributed ledger platform environment. However, in this example, block entry1501comprises a banking transaction transferring money from one user's bank account to another user's bank account.

Data platform1510represents any computing system or systems capable of hosting a blockchain application, of which controller2800inFIG.28is representative. Data platform1510provides a secure distributed ledger system for recording transactions into the blockchains. Data platform1510may be implemented across a multitude of distributed network nodes which may be accessed by a variety of users, such as tax auditors, financial institutions, gaming regulation committees, customers, company employees, and the like.

Data platform1510also includes servers1520-1522. Servers1520-1522may be representative of any computing system or systems with which the distributed network nodes may communicate. Examples include other devices having corresponding applications or services installed thereon, such that an operating user of a user device may be able to transfer a transaction to be added to a blockchain and distributed amongst the network nodes of the distributed network. Examples include media servers, web servers, and other types of end-points that may transmit transaction data to or receive transaction data from user devices and network nodes.

Block diagram1500further includes blockchain1530. Blockchain1530contains a continuously growing list of records, called blocks, which are linked and secured using cryptography. Each of the block in blockchain1530contains a timestamp and a hash. The hash includes both a cryptographic hash of the current block and a cryptographic hash of the previous block in the blockchain. Each block also contains data associated with a block entry. In this example scenario, each portion of data (Parties, Account Number, and Available Funds) have been recorded into blockchain1530with a separate access level flag.

Additionally, each of the access level flags associated with each of the data portions in blockchain1530is associated with a separate access level. For example, Parties is associated with a public access flag which allows any user interacting with the distributed ledger to view the portion of data in the block. A public user may be any user interested in viewing the Parties to the Transaction and no privacy exists for this portion of data. Conversely, Account Number is associated with a private access flag which may only be accessed and viewed by authorized users, such as the transferring bank for each party. Available Funds is associated with a permissive access flag which may be view by a limited set of parties but not all users. For example, Available Funds may be required to be view by receiving bank to ensure that funds are available in the transferring account to complete the monetary transaction.

Access platform1540represents any computing system or systems capable of validating user request to access blockchain entry data, of which controller2800inFIG.28is representative. Access platform1540provides a secure access flag mediator between the portions of data recorded in blockchain1530and the generation of record1502for a requesting user. Access platform1540may be implemented across a multitude of distributed network nodes which may be accessed by a variety of users, such as tax auditors, financial institutions, gaming regulation committees, customers, company employees, and the like. Record1502is illustrative of what a user may view when requesting to view the transaction data stored in from block entry1501. Record1502may contain all or none of the data portions originally entered in block entry1501and is generated based on the authorization provided by the requesting user and access level each portion of data is associated with.

FIG.16illustrates a flow diagram in an implementation to generate a customized view of restricted transactions recorded into a blockchain. Some or all of the steps of view customization process1600may be implemented in program instructions in the context of a component or components of the application used to carry out the customized view feature.

In operation, data platform1510receives block entry1501which is to be maintained in blocks of blockchain1530(step1601). Block entry1501is requested by a user from a user device in the distributed network of nodes and contains the data portions. Data platform1510then authorizes the entry (e.g., miners validate the hash in the block) (step1602). If the block is not validated, the transaction (block entry1501) is rejected (step1603). However, if the block is accepted, each of the portions of data are evaluated for an access level and added to blockchain1530(step1604) along with an access flag based on the identified access level (step1605).

In a next operation, access platform1540receives a request to view one or more data portions of a block entry wherein the request comprises an access code associated with at least one access level (step1606). The access code may be associated with a public, permissive, or private access level. Access platform1540then evaluates the access code in the request with each of the portion of data in blockchain1530(step1607). If the access code associated with the requesting user is determined to be public, a customized view (e.g., record1502) will be generated for the requesting user indicating only Parties from block entry1501(step1608). If the access code associated with the requesting user is determined to be permissive, a customized view will be generated for the requesting user indicating Parties and Available Funds from block entry1501(step1609). If the access code associated with the requesting user is determined to be private, a customized view will be generated for the requesting user indicating all portions of the data from block entry1501(i.e., Parties, Account Number, and Available Funds) (step1610).

FIG.17illustrates an exemplary operational architecture1700in an implementation of a financial auditing scenario to generate a customized view of restricted transactions recorded into a blockchain. In operation, user1710transfers paycheck1730to user1720in exchange for services. A record of the transaction is transferred from user1710to database1740indicating the name of the service and the expense cost. The record is then maintained in blockchain1760via server1750. It should be noted that in this scenario, the transaction is also recorded on the receiving end by user1720where a record of the transaction indicating a profit and the service is transferred to database1742and maintained in blockchain1760via server1750.

In a next operation, government tax auditor1770requests to view the profit recorded for user1720. User1770may not be authorized to view the service recorded in the record or the expense from user1710. Server1750may receive the request and process an access code indicating that, at this point in time, user1770is only authorized to view the profit for user1720. A customized view of the record is then generated for user1770by server1750indicating only the profit for user1720. Although user1770is unable to see the full record of the transaction, user1770is able to trust that the portion of the record indicating the profit of user1720is valid since it has been maintained in blockchain1760.

FIG.18illustrates an alternative operational architecture1800in an implementation of a parking customer account and transaction tracking scenario to generate a customized view of restricted transactions recorded into a blockchain. In operation, user1810logged in to their account on a smartphone application submits an inquiry1830about whether spaces are available to park a vehicle1820in the parking facility400ofFIG.4. User1810enters their estimated time of arrival at the parking facility400entrance402and the estimated amount of time they will need to park their vehicle1820. According to the customer's account data, for example, the application associates the vehicle1820with the license plate number. A record of the estimated time in and time out and the license plate number of vehicle1820is transferred from user1810to database1840indicating the predicted duration for the parking transaction. The record is then maintained in blockchain1860via server1850. It should be noted that in this scenario, the arrival time transaction for the vehicle1820is also recorded on the receiving end by user1880where a record of the transaction indicating the estimate and the actual arrival time of vehicle1820is transferred to database1842and maintained in blockchain1860via server1850. In some embodiments, where the actual vehicle1820arrival time occurs after the estimated vehicle1820arrival time by a predetermined threshold amount of time (e.g., 5 minutes), user1810must reinitiate the inquiry in order to be assigned any available parking space in the parking facility400.

In a next operation, another parking customer, e.g., user1870requests to view the departure time and arrival time for the vehicle1820parked in a space preferred by user1870. User1870may not be authorized to view the license plate number for the vehicle1820. Server1850may receive the request and process an access code indicating that at this point in time, user1870is only authorized to view the predicted duration and available spaces recorded for vehicle1820and parking facility400, respectively. A customized view of the record is then generated for user1870by server1850indicating only the predicted duration and the available spaces.

FIG.19illustrates an alternative operational architecture1900in an implementation of a hotel guest account and transaction tracking scenario to generate a customized view of restricted transactions recorded into a blockchain. In operation, guest1910logged in to their account on a smartphone application submits an inquiry1930about whether rooms are available for a stay at hotel1920. Guest1910enters their desired check-in date at the hotel1920and the number of nights they will need to stay at hotel1920. According to the customer's account data, for example, the application associates the stay length data with the name of the guest making inquiry1930. A record of the check-in time and number of nights of the stay at hotel1920is transferred from guest1910to database1940. The record is then maintained in blockchain1960via server1950. It should be noted that in this scenario, the check-in time transaction for the hotel1920is also recorded on the receiving end by user1980where a record of the transaction indicating the estimate and the actual arrival time of guest1910at hotel1920is transferred to database1942and maintained in blockchain1960via server1950. In some embodiments, where the actual hotel1920check-in time occurs after the estimated hotel1920arrival time by a predetermined threshold amount of time (e.g., 18 hours), guest1910must reinitiate the inquiry1930in order to be assigned any available hotel rooms in the hotel1920.

In a next operation, another hotel1920customer, e.g., guest1970, requests to view the departure date and time for the hotel1920room presently occupied by guest1910but preferred by guest1970. Guest1970may not be authorized to view the name of guest1910. Server1950may receive the request and process an access code indicating that, at this point in time, guest1970is only authorized to view the predicted check-out date and time, along with other available rooms at hotel1920. A customized view of the record is then generated for guest1970by server1950indicating only these data, but not the name of guest1910.FIG.20illustrates an alternative operational architecture2000in an implementation of an autonomous vehicle fleet passenger account and transaction tracking scenario to generate a customized view of restricted transactions recorded into a blockchain. In operation, passenger2010logged in to their account on a smartphone application submits an inquiry2030about whether an autonomous vehicle2020is available from fleet2032for a ride at a certain time and to a desired destination. Passenger2010enters their desired pick up date and time at a specified location that is served by an autonomous vehicle fleet2032, along with their requested ride destination. According to the customer's account data, for example, the application associates the ride request-related data with the name of the passenger making inquiry2030. A record of this ride request data is transferred from passenger2010to database2040. The record is then maintained in blockchain2060via server2050. It should be noted that in this scenario, the ride request data for the autonomous vehicle2020is also recorded on the fleet2032receiving end by user2080, where a record of the transaction indicating the requested vehicle2020, pick up time and location, and passenger2010destination is transferred to database2042and maintained in blockchain2060via server2050. In some embodiments, where the passenger2010is not present at the pre-arranged pick up location and a predetermined period of time elapses (e.g., 10 minutes after the pre-arranged pick up time), passenger2010must reinitiate the inquiry2030in order to be assigned any available autonomous vehicles2020from fleet2032.

In a next operation, another fleet2032customer, e.g., passenger2070, requests to view the time and date when the autonomous vehicle2020presently in the service of passenger2010, but preferred by passenger2070, will be available again for hire. Passenger2070may not be authorized to view the name of passenger2010. Server2050may receive the request and process an access code indicating that, at this point in time, passenger2070is only authorized to view the predicted vehicle2020availability date and time, along with other available vehicles of fleet2032. A customized view of the record is then generated for passenger2070by server2050indicating only these data, but not the name of passenger2010.

FIG.21illustrates an alternative operational architecture2100in an implementation of a gaming regulation scenario to generate a customized view of restricted transactions recorded into a blockchain. In operation, user2110signs sports bet2130with user2120. A record of sports bet2130is transferred from the users to database2140indicating the predicted teams and the driver's license number of users2110-2120. The record is then maintained in blockchain2160via server2150. It should be noted that in this scenario, the transaction also initiates a transfer from sports scoring committee2132to database2142indicating the official score of the game. The official score of the game is transferred to database2142and maintained in blockchain2160via server2150.

In a next operation, sporting bet management user2170may request to see the predicted results along with the official score of the game from blockchain2160. User2170may not be authorized to view the driver's licenses of each of users2110-2120. Server2150may receive the request and process an access code indicating that at this point in time, user2170is only authorized to view the predicted results of each of users2110-2120and the official score. A customized view of the record is then generated by server2150indicating only the predicted results and the official score for user2170. Although user2170is unable to see the full record of the transaction, user2170is able to trust that the portion of the record indicating that users2110-2120have a valid driver's license on file since this data has been maintained in blockchain2160.

FIG.22illustrates an alternative operational architecture2200in an implementation of an inventory tracking scenario to generate a customized view of restricted transactions recorded into a blockchain. In operation, user2210transfers cargo of packages2230to user2220to be delivered to various users, including user2270tracking Package A. A record of the departure time transaction for cargo of packages2230is transferred from user2210to database2240indicating the departure time of Package A and Package B. The record is then maintained in blockchain2260via server2250. It should be noted that in this scenario, the arrival time transaction for cargo of packages2230is also recorded on the receiving end by user2220where a record of the transaction indicating the arrival time of Package A and Package B is transferred to database2242and maintained in blockchain2260via server2250.

In a next operation, user tracking Package A2270requests to view the departure time and arrival time recorded for Package A. User2270may not be authorized to view the departure time and arrival time recorded for Package B. Server2250may receive the request and process an access code indicating that, at this point in time, user2270is only authorized to view the departure time and arrival time recorded for Package A. A customized view of the record is then generated for user2270by server2250indicating only departure time and arrival time recorded for Package A.

Referring again toFIG.18, the inventory tracking scenario ofFIG.22implements or otherwise makes use of the blockchain and the disclosed systems and methods in a similar fashion as the parking facility case. In the latter case, the product is a parking space in the parking facility and the inventory being tracked are the numbers and locations of available parking spaces. The blockchain may be utilized according to the disclosed systems and methods to improve the efficiencies and customer experiences for business operations where the timing of delivery of a product or service is important to customers and providers of the product or service. In the parking case presented inFIG.18, for example, obtaining the predicted duration of the customer's parking request based on their anticipated time in and time out to and from the parking facility400enables the operator to meet their customers' needs while effectively making the most of the parking space inventory to maximize revenues. In cases where an operator has more than one parking facility in a city, for instance, the inventory across the facilities may be leveraged to the same ends. Similarly, for the inventory tracking scenario ofFIG.22(e.g., a retail store operation having multiple store locations in an area), the disclosed systems and methods, operators and their customers may have access to real time data regarding present locations and available quantities of particular products (including while they are in transit) and thereby enjoy heightened convenience and increased sales flowing therefrom.

FIG.23illustrates an exemplary customized view of restricted transaction recorded into a blockchain.FIG.23includes computing system2301comprises one or more devices capable of running a blockchain application natively or in the context of a web browser, streaming an application, or executing an application in any other manner. Computing system2301may include various hardware and software elements in a supporting architecture suitable for generating a customized view of a parking transaction record. One such representative architecture is illustrated inFIG.28with respect to controller2800.

Computing system2301also includes blockchain application component2302capable of maintaining a complete record of the blockchain transactions in accordance with the processes described herein. User interface2303includes customized view2310which may be produced by blockchain application component. User interface2303may display in the customized view2310portions of data from a block entry which a user is authorized to view. The user may initially only have access to view public portions of the block entry, such as the license plate numbers a subset of vehicles parked or planning to park at the parking facility400.

An encryption code may then be transferred in a request to view permissive portions of data. Once computing system2301verifies the encryption code, permissive portions of data may be added to customized view2310. The permissive portions of data include the names and portrait images of each customer associate with the vehicles in the subset. However, the parking spaces currently occupied by each of the customers in the subset may remain private and therefore, the user will be unable to view the parking space data in customized view2310.

FIG.24illustrates an alternative exemplary customized view2400of restricted transaction recorded into a blockchain.FIG.24includes server node2401storing a copy of blockchain2402. Blockchain2402stores blocks which have been chained using hash codes, such as blocks2410and2412. Each block contains transactions which may be further broken down into portions of data. For example, block2412stores an up-to-date, real-time tally2420of parking transactions at the parking facility400ofFIG.4. Tally2420includes names of each of the customers, a license plate number for each customer's vehicle, a month-to-date amount of money spent (or an indication of a parking subscription plan held) by each customer on parking, and an identifier of a parking space in parking facility400in which the customer's vehicle is presently parked. It should be noted that additional data may also be included in block2412, such as month-to-date ancillary services used, and an amount of money spent on such services at the parking facility400.

In a use case corresponding to the example illustrated inFIG.24, one of the customers in tally2420(e.g., Mary) is a parking account owner, and the remaining customers shown in tally2420are authorized users of Mary's account. In the use case, Mary and Ed are divorced ex-spouses and Mary is responsible for paying all of Ed's parking costs at the parking facility400for any reason whatsoever. Mary pays for her daughter Jess's parking costs for purposes of attending college classes near the parking facility400. For each user accessing restricted parking records, a check mark is included to indicate which portions of data may be viewed by each of the users (e.g., Mary, Ed, and Jess). For example, Mary is accessing the month-to-date parking transaction history using mobile device2430. In this example scenario, Mary is authorized to view each of the names of the authorized users (Ed and Jess) and the usage dollar amounts since Mary is responsible for paying those amounts to the parking facility400. 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 settlement, Mary may not have any ability to track Ed's whereabouts. Thus, Mary does not have access to Ed's license plate number or presently occupied parking space in parking facility400. As can be seen in the customized view displayed on mobile device2430, Mary views authorized data portions2440and is blocked from viewing unauthorized data portions2441.

FIG.25illustrates an exemplary customized view of restricted transaction recorded into a blockchain.FIG.25includes computing system2501comprises one or more devices capable of running a blockchain application natively or in the context of a web browser, streaming an application, or executing an application in any other manner. Computing system2501may include various hardware and software elements in a supporting architecture suitable for generating a customized view of a payroll transaction record. One such representative architecture is illustrated inFIG.28with respect to controller2800.

Computing system2501also includes blockchain application component2502capable of maintaining a complete record of the blockchain transactions in accordance with the processes described herein. User interface2503includes customized view2510which may be produced by blockchain application component. User interface2503may display in the customized view2510portions of data from a block entry which a user is authorized to view. The user may initiate initially only have access to view public portions of the block entry, such as the name of each employee who is on the payroll.

An encryption code may then be transferred in a request to view permissive portions of data. Once computing system2501verifies the encryption code, permissive portions of data may be added to customized view2510. The permissive portions of data include the wages and birthdates of each employees on the payroll transaction. However, the social security numbers of each of the employees may remain private and therefore, the user will be unable to view the social security data in customized view2510.

FIG.26illustrates an alternative exemplary customized view of restricted transaction recorded into a blockchain.FIG.26includes server node2601storing a copy of blockchain2602. Blockchain2602stores blocks which have been chained using hash codes, such as blocks2610and2612. Each block contains transactions which may be further broken down into portions of data. For example, block2612stores online poker game bet entry2620. Bet entry2620includes names of each of the players, a bet amount for each of the players, an amount of funds each player has available to make the bet, and a player rank index. It should be noted that additional data may also be included in block2612, such as game statistics, win/loss percentages, etc.

For each user access the bet entry, a check mark is included to indicate which portions of data may be viewed by each of the users. For example, Sue is accessing the poker game bet entry using mobile device2630. In this example scenario, Sue is authorized to view each of the names of the players and the bet amounts since the names and bet amounts are accessible to the public. Sue is also allowed private access to her own funds amount and rank. However, Sue does not have access to the available funds and rank of the other players. As can be seen in the customized view displayed on mobile device2630, Sue views authorized data portions2640and is blocked from viewing unauthorized data portions2641.

FIG.27illustrates an alternative operational architecture in an implementation of a data access system capable of providing a customized view of restricted or sensitive data recorded into a blockchain. As illustrated inFIG.27, users2710A-2710N can use various electronic devices to request access to a document, electronic record, physical location (e.g., safe, room, building, area, etc.), or information. For example, in accordance with various embodiments users2710A-2710N may have difference access levels such as security clearance that grants the user access to classified information (e.g., state or organizational secrets) or to restricted areas. Typically, a security clearance (e.g., classified, secret, top secret, etc.) is not sufficient to gain access to all documents and/or data. Instead, the individual must also have a need to know the specific information.

The request can be submitted to access control framework2720which can translate and validate the requests from different systems (e.g., application, key card system, fingerprint readers, biometric devices, passwords, multi-factor authentication, and the like). Upon validation, the access control framework can submit the request to security applicator2730which can process the request using various security protocols. For example, the security level of the requests document or location may require additional multiple validations (e.g., password and hardware device, biometrics, location verification, PINs, passwords, etc.). Security application, in some embodiments, may pull this information from a field or metadata within a block on a blockchain associated with the data.

The document or data2750A-2750B stored in blockchain2740may have different fields or portions that can be accessed by different individuals with differing “needs to know” or access levels (e.g., a compliance officer vs. a lower level employee of a company, individual with higher security clearance level vs. one with a lower security clearance level, etc.). For example, in some embodiments, various redaction mappings may be stored in the blockchain and applied by document generator2760before being presented to users2710A-2710N. As such, two users requesting the same document or data may be presented with different results.

As an example, a freedom of information access request may yield redacted documents which have been deemed as available to the public while an individual with security clearance and a need to know will be presented with a different level of access. In accordance with various embodiments an initial request may be received from a user. The system can identify the information that is compliant with the request and set a timer period for responding to the request (e.g., 30 days) to the FOIA request. The system can then determine whether each piece of information compliant with the request has any classification restrictions. If any of the information is determined to be unrestricted (e.g., no classification levels), then the system can respond to the user who made the request with a response that includes information without inspection. This type of feature reduces the workload of governmental employees and ensures that the time period for response is met (e.g., by prioritizing and reassigning review among employees). In some embodiments, if enough time remains, the system may request a human review and approve the included information before sending.

When the system identifies confidential information, the system would next evaluate the access and clearance. If for example, the person requesting the data had a higher access/clearance than an administrator, then the information would be automatically sent. If redactions need to be made to comply with the security clearance, then document generator2760may apply any redactions needed and/or remove documents that should not be included in the response. While not illustrated inFIG.27, some embodiments may include a machine learning/artificial intelligence component to review the data and/or metadata and identify portions that should not be included.

Other embodiments may have other types of individuals seeking varying information (e.g., people seeking information on a gambler, a banking client, regulators performing audits, etc.). Many such use cases exist. Also, some embodiments may use decentralized applications (Dapps) that have backend code running on a decentralized peer-to-peer network to submit the request, retrieve information from the blockchains, and communicate with other applications (e.g., other Dapps).

Security applicator2730may also review the status of the credentials or security level of the user. The record of the user may be stored on blockchain2745. For example, information regarding background checks, bank account information, travel information, projects the user is associated with (past and present), family history, medical history, credentials, biometrics, passwords, signatures, and the like can be stored on in the user's record. Security applicator2730may retrieve that information and utilize the information in generating the customized view of the data or document.

FIG.28illustrates a block diagram illustrating an example machine representing the computer systemization of the host computer system. Controller2800may be in communication with entities including one or more users2825client/terminal devices2820, user input devices2805, peripheral devices2810, optional co-processor device(s) (e.g., cryptographic processor devices)2815, and networks2830. Users may engage with controller2800via terminal devices2820over networks2830. In some embodiments, all or a portion of the communications between terminal devices2820and controller2800can be encrypted. Various laws, standards, or best practices may require cryptography for storing, transmitting, and/or utilization of various types data, information, code, signaling, etc.

Computers may employ central processing units (CPUs) or processors to process information. Processors may include programmable general-purpose or special-purpose microprocessors, programmable controllers, application-specific integrated circuits (ASICs), programmable logic devices (PLDs), embedded components, a combination of such devices and the like. Processors execute program components in response to user and/or system-generated requests. One or more of these components may be implemented in software, hardware or both hardware and software. Processors pass instructions (e.g., operational and data instructions) to enable various operations.

Controller2800may include clock2865, CPU2870, memory such as read only memory (ROM)2885and random access memory (RAM)2880and co-processor2875among others. These controller components may be connected to a system bus2860, and through the system bus2860to an interface bus2835. Further, user input devices2805, peripheral devices2810, co-processor devices2815, and the like, may be connected through the interface bus2835to the system bus2860. The interface bus2835may be connected to a number of interface adapters such as processor interface2840, input output interfaces (I/O)2845, network interfaces2850, storage interfaces2855, and the like.

Processor interface2840may facilitate communication between co-processor devices2815and co-processor2875. In one implementation, processor interface2840may expedite encryption and decryption of requests or data. Input output interfaces (I/O)2845facilitate communication between user input devices2805, peripheral devices2810, co-processor devices2815, and/or the like and components of controller2800using protocols such as those for handling audio, data, video interface, wireless transceivers, or the like (e.g., Bluetooth®, IEEE 894a-b, serial, universal serial bus (USB), Digital Visual Interface (DVI), 802.11a/b/g/n/x, cellular, etc.). Network interfaces2850may be in communication with the network2830. Through the network2830, controller2800may be accessible to remote terminal devices2820. Network interfaces2850may use various wired and wireless connection protocols such as, direct connect, Ethernet, wireless connection such as IEEE 802.11a-x, miracast and the like. Some components of the interactive gaming system may include various protocols or comply with various standards or certifications set forth by different associations or regulatory agencies. For example, some embodiments may use the slot accounting system (SAS) protocol or comply with the game to system (G2S) standard.

Examples of network2830include the Internet, Local Area Network (LAN), Metropolitan Area Network (MAN), a Wide Area Network (WAN), wireless network (e.g., using Wireless Application Protocol WAP), a secured custom connection, and the like. The network interfaces2850can include a firewall which can, in some aspects, govern and/or manage permission to access/proxy data in a computer network, and track varying levels of trust between different machines and/or applications. The firewall can be any number of modules having any combination of hardware and/or software components able to enforce a predetermined set of access rights between a particular set of machines and applications, machines and machines, and/or applications and applications, for example, to regulate the flow of traffic and resource sharing between these varying entities.

The firewall may additionally manage and/or have access to an access control list which details permissions including, for example, the access and operation rights of an object by an individual, a machine, and/or an application, and the circumstances under which the permission rights stand. Other network security functions performed or included in the functions of the firewall, can be, for example, but are not limited to, intrusion-prevention, intrusion detection, next-generation firewall, personal firewall, etc., without deviating from the novel art of this disclosure. It should be appreciated that controller2800may be capable of using network interfaces2850to transfer and receive payment amounts. The payment may be driven by an application executed by controller2800, such as a National Fighting Club (NFC) application tap using Bluetooth® 2855 may be in communication with a number of storage devices such as, storage devices2890, removable disc devices, and the like. The storage interfaces2855may use various connection protocols such as Serial Advanced Technology Attachment (SATA), IEEE 894, Ethernet, Fiber, Universal Serial Bus (USB), and the like.

User input devices2805and peripheral devices2810may be connected to I/O interface2845and potentially other interfaces, buses and/or components. User input devices2805may include card readers, fingerprint readers, joysticks, keyboards, microphones, mouse, remote controls, retina readers, touch screens, sensors, and/or the like. Peripheral devices2810may include antenna, audio devices (e.g., microphone, speakers, etc.), cameras, external processors, communication devices, radio frequency identifiers (RFIDs), scanners, printers, storage devices, transceivers, and/or the like. Co-processor devices2815may be connected to controller2800through interface bus2835, and may include microcontrollers, processors, interfaces or other devices.

Computer executable instructions and data may be stored in memory (e.g., registers, cache memory, random access memory, flash, etc.) which is accessible by processors. These stored instruction codes (e.g., programs) may engage the processor components, motherboard and/or other system components to perform desired operations. Controller2800may employ various forms of memory including on-chip CPU memory (e.g., registers), RAM2880, ROM2885, and storage devices2890. Storage devices2890may employ any number of tangible, non-transitory storage devices or systems such as fixed or removable magnetic disk drive, an optical drive, solid state memory devices and other processor-readable storage media. Computer-executable instructions stored in the memory may include an interactive gaming platform having one or more program modules such as routines, programs, objects, components, data structures, and so on that perform particular tasks or implement particular abstract data types. For example, the memory may contain operating system (OS) component2895, modules and other components, database tables, and the like. These modules/components may be stored and accessed from the storage devices, including from external storage devices accessible through an interface bus2835.

The database components can store programs executed by the processor to process the stored data. The database components may be implemented in the form of a database that is relational, scalable and secure. Examples of such database include DB2, MySQL, Oracle, Sybase, and the like. Alternatively, the database may be implemented using various standard data-structures, such as an array, hash, list, stack, structured text file (e.g., XML), table, and/or the like. Such data-structures may be stored in memory and/or in structured files.

Controller2800may be implemented in distributed computing environments, where tasks or modules are performed by remote processing devices, which are linked through a communications network, such as a Local Area Network (“LAN”), Wide Area Network (“WAN”), the Internet, and the like. In a distributed computing environment, program modules or subroutines may be located in both local and remote memory storage devices. Distributed computing may be employed to load balance and/or aggregate resources for processing. Alternatively, aspects of controller2800may be distributed electronically over the Internet or over other networks (including wireless networks). Those skilled in the relevant art(s) will recognize that portions of the interactive gaming system may reside on a server computer, while corresponding portions reside on a client computer. Data structures and transmission of data particular to aspects of controller2800are also encompassed within the scope of the disclosure.

FIG.29illustrates an exemplary operational architecture2900in an implementation of a financial auditing scenario to generate a customized view of restricted transactions recorded into a blockchain that can be used as a basis to automatically fulfill tax payment obligations to government entities2910. In operation, as discussed with respect toFIG.17, records of transactions and earnings can be maintained as restricted transactions in blockchain1760via server1750. It should be noted that in this scenario, financial aspects (i.e., earnings) associated with the transactions can be reported to an auditor1770from blockchain1760. A government tax auditor1770can also request to view the profit recorded for income earning entities (e.g., parking, hotel, gaming, services) etc.

In addition to access of financial information by user1770(e.g., tax auditor) as previously described with respect toFIG.17and here, the blockchain1760can be programmed to automatically (e.g., in real time) or periodically (e.g., daily, weekly, bi-weekly, monthly, quarterly) pay taxes to government entities2910entitled to receive tax (e.g., federal, state, local government) based on an income earning entity's earnings. The desired payments schedule can depend on real time earning and tax determinations by a server and/or artificial intelligence engine that is then recorded into the blockchain. Real time earnings and tax determinations can also enable government entities with real time auditability of the financial aspects of transactions. Payment of taxes based on earning can be provided via fiat or by cryptocurrency such as a stable token2930designed for the payment of taxes. Payments of tax onto the government tax departments or authorities can be via a batch payments that are compiled and paid daily, bi-weekly, weekly or monthly. The desired payments schedule would depend on real time earning and tax determinations by the server1750that is then recorded into the blockchain1760. Payments and payment scheduling can be enabled on the blockchain via smart contracts. Real time earnings and tax determinations can also enable government entities with real time auditability of the financial aspects of transactions. An artificial intelligence engine2940can also be provided to review entries within the blockchain1760, identify earnings information associated with the sales of the commercial inventory, determine tax based on earning information, and pay tax to government authorities2910based on earnings information. Earnings- and tax-related information can be segregated2950on the blockchain for government auditing purposes.

Certain inventive aspects may be appreciated from the foregoing disclosure, of which the following are various examples.

The functional block diagrams, operational scenarios and sequences, and flow diagrams provided in the Figures are representative of exemplary systems, environments, and methodologies for performing novel aspects of the disclosure. While, for purposes of simplicity of explanation, methods included herein may be in the form of a functional diagram, operational scenario or sequence, or flow diagram, and may be described as a series of acts, it is to be understood and appreciated that the methods are not limited by the order of acts, as some acts may, in accordance therewith, occur in a different order and/or concurrently with other acts from that shown and described herein. Those skilled in the art will understand and appreciate that a method could alternatively be represented as a series of interrelated states or events, such as in a state diagram. Moreover, not all acts illustrated in a methodology may be required for a novel implementation.