Patent Application
20210319436
This invention relates to a system and method for managing users in a in a decentralized and distributed blockchain networking environment. Decentralization requires management of resources to ensure scalability and network performance. This invention relates to a system and method to ensure ease of scalability and network physical growth without sacrificing network performance or otherwise limiting network speed and accessibility. This invention also relates to creation and management of a user wallet private key within a decentralized network setting such as a blockchain and decentralized distributed database.
Another aspect of this invention relates to a system and method for utilizing and adjusting restrictions that govern the movement of cryptocurrencies and digital tokens that are stored in a digital wallet within a blockchain environment. More specifically, this aspect of the invention relates to allowing a provisioner of blockchain tokens or network administrator to impose and adjust restrictions applied to an application specific internal wallet based on selected parameters that automatically trigger an adjustment in at least a portion of the applied restrictions, or to manually adjust the restrictions.
Centralized networking configurations can be balanced by adding resources at the centralized location, for example, by adding more servers, more processing power and the like. Decentralization presents a different problem as decentralized networks often feature fewer resources, such as network nodes, resulting in large areas of coverage. Therefore, a need exists to better manage existing resources to attain a balance between network scalability and network access and performance.
Further, existing private key management protocols typically force centralized storage for management and control of keys. Therefore, a need exists to enable decentralized key management systems without sacrificing access and usability while ensuring both privacy and security of the user keys.
Further, as is known in the art, blockchains typically utilize digital currency or blockchain tokens as a tool to enable transactions for products and/or services within the specific blockchain network itself. As used herein, a token or blockchain token refers to any type of token on a blockchain, and is meant to include any token or terminology that connotes a token that is supported by a blockchain that is digitally transferrable, such as digital tokens, cryptocurrency tokens, cryptographic tokens, security tokens, and utility tokens. Typically, transaction records of blockchain tokens are recorded on a blockchain. A cryptocurrency is one example of a blockchain token. As is commonly understood, unless otherwise specifically noted, a blockchain token is understood to be both singular and plural, and may refer to entire tokens or to one or more fractional pieces of a whole token. Digital currencies or tokens (including, as just mentioned, fractions thereof) are also commonly bought, sold and traded on cryptocurrency exchanges. In blockchain environments, where tokens and digital currency are used to power applications that reside on the specific blockchain (for example, tokens commonly referred to as utility tokens), it may be advantageous to restrict the usage of at least some of the tokens. For example, some tokens may be restricted so that they can only be used in one or more applications that reside on the blockchain. Restrictions may include preventing certain tokens from being bought, sold, or traded on a cryptocurrency exchange. Token movement may be restricted, for example, in order to comply with regulations applicable to digital tokens. For example, a token issuer may seek to restrict tokens to certain uses, at least on a temporary basis, to ensure that the issuer complies with government regulations such as securities laws. Therefore, a need exists to be able to restrict the usage of at least a portion of the tokens on a blockchain to certain uses.
Moreover, it may be desirable to alter the restrictions that have been implemented. From a regulatory standpoint, it may be that once a certain amount of time passes or certain milestones are reached with respect to the network or the usage of tokens, restrictions may no longer be necessary. In addition, regulations may change over time. Further, the restrictions that are implemented may be undesirable. Thus, a need exists to be able to alter restrictions that have been put in place to adjust to real-time changes. A further need exists to have the ability to set parameters that will automatically trigger the tightening or lessening of imposed restrictions, and to allow for the manual adjustment of restrictions.
The system and method discussed herein manages network resources by moving resource users to areas of the network where resources are more readily available. The system and method further includes a network-based private key management system enabling transactions to be executed without the need for the user wallet to host a private key. Further, the system discussed herein includes a wallet that allows for restrictions to be imposed on a wallet or on tokens themselves and also to be adjusted either automatically depending on certain parameters or else manually by a provisioner, administrator, or other user with appropriate permission.
From the discussion that follows, it will become apparent that the present invention addresses the deficiencies associated with the prior art while providing additional advantages and benefits not contemplated or possible with prior art constructions.
An Autonomous eXchange via Entrusted Ledger blockchain (hereinafter “AXEL”) is described herein. AXEL is a distributed blockchain network that utilizes a suite of unique smart contracts to facilitate the transfer, storage, sharing, and streaming of digital content through the network enabling trust to be established between nodes while providing private transaction capabilities for participants within the AXEL blockchain. While the following disclosure provides an example of the AXEL blockchain in a decentralized network configuration, the AXEL blockchain can easily be configured to support centralized architectures in both public, private, and hybrid deployment configurations.
AXEL is intended to provide a networking environment wherein transactions that occur between parties can be done in a private setting while still enabling the network trust element of a publicly available ledger. AXEL utilizes a unique public and private chain (ledger) approach to decentralized computing wherein the details of transactions that occur between parties remain hidden from public view. In one preferred embodiment, a file can be transferred between a first and a second user. The transaction record of the file transfer will appear in detail on the private ledger of both the first and the second user. Witnesses to this transaction can execute the consensus algorithm to ensure that the transaction has occurred and has been verified, but the user hosting a node that is a witness will not know or have visibility to the details of the actual transaction. This enables the first and second user to maintain the privacy of their transaction while still enabling the blockchain to witness and verify the transaction to ensure authentication and accuracy.
AXEL provides participants with the capability of managing digital content in a blockchain environment. In this example, the storage, transfer, sharing, and streaming capabilities are controlled directly by the user and not through a centralized control mechanism.
The AXEL blockchain may include a utility token mechanism that enables users to create a commerce capability wherein they may trade access or download rights to digital content they own and manage within AXEL in exchange for utility tokens.
In one embodiment, the AXEL blockchain enables a user of a computing device (e.g. personal computer, smartphone, tablet, etc.) to access and manage any digital content located on the subject device (either from that same device or through another device) and provide access to the content through the AXEL blockchain. This embodiment may, in one advantageous configuration, work in conjunction with the PINApp (Pervasive Intermediate Network Attached Storage Application) platform, which is described in U.S. Pat. No. 9,792,452 to enable access and management of digital content.
As one example of the use of AXEL, an AXEL user such as a healthcare provider may wish to transfer patient records privately and securely through AXEL to a health insurance provider. The healthcare provider may select the patient records they wish to transfer and initiate the exchange to the insurance provider. The insurance provider would receive the subject patient records and acknowledge receipt through AXEL.
The transaction in the scenario above is witnessed by a randomly selected group of nodes running a witness consensus algorithm against the subject transaction. Using a consensus algorithm, witnesses reach a consensus and resolve the transaction. As the consensus is completed, the healthcare providers' private blockchain (ledger) will be updated with a block showing the transaction that occurred with the insurance provider. In a similar fashion, the insurance providers' private blockchain (ledger) would also be updated with a block that mirrored the block created for the healthcare provider. These mirror blocks would appear on the subject blockchains (ledgers) of each party participating in a transaction. The witness parties' private blockchains (ledgers) would also contain a mirror block reflecting the transaction that they witnessed.
At the conclusion of the subject transaction in the example above, each participating party (healthcare provider, insurance provider, and witnesses) would automatically update their private blockchains (ledgers) to their alpha blocks associated with each user. The updates to the alpha blocks would contain a verification that the transaction was witnessed and that it was successfully authenticated and verified, validating the subject transaction. In the interest of privacy, the updates to the alpha blocks associated with the transaction would not contain any details of the transaction that took place that are visible to users outside of the immediate transaction other than that the transaction was witnessed, authenticated, and verified.
The details of the transaction in the above sequence will be available and visible only to the parties that were directly involved in the transaction (in this example, the healthcare provider and insurance provider). Since the transaction is of a private nature, the transaction details will not be made available to parties outside of the immediate transaction.
The devices used by the witness pool executing the consensus algorithm against the transaction will have access to the details of the subject transaction during the consensus process, but these details will not be visible to the user(s) whose devices are executing the consensus algorithm. These details will be hidden from view to maintain the privacy of the transaction. Once the transaction is completed and digitally signed by the witness pool, each witness will have a mirror block of the subject transaction added to their private ledger (chain). The mirror blocks created for the witnesses will contain, but will not enable visibility to, the details of the subject transaction. The mirror blocks are a key component of the AXEL blockchain as they provide a safeguard against parties who may try to alter or otherwise compromise the conditions or details of a transaction. By making the transaction details invisible to users outside of the immediate transaction, the AXEL network can protect the integrity of the transactions that occur within the AXEL blockchain while still providing an accurate account of the transaction verification on the public blockchain.
In order to assist with providing adequate storage to facilitate a desirable environment for transactions, the AXEL blockchain can include a distributed network storage capability that allows nodes participating in AXEL to sell storage space that is attached to their local area network devices. In one preferred embodiment, a user may create a node with a personal or home computing device such as a personal computer. The user may attach a one terabyte external storage drive to that personal computer and make the space on that storage drive available for use by other participants within the network.
Unlike existing distributed and decentralized storage methods, in a preferred embodiment, AXEL stores the key codes for both encryption and decryption of the content destined for the network storage on their gateway device such as a personal computer. This ensures the privacy and security of the content being stored as the keys required to access and execute the stored content resides with the user who owns the content.
AXEL can also utilize a redundant storage algorithm that distributes the encrypted parts of the digital content being stored and places them on multiple (participating) devices throughout the AXEL blockchain. In this embodiment, AXEL may routinely request ID and storage information from the network to ensure that the content being stored is both available and accessible to the user. Should a node go offline rendering the stored content unavailable, AXEL may notify the gateway device that the content is no longer available and create additional backup copies of the content that is no longer available. These copies could be gathered from other repositories within the network storing identical encrypted fragments of the subject digital content throughout the AXEL blockchain.
AXEL can also incorporate mechanisms to comply with identification and anti-corruption due diligence requirements, such as regulations directed at money laundering activities. For example, to comply with current regulations AXEL may include an “anti-money laundering” (AML) and “know your customer” (KYC) mechanism to ensure positive identity of the participants on the AXEL blockchain. At account creation, users will disclose information about themselves during the sign up process, as well as information about the devices they are utilizing to connect to the AXEL blockchain.
If PINApp is used with AXEL, device information can be collected through the PINApp and stored in the users' private chain. Information about the device such as the MAC code will be kept in the users' private ledger (chain) to ensure that if someone were to steal their login and access information, they would be unable to access the AXEL network because the device they are utilizing is not registered to the network. In a like fashion, a person using a registered device may not access the AXEL network without the proper login and authentication information.
The AXEL blockchain can utilize functional components of the PINApp, and it may also include functional components of the Digital Certification Analyzer (“DCA”)—as set forth in U.S. Pat. Nos. 9,419,965; 9,565,184; and 9,723,090—to prevent unauthorized access of digital content. For example, the PINApp could be utilized to perform device unification capabilities allowing AXEL participants to access the AXEL blockchain from remote devices such as smartphones, tablets, and the like. The DCA functional components could be utilized in support of the AML/KYC implementation as well as the multi-factor authentication mechanisms.
In addition to the AML/KYC mechanism disclosed previously, the AXEL blockchain can also incorporate a self-sovereign identity capability that gives users complete control of their identity as well as the capability to privately store and secure the identity content, including any third-party verification and authorization validating the identity. This self-sovereign identity may be deleted, in whole or in part, by the user/owner of the identity in compliance with emerging privacy laws.
The devices, features, and functions described herein are intended to disclose a method to provide readily scalable blockchain architecture that supports the transfer of digital content and other assets, while enabling privacy and security mechanisms to protect the privacy of users, while also providing accuracy of ledger reporting to ensure trust and accountability within the blockchain. Unlike existing blockchain networks, the Autonomous eXchange via Entrusted Ledger (AXEL) network will utilize a unique ledger capability that separates out the public ledger (or public chain) from the private ledger (or private chain) allowing users to conduct transactions privately while still enabling the ledger to be authenticated by a consensus-type algorithm to ensure accuracy and blockchain integrity.
The AXEL blockchain described herein addresses the need for an efficient, scalable, and cost-effective method to allow users to manage transactions relating to digital content and other digital assets through a decentralized network wherein participants can establish a level of trust through the use of a public ledger that will track and record the transactions made within the network. The AXEL blockchain can include a utility-type token mechanism to enable parties to conduct transactions within the network and exchange the tokens in lieu of traditional currencies such as USD and the like.
The AXEL blockchain creates an environment wherein transactions made between one or more parties can be done privately without the need to notify each node in the network that a transaction has occurred, but to additionally enable the ledger to maintain accuracy and track the transactions without divulging the specific details of the transactions that occurred.
The AXEL blockchain additionally can enable the transfer, storage, sharing, and streaming of digital content (e.g. files, folders, movies, songs, etc.) to be presented and available for transactions through the AXEL blockchain. To perform this functionality, the AXEL blockchain may incorporate functional components of the PINApp.
Functionally, PINApp unifies the storage repositories across all users' computing devices and makes the content available to multiple devices as it if were hosted locally in a single repository. By enabling PINApp capability with the AXEL blockchain, users can participate in the storing, sharing, streaming, and transfer of digital content and other digital assets without the requirement to physically upload and/or move any of their content to a specific storage or device in order to allow blockchain access and engagement with the digital content.
In one preferred embodiment, a user of the AXEL blockchain will execute the blockchain gateway on a home computer but be able to access and engage the transactional capabilities of the AXEL blockchain from any of their portable devices. This capability allows a user to participate in the network from anywhere, negating the need for them to operate the blockchain gateway on each of their devices in order to gain access to the network.
In one preferred embodiment, a first user may wish to sell a digital asset such as a photo that is hosted on a portable device such as a smartphone. The first user may execute the sale transaction directly from the smartphone and engage the AXEL blockchain remotely, negating the need for the first user to physically move or copy the photo to the device running the blockchain gateway.
As the transaction above is executed, a second user (buyer) would execute a purchase through the AXEL blockchain utilizing the utility token and acquire the photo directly from the first user's smartphone hosting the referenced content. This would also negate the need to copy or otherwise move the content to a public cloud or other holding repository to allow the second user (buyer) to gain access.
The transactions occurring (as in the above example) within the AXEL blockchain are recorded to a ledger, enabling the AXEL blockchain to accurately track transactions that occur. Unlike traditional ledger technologies, the AXEL blockchain will utilize a unique ledger methodology that incorporates a public and private component of the ledger.
The public ledger (or chain) will be created in support of the network's need to provide visibility and tracking of the transactions that occur within the blockchain. The private ledger (or chain) will be created on a per-user basis, allowing each user to conduct transactions within the AXEL blockchain and enjoy a level of privacy for their associated transactions. While specific examples are provided herein of specific information that is included on the public ledger or the private ledger, AXEL may be specifically configured to adjust the particular information that is included on the public or private ledger. For example, depending on what types of transactions are contemplated or changes in laws, it may be advantageous or necessary to include more information on the private ledger as compared to the public ledger or vice versa. As another example, it may prove necessary for more information to be included on the public ledger to promote certainty in transaction verification or to better ensure that the system cannot be compromised. Thus, the disclosure herein should not be read as limiting and is only an example of the types of information that may be included on the public and private ledgers.
Each participant within the AXEL blockchain will be assigned an alpha-type block within the public ledger (chain) and a private ledger (chain).
In a preferred embodiment, the private ledger will report to the public ledger alpha block associated with the user. Any transactions that occur within the AXEL blockchain will be recorded immediately to the private ledger of the parties associated with the subject transaction. As the transactions are completed and the private ledger is updated, the updated information is reported from the private ledger to the public ledger alpha block.
The separation of the public chain and the private chain exists to (a) allow the user to enjoy a level of privacy while engaging in their transactions; (b) keep an accurate and ongoing record of each transaction the user is involved in; (c) enable the user to participate in the witness mechanism (described in detail later in this submission) and; (d) to enable the artificial intelligence mechanism (described in detail later in this submission) within the AXEL blockchain to parse the transactional data on behalf of the user and provide guidance and recommendations as to how the user can get more benefit from their participation within the AXEL blockchain.
As transactions are recorded to the AXEL blockchain, the consensus algorithm will incorporate a witness mechanism that is described in detail later in this submission. In one preferred embodiment, the witness mechanism will select a group of nodes (5 to 20 nodes as an example) using a randomized algorithm. The selected group of nodes will perform the consensus calculation against a transaction. Once consensus has been reached by the selected witness group (nodes), the transaction will be digitally signed by the witness(es) and the private ledger (chain) will be updated with a new block (or blocks) reflecting the transaction being recorded. Non-private information pertaining to the subject transaction such as (but not limited to) the authentication of the transaction and the witness nodes participating in the transaction will be visible on the public ledger (chain) in association with the alpha block hosting the private chain where the transaction took place. The incorporation of the witness mechanism allows multiple transactions to occur and be confirmed through the consensus algorithm process simultaneously, speeding up the network transaction capability.
The AXEL blockchain will also provide a user-focused artificial intelligence (AI) component that will collect and parse transactional data on behalf of the user to give them instant access to information that was transacted utilizing the AXEL blockchain. Transactional information such as automobile maintenance schedules, medical history records, prescription drug records, and other lifestyle events can be processed and tracked through the AI functions of the AXEL blockchain.
In one preferred embodiment, the AXEL blockchain AI component will collect and parse information pertaining to the history of a specific user to enable the user to instantly access information including but not limited to medical records, prescription medication history, car maintenance history, general sale and purchase history and other lifestyle metrics that can be managed and tracked through the private ledger and parsed with the artificial intelligence module. The information will be provided to the user based on a query submitted by the user pertaining to their transactional history within the AXEL blockchain.
The purpose of the AI and the data parsing is to further enable the users of the AXEL blockchain to accurately track transactional history and provide feedback and historical information directly to the users of the AXEL blockchain. The AXEL blockchain AI component will act as a personal assistant or personal transaction manager for the user to enable them to easily recall historical information pertaining to transactions within the AXEL blockchain. In a preferred embodiment, the AI component is not intended or designated for use by any company or other entity seeking to collect user information for marketing or other purposes. The information may be stored and parsed at a local level to ensure the security and privacy of the AI functionality.
As previously stated, the user private chain will be updated as each transaction is executed and subsequently verified within the system utilizing a consensus algorithm. In a similar fashion, the user private chain will be updated with a block reflecting the user participation in the witness mechanism. Blocks created on the user (witness) private chain during the nodes' participation in a witness function/event are designated as mirror blocks. These blocks mirror the transaction that the subject node witnessed to ensure the accuracy of the consensus and to prevent attempts to alter the transaction or the associated blocks hosted within the ledger(s).
The mirror-blocks include details of the transaction that took place during the transaction being witnessed, along with the consensus verification to ensure the block has been verified and/or vetted through the consensus algorithm within the AXEL blockchain. The purpose of the mirror-block is to prevent a party (user) from making a change or augmenting a transaction that has already occurred and been verified within the AXEL blockchain. The witness mechanism and the mirror-block function are described in detail later in this submission.
In one preferred embodiment, the witness mechanism will select a group of nodes (5 to 20 nodes as an example) from the AXEL blockchain using a randomized algorithm. The selected group of nodes will perform the consensus calculation against a transaction. Once consensus has been reached by the selected witness group (nodes), the witness(es) will digitally sign the transaction and the ledger (chain) will be updated with a new block (or blocks) reflecting the transaction being recorded. Each node (witness) participating in the consensus of the subject transaction will create a mirror-block on their own private chain to reflect the transaction in which they participated. The incorporation of the witness-consensus feature allows multiple transactions to occur and be confirmed simultaneously, speeding up the network transaction resolution capability.
In a preferred embodiment, the witness mirror blocks created on the witness private chain during a witness event contain encrypted information which prevents the user of the witness node from seeing any private or personal details from the subject transaction. Details such as party names, items being bought or sold, the pricing of the subject items, vendor names, and other private details of the transaction are encrypted to protect the privacy of the parties that participated in the subject transaction. However, in order for the witness function to perform properly, this information is shared (in an encrypted format) with each witness performing the consensus algorithm via the witness function. Once the witness event is complete (regardless of whether the transaction was authorized or declined) the blocks added to the witness ledger will be encrypted to protect the privacy of the participants of the subject transaction.
In another preferred embodiment, nodes participating as witnesses in a transaction will create mirror-blocks which are then added to their respective private ledger (chain) to serve as an indication that the transaction has occurred and been verified through the witness mechanism, that they (the participating node) executed the consensus algorithm of the subject transaction, and to ensure that changes may not be made to a ledger entry that has already been verified within the AXEL blockchain.
In this preferred embodiment, mirror-blocks become a component of each user's private ledger (chain) that participates in a witness event. Since the users of the network do not know when a node will be selected as a witness to a transaction, they cannot accurately predict or target these nodes for purposes such as hacking or introducing non-verified ledger information into the AXEL blockchain. The randomized algorithm that selects the nodes to participate in the witness event prevents any visibility of the transaction details to participating nodes, ensuring accuracy and security of the transactions and ledger updates.
In a preferred embodiment, the AXEL blockchain provides a distributed storage capability to enable participants of the network to store the digital content (e.g. files, folders, images, etc.) on participating computing devices connected to the AXEL blockchain. Unlike typical storage models, the AXEL blockchain stores the encryption and decryption information to support the distributed network storage function directly on the user's (content owner) private chain. This prevents visibility to the user encryption data, and subsequently the files and digital content being stored within the network. By locally storing the encryption and decryption information on the user's local private chain, the AXEL blockchain ensures availability of the keys utilized to manage the stored content.
The AXEL blockchain will routinely query the participating storage repositories to ensure the content being stored within the AXEL blockchain continues to remain in the location in which it was stored. Due to the distributed and decentralized nature of the storage repositories that will be connected to the AXEL blockchain, continuous verification of file storage accessibility, integrity, and availability is paramount to ensuring the security of the stored content.
In a preferred embodiment, the digital content stored within the AXEL blockchain will be stored redundantly, ensuring the availability of stored content in cases wherein the device storing the subject content becomes unavailable due to being offline or for other unforeseen circumstances. In one preferred embodiment, a file may be locally fragmented and encrypted on the user device utilizing the distributed decentralized storage capability to store the file within the AXEL blockchain. The subject file fragments will then be sent to participating network storage nodes that will store the encrypted fragments. The participating nodes will host various fragments of the file to ensure redundancy, availability, and accessibility to the file owner within the AXEL blockchain. In one preferred embodiment, the same encrypted fragment portion of a file may be stored in a variety of locations within the AXEL blockchain to ensure redundancy and availability of the subject file. The location of the fragments and the contents therein will be known by no one within the AXEL blockchain except the file owner.
The AXEL blockchain will incorporate a unique user identification block that will contain information required to provide a positive identification of the user and their associated engagement with the AXEL blockchain. The user identification block will be created on the private chain component of the AXEL blockchain and remain in control of the user who owns the physical identification being written digitally to the identification block.
Unlike identifications created by third-parties such as online shopping websites, eCommerce websites and the like, the user identification block will be created by and controlled by the user/owner of the identification. The user/owner may then allow (at their sole discretion) a party to authenticate the identity of the user/owner to facilitate both digital and physical transactions that may occur and/or be recorded through the AXEL blockchain.
In one preferred embodiment, a user may create an identification block that provides a positive identity of the user and meets all legal requirements as such. In this embodiment, the identity will be under the complete control of the user/owner of the identity and may be deleted at any time, completely removing the user/owner identity from the AXEL blockchain. The user/owner of the identification will hold privacy-type keys that control the access to the identity and the usage thereof. A public key may be provided to a third party by the user identification owner to enable that third party to execute a one-time authentication of the identification of the user to enable eCommerce and other transactions of both physical and digital nature(s) that can be managed through the AXEL blockchain.
The user identity will be stored in a digital vault that is managed solely by the user identity owner. This vault (similar to a digital wallet) will be controlled by keys that the user/owner of the identification can share at their discretion to enable others to positively identify the user/owner for the purpose of transactions requiring such identification. The vault will exist on the user/owner controlled device(s) and may be backed-up to ensure integrity of the identity. As third-parties are allowed to verify the identity of the user/owner, these verification authorizations and confirmations will also be stored in the user identity vault to further add to the validity and authenticity of the user/owner identity.
The user identity block created on the private chain will support a self-sovereign control mechanism ensuring the user identity block can be both completely separated from the AXEL blockchain as well as to be deleted in its entirety. While the deletion of the user identity block will support legal requirements relating to “right to be forgotten” and other identity protection laws, the deletion of the user identity block will not negatively affect the authenticity of the transactions that occurred while the user was a participant in the AXEL blockchain. The user identity block may not be removed by anyone but the user/owner of the user identity block.
AXEL provides an integrated financial management system (hereinafter AXEL Pay) that enables a participant to utilize external financial institutions such as banks, currency exchanges, token markets and exchanges, and other institutions that engage in the management of personal finance to allow the user wallet to convert currency from a registered fiat currency within a region (such as USD) to the required token, digital currency, or cryptocurrency and then back again.
The purpose of the AXEL Pay system is to allow a user to participate in the AXEL network without having to take the manual step of physically exchanging their registered geographic fiat currency (such as USD) at a registered token or cryptocurrency exchange to enable the user to participate in the network utilizing a cryptocurrency, digital currency, or token instead of their geographically registered fiat currency. Currently, blockchain networks do not allow a user to utilize (as a currency) any payment mechanism that originates outside the blockchain network. Blockchain requires that the user utilize the token or cryptocurrency represented by the associated blockchain as a form of network-based currency. The AXEL Pay system will allow any user to exchange their fiat currency with a registered cryptocurrency without any intervention by the user.
AXEL Pay will automatically make the conversion required to support the blockchain network for the user whenever a user chooses to participate in a transaction that requires a financial exchange. As an example, if a user wishes to purchase a song from a seller on the AXEL blockchain, the user can simply activate their wallet to create a payment. The AXEL Pay system will then connect with the user's registered banking and/or cryptocurrency exchange agency and facilitate the transaction automatically in the appropriate token or cryptocurrency. Naturally this example assumes the user has the adequate registered currency funds (as an example in USD) to complete the transaction.
The AXEL blockchain will incorporate a token identification system and method (Token ID) that will enable the AXEL blockchain to track and account for all tokens created and utilized within the system. Unlike current blockchain mechanisms, the AXEL blockchain will be able to account for each unique Token ID within the network to ensure compliance with laws and regulations such as anti-money laundering and prevention of activity with sanctioned countries.
The Token ID will monitor and record the token location, movements, and authorized holder information to protect the user(s) against hazards such as hacks and wallet thefts. Should a wallet be stolen or otherwise rendered inaccessible to the wallet owner, the AXEL blockchain can immediately disallow the usage of the specified Token IDs to ensure that they are negated until such a time as they can be returned to the legal token owner.
AXEL is also capable of interacting with a distributed database through a distributed database function. This function works in conjunction with the AXEL blockchain to enhance transaction speeds, allow the collection and storage of file and transaction data, and provides a hash function that enables the transactions that occur between the AXEL blockchain and the database to be immutably stored. In one embodiment, a file may be sent from a first user to a second user. The distributed database will record the file metadata and transaction information. Once recorded, the distributed database will generate a unique hash code associated with the file transaction and metadata. That transaction hash is then sent to the AXEL blockchain for recording. The AXEL blockchain will record the transaction hash received from the distributed database and then generate its own hash as a confirmation of recording the hash received from the distributed database. This new hash generated by the AXEL blockchain will then be sent to the distributed database for recording. By enabling the distributed database and the AXEL blockchain to share and record each other's hash records of transactions that take place within the network, AXEL creates an immutable transaction record of each transaction that occurs, along with a complete backup of all network transactions. This ensures the integrity of the network is maintained should either the distributed database or the AXEL blockchain itself become compromised or otherwise unavailable due to unforeseen circumstances.
In another embodiment, a first user may wish to upload a file to the AXEL network using the decentralized storage capability. The keywords, file naming information, and all file metadata will be collected and stored in the distributed database. This will allow the system to display complete file information back to the user as well as enabling advanced keyword and metadata searches to take place within the network. In current blockchain enabled decentralized storage networks such as IPFS (the Interplanetary File System), files are stored and retrieved by the unique file hash. By incorporating a decentralized database to work directly with the blockchain, AXEL provides full file description and keyword search information as well as the capability to render full public and private storage listings to file owners and users.
As is commonly known in the art, blockchain wallets do not actually contain tokens. Instead, the tokens are generated, hosted and reside on the blockchain. Tokens are controlled by a series of public and private addresses or keys that are typically governed/controlled by a blockchain wallet. However, the functionality of the blockchain is that tokens never leave the blockchain and physically enter a blockchain wallet. Tokens exist on a blockchain only, and are governed by one or more wallet addresses that are assigned control of the tokens.
While some existing wallets allow for the utilization of “multiple wallets within a single wallet”, these wallets are a way of collecting wallets that belong to the wallet owner but are on different blockchains. They are designed to allow for an easier user interface but do not solve existing security problems.
The AXEL wallet allows a wallet user to both send and receive blockchain tokens within the blockchain network. The wallet assigns sending and receiving addresses (or keys) to be used by the blockchain in order to facilitate the movement of tokens into and out of the AXEL wallet.
In a preferred embodiment, an AXEL wallet has an addressing mechanism that allows the wallet to provide both internal and external addresses. In this embodiment, the external addresses are accessible to the blockchain but the internal addresses are not. For example, the external addresses can include both public and private keys, and these keys can be utilized in the same manner as a conventional wallet, where the public key is used for sending tokens to other wallets and receiving tokens from them, and the private key is kept private by the owner/user of the wallet. In addition to the external addresses of the wallet, one or more sets of internal addresses of the wallet can be configured by the user, whereby an internal portion of the wallet is not accessible to the blockchain.
In a preferred embodiment, an internal portion of the wallet is completely isolated from the blockchain or any network, while still retaining all other attributes of a wallet, such as addresses. For the purpose of increased security on the internal portion, the wallet owner or user would never need to and would preferably not disclose any internal addresses. In a preferred embodiment, only the wallet owner or user would know of the existence of the internal portion of the wallet. The separation of the external addresses from the internal addresses allows the control of the tokens to be transferred from addresses that are accessible from external sources (such as a blockchain) to internal sources that are not accessible from external sources. This transfer of token ownership and control vastly enhances the security of the tokens being managed by the AXEL wallet.
As an example of the above embodiment, a token may be received at an externally accessible receiving address that is visible to the blockchain and to other users. Once the blockchain confirms and logs the transaction (receipt of the subject token), the received token can be transferred either through direct action of the wallet user or automatically, for example, by settings configured by the wallet user, to addresses that are unique and internal to the wallet, but are not accessible to the blockchain itself. Once such a transfer takes place, the tokens controlled by the wallet could be isolated in an internal portion whose existence, let alone the information needed for access, is only known by the wallet owner/user.
In a preferred embodiment, the blockchain would record transactions by which external addresses receive the tokens, but would have no knowledge or record of transactions through which the token is transferred to internal addresses. Then, if a user desires to transfer a token to the wallet of another owner/user, the token could be transferred to a sender's external addresses, and then transferred elsewhere via the blockchain, and only the latter transaction would be recorded on the blockchain.
In a similar embodiment, the wallet will assign tokens to one or more internal addresses that are not available or accessible to the blockchain itself. As an example, a wallet may have an internal address that controls the entirety of the tokens allocated to the wallet. A user may wish to send a token from their wallet to a recipient wallet. As the transaction takes place, control of the token being sent is moved from the internal address to an external address as assigned by the wallet. Once the token is in the control of the external address, the transaction may be completed.
In a similar embodiment, tokens that are received at a unique receiving address are held at that address until the blockchain confirms the transaction. Once confirmed, the receiving address transfers control of the tokens to an internal wallet address that is not otherwise accessible to the blockchain. In both of the above embodiments, the transfer of token control between an internal and external (blockchain visible/accessible) address ensures that tokens may enter and exit a wallet, but also gives the impression that the wallet is offline after the transaction, greatly improving the wallet security as it interacts with the blockchain.
In another embodiment, the wallet has the capability of assigning a new receiving address that is both unique and randomly generated by the AXEL wallet. For example, a wallet owner or user may find it desirable to generate a new receiving address for the purpose of receiving a token from another user. This address may be configured by either the wallet owner or by the wallet itself to include desired restrictions. Examples of such restrictions include to limit the ability of the address to receive tokens to a single use, limit the quantity of tokens received at the address, limit the amount of time the address remains active for the receipt of tokens, limit the sending addresses that the wallet will allow tokens to be received from, and other such restrictions as defined by the need of the transaction. As an example, a wallet receiving address may be generated and configured to only receive tokens from a certain wallet sending address; further, the quantity of tokens received, date and time the tokens are received and the type of tokens being received can be restricted. Once the conditions of the receiving address have been met, the receiving address may then disallow any further transactions to be conducted through that address. The wallet may have multiple active receiving addresses configured with differing rules simultaneously. By allowing controls to be placed on a wallet address, the token transactions can be performed with a set of controls that meet the needs of the wallet owner.
In a similar embodiment, the restrictions placed on a receiving address as described above are examples of restrictions that can also be placed on a sending address. As an example, a sending address may be configured for a single use, and to allow a preset amount of tokens being sent to one or more specific addresses. Multiple active sending addresses configured with differing rules can be operational simultaneously. Once the conditions of the sending addresses have been met, the wallet may disallow further sending of tokens through a specific address. Further, this address may then be destroyed by the wallet and replaced with a different unique sending address to allow for the next one or more transactions to occur.
The AXEL wallet provides the capability of changing the incoming and outgoing (sending and receiving) addresses either automatically or at the request of a user. In one embodiment, the wallet may change both the sending and receiving (public) addresses after each send or receive transaction. These address changes do not need to take place simultaneously and in fact may occur independently of one another. Further, the wallet addresses may be changed based on a time limit placed on either or both addresses as opposed to limiting the number of transactions that occur at each address prior to the addresses being changed. Each address used will be generated randomly by the AXEL wallet, and each address will be unique in composition. The aforementioned configurable restrictions and ability to change incoming and outgoing addresses are described in connection with the wallet's external addresses, but the same restrictions and ability to change incoming and outgoing addresses could be utilized for the wallet's internal addresses. All of these features create extra security layers for the wallet. For example, the use of restrictions can prevent unexpected or unauthorized token transactions. The use of addresses on a single use basis would allow for a wallet owner or user to limit the disclosure of other addresses used (and configured to be less restricted) for the purpose of transactions with other trusted parties.
The AXEL wallet provides a method in which tokens may be assigned specifically for use within the network itself to facilitate the engagement of an application that is specific to the blockchain network. In one exemplary embodiment, a network host may wish to create an event such as an “airdrop”. An airdrop is an event wherein a network host will provide tokens to participants. An airdrop may be undertaken for a variety of purposes, such as to raise awareness of the token, the blockchain, or an application through which the token can be used. The airdrop itself can be designed in any number of ways. For example, in certain instances participants may simply be selected and may receive a number of tokens without taking any specific action. In other instances, an airdrop participant may accumulate tokens by performing certain activities such as joining a network, creating a wallet, following the blockchain project on social media, or performing some other activity that brings visibility to the blockchain project.
While airdrops have achieved popularity within the token community, it has also been recognized that a portion of the participants may immediately take the tokens they received through the airdrop to a token exchange to sell them for fiat currency, or to trade them for another token or cryptocurrency. Depending on the number of tokens issued in an airdrop, this could potentially lead to a large number of tokens being traded on token exchange by airdrop participants as soon as those tokens are distributed. This activity may have several undesirable effects. For example, if the purpose of the airdrop was to get participants to try certain applications, their immediate sale or trade of the distributed airdrop tokens means the participants are not actually doing so. In addition, if the number of tokens sold or traded on an exchange significantly increases from the amount of tokens that are ordinarily sold or traded, the entirety of the token economy can be affected. This could affect not only the participants of the airdrop, but all other token holders and application users as well.
In this exemplary embodiment, the airdrop tokens may be awarded to participants through an application specific area within the blockchain native wallet (AXEL wallet) that does not allow tokens to be transferred to exchanges or other non-network usages, but instead designates the tokens to be used in an application that is native to, or supported by the network such as a file storage and sharing application, or other application as chosen by the network host. By hosting these airdrop tokens in an application specific area within the wallet, the tokens are ensured to be utilized solely for the application for which they are intended and were otherwise awarded. This prevents the tokens from being removed from the network and ultimately sold on an exchange or otherwise transferred out of the network.
In another exemplary embodiment, tokens may be pre-configured or pre-loaded into a blockchain native (AXEL) wallet for the purpose of enabling the usage of a digital application (DAPP). In a blockchain environment wherein tokens and/or digital currency is used to power DAPPs, there exists a need for these DAPPs to be “free to try”, enabling a potential user to try the DAPP without the need to take burdensome steps to acquire tokens or digital currency first. For example, a potential user may be willing to devote a small amount of time and effort to try the DAPP, but may give up if forced to either undertake too many steps to do so, or a cost. Such a user may not be willing to try the DAPP if the user must purchase the necessary tokens from an exchange first. By creating an application specific wallet function within the blockchain native (AXEL) wallet, or the wallet associated with the DAPP, potential users can try these DAPPs for free, with minimal set-up time, and without fundamentally changing the function of the DAPP itself. This methodology also enables a to DAPP to be utilized within a blockchain environment on a subscription-type basis wherein a user could pay (in fiat or tokens) for the use of the DAPP over a period of time. By enabling the preloading of tokens and/or digital currency into the wallet powering the DAPP, the user is not required to obtain digital currency or tokens on their own, dramatically reducing the barriers of entry for the user community. For example, the user may be required to provide a minimal amount of information to sign up to try the DAPP, and through this process may automatically be assigned an application specific wallet with tokens already present that can be used on the DAPP.
In another embodiment, tokens may be assigned for powering multiple applications hosted on or available through the blockchain network. Tokens assigned to the application specific wallet area could be designated to support all of the applications hosted on or available through the blockchain, a subset of the applications, or any of these subject applications specifically. The application specific wallet function may allow tokens to only be used on some or all of the applications hosted on or available through the blockchain, and can also prevent tokens from being utilized for any purpose outside of the use intended by the network host or provisioner.
As another example of a preferred embodiment, a network such as AXEL may provide an application for the purpose of engaging users and providing an education about blockchain and the associated architecture and technology. Such an application could be in the form of a game of any variety, including but not limited to casino type gaming wherein tokens are utilized to power the functions within the game, and where tokens may be awarded back to users and participants of the network and/or of the subject game. All tokens provided for use within the gaming application may be hosted within the application specific wallet, ensuring that the tokens are solely and exclusively utilized within the game and/or the gaming application, and may not be otherwise utilized for any purpose outside of the specified gaming application. In the alternative, the application specific wallet may be configured to allow the tokens provided for use within the gaming application to be used on other applications associated with the blockchain to encourage the user to try other applications. In that instance, the wallet may be configured to prevent the removal of the tokens from the network, for example, to be sold or traded on an exchange.
In multiple embodiments, the application specific wallet allows for restrictions to not only be imposed, but to be adjusted either automatically depending on certain parameters or else manually by a provisioner, administrator, or other user with appropriate permission. In some embodiments, the wallets would implement the restrictions. In other embodiments, restrictions could be imposed by configuring the blockchain or the tokens themselves. While this application primarily addresses the example where restrictions are imposed using wallets, one of ordinary skill would recognize that the same concepts discussed herein could be applied when configuring a blockchain or tokens. Restrictions can be imposed by any platform that has a provisioner or administrator and can be adjusted through any platform which allows a provisioner, administrator, or user with permission to make adjustments.
As an example of an instance where restrictions may be imposed and adjusted, the requirements to use airdrop tokens only for certain applications, or restrictions placed on tokens provided for the purpose of getting users to try a DAPP or tokens that are designated to support multiple applications, can be adjusted over time. A restriction adjustment might be programmed into the imposed restriction ahead of time, could be programmed in at some point after issuance, or could be adjusted manually by a user with permission to do so, such as an administrator or the provisioner that imposed the restriction. An administrator or provisioner may also designate others who are able to make adjustments. In a preferred embodiment, an automatic adjustment can be based on one or more parameters selected by the provisioner, one or all of which may trigger an adjustment to the restriction. For example, a provisioner might set up a restriction to expire after a prescribed period of time, or gradually lessen over a period of time (e.g., the restriction may expire for only some tokens at one time, and other tokens as additional time passes). A provisioner may also elect to allow restrictions to ease when certain conditions exist or milestones are achieved. For example, it may not be necessary from a regulatory standpoint or desirable to maintain restrictions after a certain portion of the tokens are used within the applications. In another example, perhaps the frequency of usage of tokens in an application triggers regulatory concerns. For example, it may be determined by the provisioner or administrator (who may have also sold tokens) that the more often tokens are used in an application, the less likely the tokens (and token seller) are to run afoul of regulations. Restrictions could be set to be implemented (or re-implemented) only when the token usage frequency falls below a certain level.
In a preferred embodiment, adjustments may both lessen and tighten restrictions that are imposed on the tokens. As an example of tightening restrictions, perhaps when distributed, tokens may be used for multiple applications, but later, the use may be restricted to a single application. Moreover, adjustments may be directed only to apply to a subset of the tokens for which a restriction was imposed.
The ability to adjust imposed restrictions, whether through pre-programmed conditions or manually, can have regulatory benefits. For example, a designer of a token or DAPP may wish to conduct a token sale. As known in the art, this is an event where an individual or entity sells digital tokens, or the rights to digital tokens, to members of the public or others interested in their token or DAPP. Due to regulations such as securities laws, it may be necessary or desirable to control the usage of the subject tokens. The token issuer may want to ensure that token purchasers are not selling or trading the tokens. The token issuer may want to ensure that tokens are used only in transactions within one or more available DAPPs.
As one specific example, it may be desirable in some circumstances to restrict the tokens by imposing a programmed “lock-up” period wherein the tokens being sold cannot be utilized in any transaction for any reason during that period. To accomplish this, in some embodiments, the application specific wallet provides a series of timers that enable a provisioner or network host to provision the application specific wallet to be locked, unlocked and relocked, depending on the needs of the network provisioner or host.
The timers provided in the application specific wallet enable a provisioner or network host to ensure the tokens would not be made available to a token buyer until a prescribed lock-up period has expired. In another embodiment, the application specific wallet may be used to enable the delivery of tokens to a recipient during a lock out period, enabling the token sale host to deliver the tokens to the recipient at the time of the sale, but to prevent their use or transfer until the lock-up period has elapsed. This is particularly well suited for instances where regulatory requirements may allow token sales but prohibit the sale of those tokens during a given period.
In alternative embodiments, the timers could be utilized lock the wallet until certain metrics (other than the simple passage of a given amount of time) have been reached. Or, the timers could be utilized to only allow the wallet to be unlocked when certain conditions are true and a certain amount of time has passed. For example, the timers may be programmed to not allow for the wallet to be unlocked until at least one year has passed, and after that, only when certain other conditions are true. Thus, after one year has passed, the wallet may be unlocked in various timeframes and locked during others.
In another embodiment, the locking mechanism of the application specific internal wallet may be set to never expire, limiting the usage of the tokens to the application specified, and limiting the number of tokens allowed within the wallet for the application specified. As an example, a game developer wishes to provide a game to one or more recipients as a “sample” or to “test” to determine if the recipient would be interested in purchasing or subscribing to the game. The application specific wallet would contain a quantity of tokens as set by the game developer and would not allow additional tokens to be added, preventing the usage of the gaming application once the tokens within the application specific wallet are exhausted. This would render the gaming app unplayable after the tokens become exhausted, forcing the recipient of the gaming app to either subscribe or to purchase the game to continue to access it. In one or more embodiments of the above (and using the example of a gaming app above), the locking on the application specific internal wallet may be on a timer, which would allow the recipient of the gaming app to only use a specified number of tokens (or plays) during a time period chosen by the provisioner prior to allowing more tokens to be added, and for additional plays to be allowed. By governing the number of tokens allowed during a period, the application specific internal wallet can control access to the application for which the tokens hosted in the wallet is indented.
In another embodiment, the locking mechanism of the application specific wallet may allow tokens to be freely moved into the application specific wallet, but may restrict the usage of tokens for the application which they are intended. As an example, the gaming application referenced above may award tokens as is the case with some casino type gaming applications. The application specific wallet would allow the awarded tokens to freely enter the wallet, but may still control the number of tokens leaving the wallet and/or the timeframe(s) in which these tokens may leave the wallet. In another embodiment, the application specific wallet allows for a timer to unlock a group of tokens for a set time period and then to relock the tokens upon completion of the time period. The unlocking and relocking of tokens within the application specific wallet could be used in cases where an event such as a bounty program was to take place. A bounty program typically enables network users to participate in the testing and troubleshooting of new functional elements of a network such as new apps, new wallets and the like. The application specific wallet may be unlocked during such an event to enable participants to freely move tokens into and out of their application specific wallet, allowing tokens to be used outside of the specified application the tokens were intended to be used for. Upon completion of the program, the tokens (and the subsequent application specific wallet) would be relocked, returning the wallet function to its normal, application specific state. It is important to note that the quantity of tokens that are part of the event, and thus subject to the unlocking of the application specific wallet during the example event, can also be controlled by the provisioner.
In another embodiment, the application specific wallet timer configuration can be utilized by a third party to create applications on a blockchain. As an example, an application developer creates a gaming app and wishes to launch it on the AXEL blockchain. The application developer chooses a launch date (for example, January 1), but wants to put the game in the app store before the launch date to allow users to install the game. The application developer can configure the application specific wallet timer to unlock the wallet (and the tokens held within it) on the launch date chosen. This allows the application developer to make the subject application (the game) available to download and install prior to the launch date, but prohibiting usage of the application (the game) until the launch date arrives.
In a similar embodiment, the application developer launching a game may wish to conduct a prelaunch event to enable users to try the application (game) prior to the general availability (launch date) of the game. In this case, the application developer may choose to have a start and end date for this prelaunch event, which would make the game playable during a period, but not available prior or after the period. At the start of this period, the application specific wallet (and the tokens within it) would automatically unlock based on the time and date set by the application developer. At the end of the period, the application specific wallet may relock, preventing further user of the gaming application and the tokens used to power it. By enabling the locking, unlocking and relocking of the application specific wallet and the tokens within that wallet, developers gain a significant amount of flexibility in the deployment of their applications.
AXEL also provides a network-based wallet administration tool (AXEL WebWallet) that may be used in conjunction with a user-owned AXEL wallet, or as a stand-alone wallet administration mechanism wherein the key pairs (user public and private keys) may be generated and managed. For example, key pairs generated by an AXEL WebWallet may be used by the network client (user) to enable token transactions through a native AXEL wallet. A public key generated by an AXEL WebWallet (at the request of the user and their subsequent locally hosted wallet application) could be shared with a user wallet (AXEL Wallet or AXEL WebWallet), whereas a private key generated by the AXEL WebWallet would not be disclosed to the user, user wallet or any other entity outside or beyond the AXEL WebWallet.
The system allows for a user of the AXEL WebWallet to, at any time of their choosing, generate additional public keys for their use. This capability allows a user to specify the usage parameters surrounding a public key. For example, in one preferred embodiment, a user may generate one or more public keys to be used solely for receiving tokens from one or more specific sources, such as a particular online exchange. As another example, a user may be participating in an airdrop and create a public key to be shared with the airdrop host for the purpose of receiving tokens in the airdrop event. The AXEL WebWallet enables a user to create a virtually unlimited number of public keys for which the user can determine specific usage parameters. This enables advanced accounting and tracking of transactions beyond simply reviewing the blockchain transaction records, as the WebWallet user may review their transaction history through their wallet at any time, and the transaction history can identify which of the user's public keys was utilized in a given transaction.
An AXEL WebWallet private key functions entirely differently than the previously mentioned public key. In a preferred embodiment, an AXEL WebWallet private key for a user's wallet would not be disclosed to the user. Indeed, the WebWallet may be configured such that no private keys can ever be shared with any user(s), even the owner of the wallet that initiated the generation of a private key. Instead, a private key generated by the AXEL WebWallet will be stored, for example, solely by the WebWallet on the network itself in a fragmented and encrypted fashion. That is, the key will be broken into smaller pieces called fragments. Each fragment of the key will be encrypted and stored on one or more network storage repositories that exist throughout the blockchain network.
In a preferred embodiment, the private key will only be used as a means to validate a transaction that is initiated by the wallet that generated the key itself. As an example, when a new user creates a wallet and key pair using the AXEL WebWallet, the private key is accessed and read by the AXEL WebWallet as a means to approve a transaction request by the user and their wallet installed on their personal device. Once the key is used to validate the subject transaction, it will once again be fragmented into smaller files, each being encrypted and then each being stored (in locations undisclosed to any user) throughout the AXEL network. Thus, while the public key may be transferred to the user wallet, the private key will remain under the sole control of the AXEL WebWallet. Specifically, in this embodiment, the private key, its location and its access are controlled entirely by the AXEL WebWallet and will not be disclosed outside of the AXEL WebWallet and its subsystems.
Storage of a private key by the AXEL WebWallet is managed based on the needs of the network administrator or provisioner, and may be managed by a unique algorithm that selects secure storage locations randomly and assigns encrypted key fragments to the random selection of storage repositories. To ensure access and availability of the encrypted key fragments to the AXEL WebWallet, fragments may be copied and stored in multiple locations such that the information that forms part of one fragment may overlap, in whole or in part, with the information that is stored on a different fragment. This protects the private key and ensures that the information necessary to utilize a private key in a transaction is always available for recall by the AXEL WebWallet, regardless of the network stability, resource usage or other factors that may impede the collection of a key fragment from a designated storage repository. In one embodiment, each key fragment is assigned a unique hash code that is known only to the AXEL WebWallet. Storage information associated with the key fragments is unknown to all network entities outside of the AXEL WebWallet. The AXEL WebWallet may generate multiple encrypted key fragments that are identical. More specifically, each key fragment created may have duplicates created to ensure that all fragments are able to be recalled, decrypted and combined to generate the private key needed for a transaction. The identical key fragments will be stored in various locations throughout the network to ensure that if a fragment is damaged or otherwise not retrievable by the system, a backup fragment is available. In another embodiment, AXEL WebWallet may also generate for storage duplicative but not identically overlapping fragments.
In a preferred embodiment, the AXEL WebWallet is managed by the AXEL decentralized and distributed database (DDB), and not by the blockchain itself. This may enhance the privacy and security of the WebWallet and its associated functional elements. In one preferred embodiment, the DDB does not run on all network nodes, but does have access to all nodes. Control over the DDB and the AXEL WebWallet is paramount to network security, so running the DDB on a subset of the nodes, as opposed to a larger number, may enhance security by limiting accessibility.
In a preferred embodiment, while the AXEL WebWallet is not directly managed by the blockchain, it does record and track all transactions associated with the WebWallet. This ensures transaction records are stored on both the blockchain and within the WebWallet itself, providing additional security for the management and tracking of transactions that occur within the network.
AXEL provides a digital signature capability that enables one or more parties to digitally sign documents, contracts, agreements and other single or multi-party works. The digital signature supports multiple levels of authentication, depending on the need of the participants and the level of verification the signatory has applied for through the AXEL network.
In an exemplary embodiment, the digital signature will require the user or network subscriber to participate an AML/KYC protocol, which may be conducted through the network, to ensure the identity of the user or subscriber. This enables authentication of the true identity of the user creating the digital signature within the AXEL network, ensuring authenticity of the signatory.
In another embodiment, and for the express purpose of further ensuring the authenticity of the signatory, the digital signature is governed by the signatory/user's wallet. The wallet can be tied to the digital signature, for example, by using the private key generated within the wallet, ensuring authentication of the signatory. In this example, as the private key is blocked from network view, it provides an added level of security and privacy.
In another exemplary embodiment, the signatory is required to authenticate their access to the digital signature capability through their authentication of access to their blockchain wallet. More specifically, the signatory/user must complete authentication prior to accessing their blockchain wallet. The authentication steps are detailed later in this submission.
The digital signature may require additional verification and authorization beyond what is required to access the blockchain wallet. Specifically, the signatory can be required to perform additional verification and authentication steps after accessing their blockchain wallet, but prior to being granted access to the digital signature capability. This implementation, along with the security protocols detailed in this submission pertaining to the blockchain wallet, provides multiple layers of protection for a user/signatory should their account username and password be compromised.
In a preferred embodiment, the digital signature function works directly with the self-sovereign ID information to ensure the identification of the signatory is both valid and authentic. As an example, a signatory is required to participate in an AML/KYC audit prior to being granted a digital signature capability. This ensures that the signatory is verifiable and authentic, further enhancing the trust factor between nodes in a decentralized and distributed networking environment.
In another embodiment, the digital signature function can be utilized in real time to perform signature actions during meetings or other settings wherein an arbitrator and/or witness are separate from the signatories, and/or the signatories are separate from each other. This is often the case in situations wherein system users are geographically separate or not otherwise collocated with each other.
In another preferred embodiment a digital signature may be enacted in conjunction with a live video event such as a video conference conducted through commonly known in the art video meeting software such as Skype, Zoom, GoToMeeting or other video meeting software that enables people to conduct real-time meetings and gatherings. This embodiment enables the signatories to witness the digital signing of media such as contracts that would be created through agreements between parties.
As an example of a live video enabled signing event, a first user may have an wallet running on a personal computer. The live video (provided by known in the art services such as Skype, Zoom, GoToMeeting, etc.) may be running on the same device, or may be synchronized through the AXEL blockchain by the AXEL wallet. The live video may include video of the individual entering their signature through, for example, a camera on the device. it may also take advantage of other capabilities of video meetings, such as when one participant shares their screen with another participant. Parties may then execute the signature event both digitally (through their respective AXEL wallets) as well as visually through the user of the aforementioned video services. It is contemplated that while the wallet and the video provider application may run parallel on a single user device to support the disclosed live video enabled signing event, these services may be separated entirely both physically and geographically and controlled through the AXEL blockchain and/or the use of a database enabling synchronization and tracking.
AXEL also provides a load management system wherein network users and their associated apps and tools are allocated to specific areas of the network, including specific nodes, based on factors such as available bandwidth, resource availability, geographic location, access time, network traffic, service outages and other factors that may impact network performance and user access.
In common networking configurations as known in the art, network resources are typically permanently allocated to portions of the network where traffic is the heaviest. For example, resources are typically provided to the network based on the geographic needs of the users accessing the network from a specific point of origin. Conversely, AXEL provides a load management system and method that allows users and their associated apps and tools to be managed as a grouping called a “shard.” A shard can be created anywhere on the AXEL network and provides a flexible and configurable grouping method that enables user-initiated network traffic to be relocated to areas of the AXEL network where more resources are available to provide for the needs of the users and their associated apps.
In an embodiment of the above, a shard can be created within the AXEL network by a network administrator or provisioner, or by an algorithm used to balance traffic against network resources. A shard can contain any number of users, user applications and user tools, and can be moved freely through the network as desired by the network administrator or provisioner, or as designated by a network balance algorithm.
The network can balance traffic with respect to a shard in various ways. A shard can be assigned to a specific single network node, or to one or more groups of nodes. At any time desirable, a shard may be broken into multiple sub-shards, or several shards may be combined into a single shard. A shard may be designated to carry only user traffic relating to cryptographic wallets and tokens (AXEL Wallet and AXEL WebWallet) or may be configured to carry any combination of users and their associated wallets, tools, apps and other traffic such as user search inquiries and the like.
Other systems, methods, features and advantages of AXEL will be or will become apparent to one with skill in the art upon examination of the following figures and detailed description. It is intended that all such additional systems, methods, features and advantages be included within this description, be within the scope of the invention, and be protected by the accompanying claims.
The components in the figures are not necessarily to scale, emphasis instead being placed upon illustrating certain embodiments of the invention. The drawings are intended to illustrate particular configurations of the AXEL blockchain, but it should be understood that AXEL allows for variation of these configurations. In the figures, like reference numerals designate corresponding parts throughout the different views.
In the following description, numerous specific details are set forth in order to provide a more thorough description of the present invention. It will be apparent to one skilled in the art that the present invention may be practiced without these specific details. In other instances, well-known features have not been described in detail so as not to obscure the invention.
As previously stated, AXEL is comprised of two distinct and separate blockchains: a public blockchain that is provided to enable public visibility to transactional history and a private blockchain to allow users within the AXEL blockchain to conduct their transactions privately between consenting parties. Each user within the AXEL network will be assigned both a publicly visible alpha-type block that resides on the public chain, and a private chain in which their personal transactions may be conducted to insure privacy and discretion.
The purpose of the AXEL blockchain's two-chain approach is to allow users to conduct their daily transactions in a more private setting, while at the same time enabling the consensus and verification of the transactions to be shared through a publicly visible ledger represented by the public blockchain.
For the purpose of the discussions that follow a node is a computer or other computing-type terminal that is running at least a portion of the AXEL gateway client software. Nodes communicate with each other through the AXEL gateway client software and create a decentralized distributed network to operate the AXEL blockchain. Storage of the public and private blockchains discussed herein may be facilitated through localized storage at the node location, localized storage at the user location (in reference to private chains). Additionally, storage of the reference chain elements can be managed through the AXEL distributed decentralized network storage capability or any combination thereof.
A general description of the chain mechanisms will now be described with reference to
The pairing indicators (155, 160, and 165 respectively) represented in
The communications 155, 160, and 165 provide direct engagement for each of the private chains 125, 130, and 135 with their respective alpha blocks 110, 115, and 120 to ensure the public visibility of the vetted transactions as well as enabling the transfer and logging of transactional information between the alpha blocks (110, 115, and 120) and their respective private chains (125, 130, and 135).
As previously stated, the AXEL public chain 105 represents the publicly visible 145 aspects of the AXEL blockchain whereas the private chains 125, 130, and 135 represent the components of the AXEL blockchain that are not visible to the public 150. The purpose of the AXEL public chain 105 and the respective private chains 125, 130, and 135 is to enable the users to enjoy a level of privacy while engaging in transactions with other users while still giving the AXEL public chain 105 and the subsequent nodes (not pictured) visibility to the fact that each transaction that occurs on the private chains (125, 130, and 135) has been verified by the AXEL blockchain.
As an example of the chain utilization, user 1 (private chain 125) engages in a transaction. Once the transaction has been resolved utilizing the consensus algorithm (witness mechanism discussed later in this submission), a new block 170 is added to the private chain 125. As the private chain 125 has been augmented with the new block 170, the private chain 125 communicates 155 the addition of the new block 170 to the user 1 alpha block 110 hosted on the AXEL public chain 105. This process repeats itself each time a user executes a transaction within the AXEL blockchain.
The details of the above subject transaction 170 will be invisible 150 to other users on the AXEL blockchain with the exception of other user(s) participating in the subject transaction. This gives the users of the AXEL blockchain the capability to conduct their transactions with a level of privacy.
It is important to note that while the transactions occur in a private setting within the AXEL blockchain, in the preferred embodiment, they do not occur with anonymity. As previously stated, the advantages of this are that verification and authentication of identity is beneficial in some instances to comply with certain regulations including, for example Anti-Money Laundering and Know Your Customer regulations. While this information would not be publicly available to other participants in the network, they will know that when they conduct transactions with other users, that these users have been authenticated and vetted by AXEL.
With continued reference to
Again, in the interest of being able to create a private transaction, the details of the transaction will only be visible to the users directly involved with the subject transaction (in this example the buyer and seller). The remainder of the blockchain users (nodes) will see that a transaction has occurred and has been verified by the system (to ensure validity and transparency pertaining to the transaction history) but will not be able to see the details of the actual transaction.
In a similar fashion if a person were to walk into a pharmacy and make a purchase from the pharmacist, other parties present in the pharmacy would have visibility to the person making a transaction with the pharmacist, but would not be privy to the details of the subject transaction. While the AXEL blockchain is capable of supporting transactions of a completely anonymous nature, in a preferred embodiment, users are provided a measure of privacy to conduct transactions within an environment wherein the ledger components can enable a measure of trust to exist between nodes over a distributed and decentralized network.
As stated previously, the alpha blocks are created and hosted within the public chain to represent each user within the AXEL network. Each alpha block acts as a repository and control mechanism for each user and their associated private chain.
In the discussion that follows, functionality that exists on both the public chain and the private chain of the AXEL blockchain will be disclosed. In many cases, like or similar functional elements will be present on both the public chain and private chain components of the AXEL blockchain.
As can be seen in
As can be seen in
With continued reference to
The AXEL communications 215 function may utilize the DCA (Digital Certification Analyzer) to enable a first user to send a private message to a second user, and require the second user to initiate the DCA protocol to access the message. The message may also be protected and/or encrypted utilizing the AXEL DCA—Security 285 capability discussed later in this submission.
Communications within the AXEL blockchain can originate from either the public chain 205 or the private chain 295, depending on the nature of the communications and the needs of the user. As an example, a public message such as a posting to comment on a product purchased from an eCommerce site or other social-type publicly visible message may originate from the alpha block 210 on the AXEL public chain 205. A private message intended for a specific recipient or group of recipients may originate from the private chain 295.
The AXEL communications 215 function works in conjunction with the AXEL database 250, the network addressing 260, and the AXEL DCA—Security 285 functions to ensure proper configuration and delivery of various message types within the AXEL blockchain.
The AXEL A.I. (artificial intelligence) 220 function is integrated into the AXEL blockchain to support both public chain 205 and private chain 295 capabilities. On the private chain 295 the AXEL A.I 220 function is controlled and managed directly by the user.
Unlike traditional machine learning and artificial intelligence algorithms, the AXEL A.I. 220 function focuses on the private chain 295 to collect and parse information pertaining to the user and their respective transaction history to enhance the user's engagement and experience within the AXEL blockchain.
In one preferred embodiment, the AXEL A.I. 220 function may collect and parse information pertaining to a video stream viewing history that has been created by the user through their viewing transactions within the AXEL blockchain. The user may query the AXEL A.I. 220 function to obtain the subject history of their stream viewing engagement; along with recommendations for other potential streams the user may be interested in viewing.
The AXEL A.I. 220 function on the private chain 295 is provided and engaged at the sole discretion of the user. The information collected and parsed is stored in the alpha block 210 for recall at the request of the user. The AXEL A.I. 220 information stored in the alpha block 210 is not publicly visible or searchable through the public blockchain 205. Only the user (not pictured) can access the AXEL A.I. 220 capabilities and the subsequently generated information provided.
On the public chain 205 portion of the AXEL blockchain, the AXEL A.I. 220 function is utilized to promote self-healing within the network. The AXEL A.I. 220 function will collect and parse performance and transaction history from nodes to determine areas of the network that are underperforming or working at a less-than-optimal pace. This information can be collected by the AXEL nodes to aid in isolating problems within the blockchain and creating solutions to ensure the functionality of the AXEL blockchain remains at an optimal level. The AXEL A.I. 220 function on the public chain 205 works in conjunction with the user reputation 225 function discussed below.
The AXEL A.I. 220 function will also utilize a weighting-type algorithm to determine and engage the quickest transactional pathing between nodes participating in the AXEL blockchain. As an example, a transaction may occur within the network that involves multiple nodes for the purpose of transporting the information through the blockchain. The AXEL A.I. 220 function will parse information pertaining to node performance and node reputation to quickly and accurately plot the most direct route for the transportation of information through the blockchain. As more transactions occur, the AXEL A.I. 220 function will continue to monitor, collect, and parse the relevant information on the public chain 205 to ensure self-healing and efficient routing/pathing of transactions and data transportation.
With continued reference to
Reputation information may be collected by the AXEL blockchain relating directly to the functionality of the node or gateway being managed by the user. As stated above, the AXEL A.I. 220 function will collect, parse, and report performance information of the associated network nodes.
In one embodiment, the user node (not pictured) may have introduced incorrect or otherwise non-validated chain data to the AXEL blockchain. The AXEL blockchain would recognize this invalid data through the consensus algorithm (discussed in detail later in this submission) and record the action as a negative for the participating node introducing the invalid data. As the reputation of a user or node moves in a negative direction, the AXEL blockchain may limit or decline participation in one or all activities within the AXEL blockchain. Node and user reputation is paramount to ensuring the security and privacy of the data being exchanged and the users within the AXEL blockchain engaging in these transactions.
If a user or node reputation continues to move in a negative direction, the AXEL blockchain (through the communications and support 275 function discussed later in this submission) will notify the user and/or node to correct the problem. As the user/node performs transactions properly, their reputation may recover. As previously stated, users and/or nodes that continue to receive a negative reputation will be subsequently limited or precluded entirely from activities within the AXEL blockchain.
As with other functional elements within the AXEL blockchain, the user reputation 225 function has both a public chain 205 presence through the alpha block 210, and a private chain 295 presence. Reputation may be granted in either a positive or negative fashion by the AXEL blockchain as discussed above, but may also be granted in either a positive or negative fashion by a second user or other participant within the AXEL blockchain. As an example, a user may participate in a transaction (through a marketplace element or a file share or transfer) that does not satisfy or meet the criteria of the transaction in a satisfactory manner for the user. The dissatisfied user may grant a negative reputation to the second participant in the transaction to show their displeasure with the subject transaction. The user may also post a public comment (to a marketplace as an example) where the original transaction took place. As previously stated, when a reputation moves too far in a negative direction the AXEL blockchain may limit or deny the user with a negative reputation from participating in some or all transactional acts until such a time as their reputation has been restored.
The private chain history 230 function serves multiple purposes within the AXEL blockchain. The primary function of the private chain history 230 function is to collect and store transactional information associated with the private chain 295 to ensure that a backup copy exists to support the restoration of the private chain 295 in the case of a failure of a user gateway device that resulted in loss or damage to the private chain 295.
As transactions occur within the private chain 295, the history is collected locally through the private chain history 230 function and reported to the public chain 205 for storage in the users' associated alpha block 210. The private chain history 230 function works in conjunction with the AXEL database 250 function to report and store details of the transactions undertaken by the user. A second function of the private chain history 230 function is working in conjunction with the
AXEL A.I. 220 function to enable a user to parse their history and enable AXEL to provide recommendations for future transactions as described in the examples given previously in this submission. Since the alpha block 210 will always be a component of the network and may not be deleted or removed by any means, the private chain history 230 function, along with other functional 201 elements will be available for recall in case of catastrophic failure on a client device or within the AXEL blockchain.
The AXEL blockchain defines a transaction as any event that creates a block of information that is added to the blockchain. In one embodiment of the AXEL blockchain, a participant may make a purchase utilizing a marketplace being hosted within the AXEL blockchain. This purchase (after being vetted by the consensus algorithm discussed in detail later in this submission) will create a block and add it to the users' private chain 295. The transaction (block) will be shared 290 with the associated users' alpha block 210 within the public blockchain 205.
The detailed information collected and stored within the private chain history 230 function is not publicly visible. Only the consensus information is publicly visible. This will ensure that the AXEL blockchain recognizes that all transactions have been authenticated within the blockchain, even though the details of the transactions are not visible. This ensures a level of privacy for the users within the AXEL blockchain while also ensuring the validity of each transaction that occurs.
The AXEL chain communications 235 function (illustrated by reference 290 in
The chain communications 235 function occurs constantly within the AXEL blockchain to ensure the information and transactions completed on the private chain 295 are being continuously communicated 290 to the public chain 205 and the subject corresponding alpha block 210.
The AXEL blockchain incorporates a witness mechanism (discussed in detail later in this submission) that randomly selects a group of five or more network users (or nodes) and utilizes these users to perform the consensus algorithm required to approve a transaction and add a block to the respective private chains of the transaction participants.
The witness administration 240 function governs and manages the aspects associated with creating and managing a witness pool to perform the consensus algorithm. As an example, a user may be selected randomly to perform the consensus algorithm to aid in the resolution of a pending transaction (referred to as the witness mechanism). As the user concludes their consensus session, the resulting verification and the fact that they participated in the subject consensus session will be noted by the witness administration 240 function.
The witness administration 240 function collects and stores (within the AXEL database 250 function) information related to the consensus algorithm function that includes, but is not limited to, the number of times a user and/or node participates as a witness, the number of times the consensus algorithm was executed resulting in a completed consensus, the number of times the consensus algorithm was executed and failed to achieve consensus, and the reputation of the user and/or node as a witness. As explained previously, the user reputation 225 function within the blockchain is vital to ensuring trust and node functionality. The user and/or node reputation relating to the witness administration 240 functions will be stored in both the witness administration 240 and the user reputation 225 functions.
As an example of the above, a user may be randomly selected as a witness by the witness administration 240 function within the AXEL blockchain. Should the consensus be reached successfully and match the consensus of the other participating witnesses, each witness may receive a positive user reputation for reaching a consensus. In a similar fashion, a node that fails to reach the consensus and/or acts in a negative manner pertaining to the network and other nodes may receive a negative user reputation. As previously stated, user reputation is required to remain a participant in good standing within the AXEL blockchain.
The wallet and token administration 245 function controls and manages actions related to both the token(s) that exist within the AXEL blockchain and the wallet mechanism the user and/or node engage to store their token(s). The wallet and token administration 245 function will manage both internal and external wallets that are engaged within the AXEL blockchain. As an example, a user may wish to utilize solely the wallet functionality (not pictured) that exists within the AXEL blockchain. The user may choose to incorporate a second wallet from a 3rd party developer that is used to both store and manage tokens as well as used to purchase and transfer tokens between parties on the AXEL blockchain. The wallet and token administration 245 function will manage each of these wallets according to the configurations set by the user.
As with functions 201 related to the public 205 and private 295 chains within the AXEL blockchain, the wallet and token administration 245 function works in conjunction with other elements including (but not limited to) the AXEL database 250, the chain communications 235, the user ID info 255, the AXEL DCA—Security 285, the unified device ID info 265, the Storage/CPU/Mining 280 functions and others. As previously stated transactional information is stored within the alpha block 210 within the public chain 205.
The AXEL database 250 function engages with other functional 201 elements of the AXEL blockchain to ensure proper routing, tracking, addressing, and historical information is easily available for managing the transactional aspects of the AXEL blockchain. As an example, the AXEL database 250 function may contain routing information associated with user devices (not shown) connected to the AXEL blockchain via the user's personal computer (not shown). The subject routing information makes it possible for the user to access any digital content (e.g. file, folder, etc.) that is managed through or otherwise connected to the AXEL blockchain.
The AXEL database 250 function may also work in conjunction with modules such as the private chain history 230 function to ensure that private chain 295 recovery is possible in case of a catastrophic failure of a client device or other system causing damage to, or deletion of, the user private chain 295.
The AXEL database 250 function stores AXEL A.I. 220 function information relating to the self-healing aspects of the public chain 205 as discussed earlier in this submission. Weighted routing and pathing information may be stored in the AXEL database 250 function to ensure proper routing of traffic and other transactional aspects that occur between nodes within the AXEL blockchain.
The user ID info 255 function is designated to manage the user engagement with the AXEL blockchain. If configured to work in conjunction with the AXEL DCA—Security 285 function (discussed later in this submission), AXEL can utilize protocol from the Digital Certification Analyzer (U.S. Pat. Nos. 9,419,965; 9,565,184; and 9,723,090) to verify and authenticate the user(s) participating in the AXEL blockchain. The user ID info 255 function collects and manages the user identification, password, pin code, and other pertinent information relating to a user's account. The user ID info 255 function (as stated above) works in conjunction with the AXEL DCA—Security 285 function along with the AXEL database 250 function to store and authenticate user access information. The user ID info 255 function also works with the unified device ID info 265 function discussed later in this submission to ensure that the login attempts are originating from devices and user(s) that have been verified within the system. As an example, a user may try to log into an AXEL account utilizing a registered device but an incorrect user ID and/or password. The login attempt would subsequently fail. As with the above, a user trying to log into the AXEL account from a non-registered device utilizing an authentic username and password would also fail. The AXEL blockchain requires that both authenticated devices and user accounts are verified through the AXEL DCA—Security 285 function working in conjunction with the AXEL database 250 and the user ID info 255 functions to enable access to a user account within the AXEL blockchain.
The user self-sovereign ID (SSID) 257 controls the detailed identification content of the user such as passport numbers and authentication, driver's license numbers, birth certificates, and other digitally managed identification assets that can be used to positively identify the user. The SSID 257 control creates a block on the private chain 258 that can be utilized by the user/owner of the private blockchain to enable third parties such as vendors, healthcare providers, and others to authenticate the identification of the user.
The SSID 257 will be controlled by a private and public key mechanism that enables the user/owner of the SSID 257 to share a public one-time-use key to any party as a means of accessing the SSID block 258 to confirm the identity of the user. As the authentication of the identification is provided to the third party, that authentication may be captured and stored in an identity vault (not pictured) that is privately stored and backed-up on a user-owned device such as a smartphone, computer, or other digital storage mechanism that can access the AXEL blockchain.
In compliance with emerging privacy laws, future changes thereto, or to adjust to shifting views on data privacy, in some embodiments, an option will exist such that the SSID block 258 can be deleted in whole or in part by the user. It may be desirable that a deletion of a user's SSID block 258 will cause the private chain 295 to immediately back-up some or all transaction content to the alpha block 210 on the public chain 205 and effectively close the account of the user, preventing further engagement with the AXEL blockchain. However, as it is contemplated that the user SSID 257 is utilized solely in instances wherein a transaction requires an extended authentication and validation of the user credentials, the SSID block 258 must remain active in order for the user to participate in such transactions. The AXEL blockchain may be configured such that no user may participate without an SSID block 258, or that a user without an SSID block 258 may have limited functionality. Common transactions such as certain types of file transfers, including content that is part of the public domain, or a purchase from an online eCommerce site may not require such authorization, and it is contemplated that the blockchain could be configured to allow a user without a complete SSID block 258 to participate in such transactions. Transactions of a significant nature such as the transfer of medical records, the purchase of a property, home, or other physical asset may require the use of the complete user SSID 257 to ensure and authenticate valid user identification.
The network addressing 260 function manages the physical addressing and routing information within the AXEL blockchain. Localized addressing such as communications between the private chain 295 and the respective alpha block 210 is managed through the network addressing 260 function. On a broader scale, the network addressing 260 function ensures that users participating within the AXEL blockchain can efficiently transfer, share, stream, access, store, and otherwise engage with all digital content managed and shared within the AXEL blockchain.
The network addressing 260 function works in conjunction with other functions such as the AXEL database 250 and the AXEL communications 215 (as an example) to enable a first user to establish a messaging and/or chat session with a second user. The network addressing 260 function manages functions associated with directing and routing network traffic on the AXEL blockchain.
The unified device ID info 265 function is utilized to register and authenticate the devices a user uses on the AXEL blockchain. AXEL can incorporate components of the PINApp to enable a user to unify all of the portable computing devices (such as smartphones, tablets, personal computers, and the like) with the AXEL blockchain, providing the capability of accessing any digital content residing on any connected/unified device from anywhere the user or participant travels. This provides the capability of accessing the AXEL blockchain from any device while negating the need to run blockchain gateway software on each device the user engages to access the AXEL blockchain. As an example, a user may be running the AXEL blockchain gateway software on their home PC. The PINApp allows the home PC to communicate directly with the subject user's smartphone, enabling them to access the AXEL blockchain remotely from their smartphone, negating the need to run a local AXEL gateway client on the subject smartphone.
The unified device ID info 265 function works in conjunction with the AXEL database 250 function to ensure device identification is properly logged and available for access. This function can prevent a user from accessing the AXEL blockchain from an unauthorized device, even if they enter the correct user ID information and associated password(s) and pin codes. As previously stated, privacy, security, and trust between nodes are vital to the functional implementation of the AXEL blockchain. By limiting access to only verified and authenticated users utilizing only authenticated and verified devices, AXEL can guarantee the user within the network is valid. As discussed above, while AXEL may operate with this described security implementation, any variation of security that is desired would be compatible with AXEL For example, it may be desirable in certain instances to include more or fewer factors of authentication.
The AXEL DCA—Security 285 function works in conjunction with functional elements 201 within the AXEL blockchain. The DCA utilizes a multi-factor algorithm to ensure the positive identity of a user wishing to access the AXEL blockchain, as well as verifying the device in which the user is utilizing to gain access. The unified device ID info 265 function enables the AXEL DCA—Security 285 function to see the physical identity and/or machine code addressing of each device utilized to connect to or otherwise access the AXEL blockchain. If the AXEL DCA is utilized, Security 285 function will only accept an authorized login attempt from an authorized user or participant utilizing an authorized device. It is contemplated that the security setting could be configured in any manner desired. More or fewer authentication factors could be used. Any variation in the login attempt such as a wrong device, wrong username, wrong password, or other incorrect matching with the requirements will be rejected by the AXEL DCA—Security 285 function.
The chain recovery 270 function works in conjunction with the private chain history 230 and the AXEL database 250 functions to restore a user private chain 295 in case of catastrophic failure. In one embodiment, a user may lose access to a gateway device such as a home computer due to a critical device failure. The chain recovery 270 function will enable that user to completely restore their private chain along with the history associated, up to and including the last verified transaction the user participated in.
As stated previously, the public chain 205 is comprised of alpha blocks 210 that may not be completely deleted otherwise removed from the AXEL blockchain. This is due to the fact that transactional information that involves other users may be stored within the alpha block 210. If it was possible to remove an alpha block 210 it could result in the absence of historical transactional information or witness administration information that could potentially have an impact outside of the first user controlling and managing the subject alpha block 210, therefore it is impossible to remove an alpha block 210 from the AXEL blockchain.
Should a user wish to delete their account or otherwise end their participation in the AXEL blockchain, their private chain 295 (up to and including the most recent transaction information) may be removed from the AXEL blockchain. However, as previously stated, the private chain 295 information is backed up to the associated public chain 205 alpha block 210 for the specified user. In a preferred embodiment, the chain recovery 270 function allows a user to recreate and/or completely restore their private chain 295, up to and including the last authenticated transaction executed prior to the private chain 295 removal.
The communications and support 275 function manages system level communications that occur within the AXEL blockchain. This includes, but is not limited to, system level error messages, client/user error messages (in response to errors made by the client/user), technical support queries and responses, alarm and/or alert messages, and the like. In one preferred embodiment, a node may be malfunctioning or generating error codes and introducing them to the AXEL blockchain. The communications and support 275 function may send an error message to the subject node alerting them of the issues and asking them to correct the problem. In another embodiment, a user and/or node may introduce a faulty block into the AXEL blockchain causing the user reputation to diminish. The user and/or node would receive a notification from the AXEL blockchain through the communications and support 275 function, notifying the user and/or node of the subject change in their network standing/reputation.
The communications and support 275 function works in conjunction with multiple functions residing on both the public 205 and private 295 chains including, but not limited to, the AXEL database 250, the private chain history 230, witness administration 240, wallet and token administration 245, user ID info 255, network addressing 260, chain communications 235, and other functions that engage networking, addressing, and communications functionality within the AXEL blockchain.
The storage/CPU/mining 280 function governs three specific client functions within the AXEL blockchain. The AXEL storage/CPU/mining 280 component of the functional implementation manages the storage repositories of the registered user relating to their own personal storage as well as the storage repositories the user wishes to designate for use in a distributed network storage capability.
The AXEL storage/CPU/mining 280 function enables users to participate in a distributed decentralized network storage capability wherein users (at their total control and discretion) may choose to provide, donate, sell, or otherwise make available for network usage their spare storage space on their node and/or connected devices.
As an example, a user may express the desire to participate in the sale/lease/rental of their spare storage space on a home computer or connected drive through the AXEL blockchain network. The user will notify the AXEL blockchain of their intent to participate and provide information to AXEL as to the amount of storage space they intended to make available, the duration of the space availability, and any limitations they intend to place on the space (if any). The storage/CPU/mining 280 function will collect this information from the user and share it with the AXEL database 250 function. Any second user wishing to engage the storage space can do so through a marketplace or other resource sharing/pooling capability hosted within the AXEL blockchain.
When a user designates drive space as available to the AXEL blockchain, the alpha block 210 will engage multiple AXEL functions 201, including but not limited to the unified device ID info 265, the database 250, the user ID info 255, the chain communications 235, the wallet and token administration 245, the storage/CPU/mining 280 functions and potentially others.
The storage/CPU/mining 280 function provides a CPU pooling function to allow network users to make their CPU available for usage in virtual machine applications. In a similar fashion as shared previously with the network storage example, a user may wish to make their CPU available for virtual machine and/or aggregated computing functionality hosted within AXEL. This capability (as with the distributed decentralized storage described above) is managed through the storage/CPU/mining 280 function.
The virtual machine/aggregated computing functionality (storage/CPU/mining 280 function) enables AXEL to pool the resources of various participating nodes within the blockchain and make that processing power available to users who need more computing power than is currently available to them. Users will be notified by AXEL via the communications and support 275 and/or the AXEL communications 215 functions when their CPU is to be utilized by the AXEL blockchain to process advanced calculations on behalf of other participants in the AXEL blockchain.
As with the storage example provided previously, the storage/CPU/mining 280 function will engage multiple functions 201 within the alpha block 210 including but not limited to the unified device ID info 265, the AXEL database 250, the user ID info 255, the chain communications 235, the wallet and token administration 245 functions, and potentially others.
As an example, a first user may wish to make available both storage space and CPU processing power through the AXEL blockchain in return for tokens. This sale/rental/leasing configuration may be managed through a marketplace wherein a second user seeking these services may engage the first user selling/leasing/renting these services. In this example, the participants (first and second user) will manage details of their arrangement through the marketplace as they would in any eCommerce setting.
As a transaction is agreed to in the above example, a transfer of tokens would be managed by the wallet and token administration 245 function along with other AXEL functional elements 201 including, but not limited to, AXEL communications 215, user reputation 225, chain communications 235, witness administration 240, AXEL database 250 functions, and other functional elements 201 within the AXEL blockchain.
The AXEL mining capability managed by the storage/CPU/mining 280 function is the process in which a node participates in resolving a transaction utilizing the consensus algorithm and digitally signs the transaction, creating a new block.
Unlike traditional blockchains that incorporate a mining mechanism, the AXEL blockchain utilizes a mining pool concept (discussed in detail later in this submission) in which each participant in a subject witness (consensus) session will each receive a payment in the form of a utility token (or a relative percentage thereof) for their efforts in executing the consensus algorithm, regardless of whether they are the node that created the actual block or if they were only a participant.
As an example, the witness administration 240 function may select a group of 10 nodes randomly to perform consensus algorithm calculations to verify a subject transaction. Each of the 10 nodes participating in the consensus calculations would receive an identical payment in the form of a token (or a relative percentage thereof) provided they all reached the same consensus during the process. As discussed earlier, nodes failing to reach consensus during a transaction or otherwise introducing incorrect information into the blockchain would receive negative reputation credits for their participation and would therefore be ineligible to receive payment or positive reputation credits.
Mining and transaction consensus activities within the AXEL blockchain are governed by the storage/CPU/mining 280 function (once the witness administration 240 function has created the witness pool). It is important to note, as stated in the example above, a participant continuing to receive negative reputation may be prevented from participating in some or all activities managed through the storage/CPU/mining 280 function as well as other AXEL blockchain transactions.
As stated previously, the alpha block 210 is a component of the AXEL public chain 205. The purpose of the alpha block 210 is to give the public chain 205 visibility to the elements of the respective user necessary to ensure trust between the nodes and other users, while also ensuring a measure of privacy relating to the transactions of the individual user(s).
In general, alpha blocks 210 are publicly visible 298 but elements within the alpha blocks 210 may not be visible 299. As an example, each time a block is added to the private chain 295, the consensus result and digital signature which created the new block is updated 290 to the public chain 205 and the associated alpha block 210. Detailed information pertaining to the specifics of the transaction such as the name of a file or the file attributes and details may not be visible 299. Other information such as reputation and some components of the user network ID and addressing are publicly visible 298 as required to enable users to interact with each other and to participate in publicly available functions such as the distributed decentralized storage function, the distributed decentralized CPU (virtual machine) function, and the consensus algorithm (mining) function, and other file storage, sharing, transferring, and communications functions.
For the purpose of ensuring private transactions in a public blockchain environment, many functions 201 hosted within and associated with the alpha block 210 are hidden from public view 299. These include but are not limited to the AXEL A.I. 220, the private chain history 230, the wallet and token administration 245, the AXEL database 250, the chain recovery 270 functions, and other functionality that is of a personal and/or private nature.
Should a user or participant cancel their engagement with the AXEL blockchain or otherwise wish to delete their account and their associated transaction history, they may do so except as it relates to the integrity of maintaining historical information in support of other users in the AXEL blockchain. In no case can an alpha block 210 ever be completely removed or deleted from the AXEL blockchain.
As an example, a user may wish to delete their account and cease using the AXEL network. AXEL will remove the user's access to the public alpha block 210 and delete the private chain associated with that user entirely. The alpha block 210 will remain intact and active to ensure that transactions that occurred with the deleted user's participation (such as acting as a witness/executing consensus algorithms, mining, wallet and token exchange functions, and other aspects of functionality that impact other users) remains intact. Deleting an alpha block 210 would result in the activity of the respective user (including group activities such as witnessing transactions and digital signatures) being deleted. This would cause historical references to archived data and past transactions to fail as their references would be eliminated from the blockchain. It is for this reason the alpha blocks 210 may not be completely removed or otherwise deleted from the AXEL blockchain.
Should a user wish to restore their account and engagement with the AXEL blockchain, their original alpha block may be reactivated and their transaction history, up to the time they ceased their engagement with the network, may be restored.
As previously stated, the public chain within the AXEL blockchain network works in conjunction with the private (user) chain to manage, track, and store relevant information pertaining to the transaction history and overall user engagement with the AXEL blockchain. The private chain is separated from the public chain to allow AXEL to provide a level of privacy for users enabling private transactions to occur while still maintaining the legitimacy of the consensus algorithm/digital signature component and the subsequent public ledger visibility. The public ledger can remain visible and reflect that the transactions that occurred on the private chain were verified using the consensus algorithm, even though the details of the transactions that occurred on the private chain are hidden from view.
The witness mechanism provided within the AXEL blockchain is a method in which a consensus algorithm may be executed by a group of users (nodes) designated as witnesses for the current transaction being resolved by the blockchain. Witnesses are selected randomly by the AXEL blockchain (utilizing the witness administration function discussed previously with reference to
In a typical blockchain with verifications utilizing a consensus-type algorithm, all nodes participating in the network will work simultaneously to resolve the transaction and create the subsequent block to be added to the subject blockchain. While this consensus mechanism is accurate and gives all nodes (users) visibility to the current transaction being resolved, utilizing all nodes to perform the process limits the thru-put capability of the blockchain and slows the overall rate at which transactions can be verified.
One benefit of the witness mechanism disclosed herein is that it enables multiple transactions to occur and be vetted simultaneously. This will give all users (nodes) visibility to each transaction consensus while speeding up the overall thru-put and transaction speed of the AXEL blockchain. The witness mechanism utilized to create a group of participants to generate a consensus and create a block for the transactions performed within the AXEL blockchain will now be discussed with reference to
With continued reference to
As the transaction consensus session is concluded by the witness pool (witness 1320, witness 2325, and witness 3330) a new block will be created. The user 1 private chain 385 and the user 2 private chain 390 (as private participants in the subject transaction) will each create a block that provides the complete details of the subject transaction 345 and the associated approval therein. On the user 1 private chain 385, block 335 is added to reflect the transaction 345 that took place with user 2. On the user 2 private chain 390 a block 340 is created to reflect the details of the subject transaction 345 that took place with user 1.
As previously noted, the transactions within the AXEL blockchain take place in a private setting. As such, the witness blocks created to reflect the subject transaction 345 will include only the authentication and the digital identification reflecting the transaction but not the details of the transaction 345 that took place between user 1385 and user 2390 private chains.
As can be seen in
The witness blocks perform multiple functions within the AXEL blockchain. The primary function of the witness block is to provide ledger (chain) verification that the subject transaction took place and was verified. A second function is to ensure that a transaction that has been completed may not be altered, changed, or otherwise removed from the network to ensure multiple copies of the transaction record always exist. Due to the random nature of witness assignment within the AXEL blockchain, bad actors or users wishing to defraud the system will be unable to do so as they will not have visibility to the users (nodes) hosting the witness blocks to reflect the successfully verified and witnessed transactions. Therefore, they will be unable to access and alter, delete, or otherwise compromise the subject transactions.
The witness blocks (350, 355, and 360) are backed up and stored to their respective user alpha blocks (320, 325, and 330). This ensures there is always a record of each vetted transaction, even in cases wherein a witness private chain is deleted or a witness otherwise removes their account from the AXEL blockchain.
The user 1 private chain 385 and the user 2 private chain 390 will also update their respective alpha blocks (U1A 310 and U2A 315) with the newly added transactions represented by block 335 on the user 1 private chain 385 and block 340 on the user 2 private chain 390. Again, these blocks (335 and 340) will contain the details of the associated transaction 345 that took place.
In the event that a participant in a given transaction were to delete their account or otherwise remove their private chain from the AXEL blockchain, the transactional information will remain intact in the alpha blocks of the associated user. As shared previously, alpha blocks may not be completely removed or otherwise deleted from the AXEL blockchain to ensure integrity of all transactions that occur.
In conjunction with the witness mechanism as discussed with reference to
The purpose of the utility token is to allow participants within the AXEL blockchain to engage in transactions that would normally require a method of payment such as a credit card or similar currency mechanism. One benefit of the utility token is that it acts as a substitute for the typically utilized payment mechanisms to allow AXEL to be a completely self-contained system negating the need for an external payment mechanism. As such, participants within the AXEL blockchain can buy, sell, rent and/or lease services and products from each other and utilize the utility token as a form of currency within AXEL.
The mining pool functionality will now be discussed with continued reference to
As the consensus is reached and the mirror blocks 350, 355, and 360 are created on the respective witness private chains 380, 375, and 370, the respective witness alpha blocks 320, 325, and 330 notify the AXEL public chain 305 of the completed consensus and the subsequent transaction 345. The AXEL public chain 305 notifies the witness administration 381, the wallet and token administration 382, the storage/CPU/mining 386, and AXEL database 383 functions that the consensus/witness session has successfully concluded. Once the session has been verified by the witness administration 381 function, the witness administration 381 function notifies the wallet and token administration 382 and the storage/CPU/mining 386 functions of the utility token distribution to the respective witness pool. The AXEL public chain 305 will engage the AXEL database 383, the network addressing 384, the unified device ID info 388 and the storage/CPU/mining 386 functions to distribute the token reward for processing the subject transaction 345 during the current witness session.
Each witness participant represented in
A record of the token award to the above subject witness pool will be logged in each participant's private chain (380, 375, and 370) along with the AXEL database 383 function.
As discussed previously in this submission, the AXEL blockchain can incorporate elements of the PINApp which is incorporated herein by reference. AXEL can engage the PINApp technology to allow the unification of the storage repositories of client/user connected devices to enable access and management of the content stored on the client/user connected devices through the AXEL blockchain. This unification and connectivity to the AXEL blockchain negates the need for the AXEL blockchain gateway software to be present and functional on each of the client devices, and instead allows aggregation of both the device storage and the device access through a single gateway device. This capability enables a client/user to access, manage, transfer, and stream a file (as an example) that exists on a smartphone to a second user/recipient through the AXEL blockchain without having the subject file physically located on the gateway device. While PINApp provides certain advantages, it is contemplated that other systems with similar capabilities of PINApp could be utilized as well.
The implementation of the PINApp technology with the AXEL blockchain will now be discussed with reference to
With reference to
The functional elements of AXEL 430 and their engagement with the functional elements of PINApp 455 will now be discussed. The number of functional elements of AXEL 430 and PINApp 455 have been reduced down to provide clarity to the preferred functions.
With continued reference to
As an example of the engagement between the PINApp 455 and AXEL 430 functional elements, we assume a user (not pictured) who owns the list of devices (personal computer 425, smartphone 415, public cloud 407, tablet 405, and external hard drive 410) wishes to share a photograph (not pictured) that resides on smartphone 415 to the AXEL private chain 480 and subsequently the AXEL public chain 475.
The following example process (with continued reference to
The process begins with the personal computer 425 running the AXEL gateway sending a query from the AXEL database 440 function through the AXEL communications 432 function to the PINApp database 460 function to identify the photo being shared and the device (smartphone 415) the subject photo resides on. The PINApp database 460 function (knowing the location of the subject photo residing on the smartphone 415) will engage the file management and control 462 and the addressing and routing 470 functions to provide the AXEL database 440 function information on the exact location, file name, file address, and other associated data disclosing that the subject file resides on the smartphone 415.
The AXEL communications 432 function will share the location information with the AXEL database 440, the AXEL A.I. 435, the network addressing 442, and the unified device ID info 445 functions. These functions will enable the AXEL database 440 function to record and verify the location (smartphone 415) of the subject photo as shared by the referenced PINApp 455 functional modules.
Now that the personal computer 425 running the AXEL gateway has established that the location of the photo is the smartphone 415, the user (not pictured) may share the subject photo through the private chain 480 and subsequently the public chain 475. The recipient (not pictured) will access the subject photo directly from the user smartphone 415, negating the need to relocate, copy, move, or otherwise transfer the photo to a secondary-type repository.
By enabling the PINApp to work directly with the AXEL blockchain users can store, share, stream, and transfer digital content residing on any of their devices through the AXEL blockchain without the requirement to physically move or copy the respective digital content.
In a similar fashion as described above, any digital content residing on any of the devices (tablet 405, public cloud 407, external hard drive 410, smartphone 415, or even the personal computer 425 hosting the AXEL gateway) may be accessed and managed through the AXEL blockchain by the digital content owner hosting the subject digital content on the above referenced connected (utilizing PINApp) devices.
In another embodiment of the engagement with the functional elements of the PINApp 455 and AXEL 430 it may be assumed that a user controlling the subject connected devices (tablet 405, public cloud 407, external hard drive 410, smartphone 415, and the personal computer 425 hosting the AXEL gateway) chooses to engage in selling their spare storage space to other users in exchange for utility tokens through the AXEL blockchain. As with the above example, the following example assumes the subject user has already accessed their AXEL blockchain account and has engaged the PINApp and associated security and vetting protocol has been satisfied.
With reference to
The marketplace (not pictured) will query the user as to the amount of storage space they wish to make available for sale, the address location of the storage, and the time period or other restrictions the user/seller wishes to place on the sale/lease of the subject storage space.
The user may be accessing the marketplace (not pictured) from any of their reference connected devices, but for the purpose of clarity we will assume the user is utilizing the personal computer 425 hosting the AXEL gateway to configure the storage sale or lease. The user will notify the AXEL blockchain that they wish to make the storage of their external hard drive 410 available for sale or lease to other users within the AXEL blockchain. The AXEL communications 432 function will engage the personal computer 425 and the PINApp 455 functional elements to determine the location and addressing information of the storage space on the external hard drive 410 being put up for sale or lease.
Since the device (external hard drive 410) is connected to the local user network via the PINApp 455 functions, the AXEL communications 432 function will query the PINApp database 460 function to determine the location of the storage of the external hard drive 410 within the unified network. The PINApp database 460 function, knowing the address location of the external hard drive 410 will engage the user device management 457, the cloud server and API management 467, the contact database 465, and the addressing and routing 470 functions to notify the AXEL functional elements 430 of the location of the associated external hard drive 410.
Now that the location of the external hard drive 410 is known to the AXEL blockchain, the user (via the personal computer 425 running the AXEL gateway) will provide information to both AXEL 430 and PINApp 455 functional elements pertaining to the user being assigned access to the external hard drive 410 through the AXEL blockchain. Information such as user identification, email address, network address, login, and other access information will be provided to both the AXEL 430 and the PINApp 455 functional elements. The second user (leasing the storage space) access information (identification, email, network addressing, and login) will be added to the AXEL database 440 and to the PINApp database 460 functions. This information will also be available to and managed from the PINApp contact database 465, the cloud server and API management 467, the addressing and routing 470, and file management and control 462 functions under the PINApp 455 functional elements, as well as through the user ID info 437, the AXEL database 440, the network addressing 442, the unified device ID info 445, the storage/CPU/mining 447, and the AXEL DCA—Security 450 functions under the AXEL 430 functional elements.
Once the above transactions have been completed, a secondary user (not pictured) may be given access to the subject external hard drive 410 from a remote location from their own devices (not pictured). This secure access will be managed by, and limited to, the provisions as defined under the agreement through the marketplace (not pictured).
Functional elements as described above work in a variety of fashions to ensure the owner of the subject external hard drive 410 and the secondary user utilizing the storage space (not pictured) can maintain their privacy and security while enabling a level of trust to exist between devices since transactions associated with the AXEL blockchain are stored on the private ledger of each participant as discussed earlier in this submission.
As with other distributed and decentralized technologies currently being deployed, the AXEL blockchain does not incorporate a typical client-to-server relationship. The network capability including management of storage and computing resources are provided by users who create nodes to support the network. Therefore, resource management must be handled by the nodes in conjunction with the AXEL blockchain.
The management of network resources such as the availability of user/node provided CPU processing power (supporting the distributed computing function) and the availability of user/node provided storage space (supporting the distributed storage function) within the AXEL blockchain is actively monitored and reported by a resource assessment algorithm.
The resource assessment algorithm routinely queries the AXEL blockchain to determine resource allocation related to both CPU and storage usage as well as to determine the appropriate pathing and trafficking of transactions that occur within the AXEL blockchain.
The resource assessment and traffic pathing capabilities of the AXEL blockchain will now be discussed with reference to
As can be seen in
In one preferred embodiment, the resource assessment algorithm will periodically query the network (each node pictured 510, 515, 520, 525, 530, and 535) to determine the amount of unused (available) storage and compare that with the amount of storage that is currently being used by participants within the AXEL blockchain 505. The resource assessment algorithm will further run a comparison against storage use history to determine if the currently available storage (unused and available) is satisfactory to support what the algorithm determines as pending needs for the network.
As an example of the above embodiment (and with continued reference to
In a situation wherein the network resource (such as storage in this example) is satisfactory to support the network needs as determined by the resource assessment algorithm, no further action will be taken by AXEL. In a situation wherein the network resource is not satisfactory and more resource is needed, one or more nodes (including nodes currently providing storage such as nodes 525 and 530) will be notified of the need to add storage resources.
Since these nodes are independently operated by users on the AXEL blockchain, they will be invited to participate in supporting network resource needs in exchange for utility tokens (utility tokens) that are used as a form of currency within the network itself. The addition of network resources (such as additional storage space) is entirely at the discretion of the node operator. Should the nodes decide not to add more resources (such as storage) the AXEL blockchain will allow the remaining storage capability to be utilized until such a time as it is at capacity. Once capacity has been reached, the AXEL blockchain will disallow further requests for distributed storage until such a time as resources allow more storage to be provided by the network.
The resource assessment algorithm works in conjunction with other AXEL functional elements 507 to both collect current and relevant statistical information pertaining to the resource availability of the AXEL blockchain 505 as well as to compare and parse this information with historical information to determine the network needs for current and future resource allocation.
As an example (and with continued reference to
As discussed earlier, nodes both deploy and control network resources such as storage (as depicted by node 525 with storage 537 and by node 530 with storage 539) and CPU usage for virtual machine capability (not pictured). Both of these resource needs, along with a variety of others are managed through the resource assessment algorithm function.
Network node-provided resources are governed by not only the resource assessment algorithm, but the user reputation associated with the node(s). As discussed earlier in this submission, node reputation governs the extent at which a node can engage in activities such as providing a witness function, providing decentralized storage for the AXEL blockchain, or providing the CPU capability supporting the distributed computing mechanism (virtual machine capability). As an example (and with continued reference to
Assuming all of the nodes within the AXEL blockchain 505 are of an acceptable reputation level (as managed by the user reputation 545 and the AXEL database 560 functions), they will be notified through the chain communications 550 and the communications and support 580 functions of the pending needs of the AXEL blockchain 505 and be invited to participate in providing the required resource. Should a node be disqualified because of a negative reputation (as determined by the user reputation 545 and AXEL database 560 functions) they may be excluded from the network message inviting nodes to participate in providing additional resources. As previously stated, nodes that fall into disfavor within the AXEL blockchain 505 (through negative reputation) will be notified (through the chain communications 550 and the communications and support 580 functions) of their negative reputation and provided guidelines in which the reputation may be repaired. Long-term negative reputation or continued violations may result in the node being removed from participating in network functions, up to and including node deactivation.
As a component of the resource assessment algorithm, the AXEL blockchain 505 provides a mechanism in which transactional traffic can be governed and managed to reduce transaction times while abiding the needs of both the users and the network architecture. Intentionally redundant, the AXEL blockchain 505 (utilizing the resource assessment algorithm) factors into account aspects such as resource allocation, node reputation, node location, ping response times, and other elements to determine how best to manage transactional traffic through the blockchain. This process within the AXEL blockchain 505 is referred to as “weighting” and the above referenced variables determined through the resource allocation algorithm are utilized to determine the proper transaction pathing for a given transaction.
As an example of the weighting process managed through the resource assessment algorithm (and with continued reference to
Using the above example, we now assume that node 535 has a negative reputation. As the ping-type signal is executed from node 510 it will again be sent to node 515, 520, and 535. Node 535 will report the negative reputation which will require the resource assessment algorithm (weighting process) to either choose the pathing through node 515 or through node 520. It is important to note that secondary speeds are also considered in determining the most efficient pathing to support transactions.
As an example of the above embodiment, the resource assessment algorithm will seek a complete speed test utilizing the ping-type signal method engaging all nodes and all paths illustrated within
The AXEL blockchain provides a distributed decentralized CPU processing capability that enables multiple nodes to engage in processing against a user-required program in instances where additional processing power is needed to satisfy the user need. Functioning in a similar fashion to the distributed and decentralized storage capability (discussed below with reference to
The distributed decentralized CPU processing capability follows the same rules as the resource assessment algorithm with reference to traffic, pathing, node engagement, user reputation, and other functional aspects pertaining to the usage of the AXEL blockchain. The distributed decentralized CPU processing capability of the AXEL blockchain will now be discussed with continued reference to
A user 501 has a computer processing job 506 that needs to be executed. The processing job 506 is broken down into sections 509 by the AXEL blockchain 505. These sections 509 are then distributed to the nodes participating in the AXEL blockchain 505 CPU processing capability. As an example, the nodes receiving the sections 509 to be processed may be nodes 510, 515, 520, 525, and 530. As the processing job 506 is completed, the resulting sections 509 will be reconstructed by the AXEL blockchain 505 into a single file 506 and returned to the user 501.
The process is governed by the storage/CPU/mining 585 function and the associated AXEL functions 507 including (but not limited to) the AXEL communications 540, the user reputation 545, chain communications 550, AXEL database 560, user ID info 565, network addressing 570, and the AXEL DCA—Security 590 functions.
The distributed decentralized CPU processing capability (managed through the storage/CPU/mining 585 function) takes into account available resources, user reputations, and transaction times within the AXEL blockchain.
The AXEL blockchain provides a decentralized distributed storage capability that enables users to purchase and sell storage space that is attached to or otherwise managed through their AXEL blockchain connected device(s). In general functional terms, as a user engages the AXEL blockchain storage, digital content (such as a file) may be broken into multiple smaller parts, and then each of the parts may be encrypted to ensure both privacy and security of the stored content as well as to facilitate redundant storage wherein a component or part of a disassembled and encrypted file may reside on multiple storage repositories. The storage mechanism is governed by the AXEL blockchain and deployed and managed by the individual users participating in the sale of storage space within the network.
The decentralized and distributed storage capability will now be discussed with reference to
As can be seen in
Once the file 610 has been broken down into component parts 615 it is then encrypted. Once encrypted, it is distributed to the AXEL nodes (630, 640, 655, 660, 670, 680, and 690) for storage. As can be seen in
Nodes 670, 680, and 690 host the identical encrypted file parts (1, 2, and 3) shown as 675, 685, and 695 respectively, while node 660 has stored the entirety of the file parts (1, 2, 3, 4, and 5) as shown 665. As previously stated, the example referenced in
As previously stated, nodes are independently owned and operated by users within the AXEL blockchain. As such, they may choose to remove themselves from service with little or no warning at any given time. The resource assessment algorithm working in conjunction with the storage/CPU/mining function discussed previously will continuously verify the storage repositories and their associated contents to ensure that stored digital content is available to the users who own and manage them. In situations wherein a node is no longer available, the AXEL blockchain (utilizing the resource assessment algorithm in conjunction with the storage/CPU/mining function) will respond to the missing node and recover the missing stored content by copying the missing content (file parts) from a secondary storage point to one or more additional storage points (repositories) to ensure that the content remains available and backed up.
The storage recovery capability will now be discussed with reference to
As can be seen in
As can be seen in
The storage/CPU/mining 789 function will then engage the resource assessment algorithm to query the entire AXEL blockchain 720 network to determine the best location to create additional backup copies of the file parts from storage 795 (1, 2, and 3) that have gone offline. The resource assessment algorithm (in this example) reported that both node 755 and node 740 were/are suitable to support backup copies of the unavailable file parts from storage 795 (1, 2, and 3). The storage/CPU/mining 789 function will then copy the missing file parts from storage 795 (1, 2, and 3) from an existing location (storage 785 from node 780 as an example) and place them into one or more storages as indicated by storage 798 at node 740 and storage 799 at node 755. The quantity and location of the backup storage repositories (as previously stated) will be determined by the resource assessment algorithm. The algorithm will take into account transaction times and speeds, ping rates between nodes, user reputations, available space, and other attributes to determine the most suitable location for the backup file parts.
As previously discussed, anytime a node is utilized to support storage (such as described above) multiple functional components 759 of the AXEL blockchain 720 may be engaged. These functions can include (but are not limited to) the AXEL communications 749, user reputation 739, chain communications 729, AXEL database 779, user ID info 719, network addressing 769, unified device ID info 709, communications and support 704, and the storage/CPU/mining 789 functions.
The AXEL blockchain provides advanced user identification capabilities that allow transactions to occur within the blockchain that would otherwise require face-to-face interaction to ensure identity and transaction verification. Often referred to as AML/KYC (Anti-Money Laundering/Know Your Customer) capabilities, the AXEL blockchain incorporates a user identification mechanism that will allow (when desired based on the nature of the transaction and/or for compliance with laws and regulations) two or more users to participate in a transaction across the blockchain, such as a purchase of an automobile or other high cost item, without the requirement that all parties are in the same place to facilitate the transaction.
The user identification mechanism (AML/KYC function) can be used to support transactions that may require compliance with local, state, federal and/or international laws, as well as ensuring geographical areas under sanction by another governing body can be prevented from participating within the network as governing laws may require or mandate.
In one advantageous embodiment, the user identification (AML/KYC) mechanism utilizes portions of the Digital Certification Analyzer (DCA) U.S. Pat. Nos. 9,419,965; 9,565,184; and 9,723,090 to perform verification of the user and the device being utilized by the user. The user identification mechanism is designed to be implemented in layers within the AXEL blockchain. As an example, a user may be required to only provide an email address and other identification to participate in the network if they choose not to operate a node or to otherwise not participate in providing functional services to support the network such as the distributed computing/CPU capability or the distributed storage capability. Conversely, a user wishing to provide these types of services through the AXEL blockchain may be subject to further identification and verification such as (but not limited to) passport number, driver's license number, photo ID, or more distinct and descript identification information to ensure that the party's identification can be verified.
The user identification (AML/KYC) mechanism can utilize components of both the PINApp and the DCA to collect and manage information associated with both the user participating in the network as well as the device(s) utilized by the user to engage the network.
The functional aspects of the user identification within the AXEL blockchain will now be discussed with reference to
As can be seen in
PINApp reports the device identification of each of the subject user devices (tablet 845, public cloud storage repositories 850, smartphone 855, personal computer 860 running the AXEL gateway software, and an external hard drive 865) to the AXEL database 815 function. This information is stored within the AXEL database 815 function in conjunction with the user account creation and login information.
As an example of the functional elements during a login session wherein the user is seeking to gain access to the AXEL blockchain, we assume the user is logging into their account through the tablet 845. The user will enter their login criteria and submit it to the AXEL DCA—Security 840 function. The AXEL DCA—Security 840 function will engage the AXEL database 815 function to authenticate information including (but not limited to) the user login information, the tablet 845 unified device ID info 830, the network address 825 of the tablet 845, the user ID info 820, and potentially other functional elements to verify (a) the user credentials and (b) the device authorization. Should a user provide a valid user identification and an invalid device authorization, the login attempt will fail. Conversely, if the user identification is invalid but the device is authorized, the login attempt would again fail.
The AXEL DCA—Security 840 function will be engaged each time a user seeks to access the AXEL blockchain or any associated device, even after they have achieved a login session. As an example, we assume the user has logged into the tablet 845 as stated above. The user then wishes to access content stored on their external hard drive 865 that is unified with other client devices (tablet 845, public cloud storage repositories 850, smartphone 855, and personal computer 860 running the AXEL gateway software). As the user access request is initiated, the AXEL DCA—Security 840 function will access the AXEL database 815 function to collect the unified device ID info 830, the user ID info 820, and the network addressing 825 to ensure that the user (via tablet 845) is authorized to access the external hard drive 865.
As previously stated, the AXEL DCA—Security 840 function will verify multiple data points including (but not limited to) user identification info 820, network addressing 825, and unified device ID info 830 along with a PIN and TOKEN mechanism that is a component of the DCA to ensure the user is authorized to access the information stored on the subject external hard drive 865.
The above process will repeat through the system anytime a user wishes to engage any of the unified local network (801) devices that comprise their registered device network utilized within the AXEL blockchain.
In instances wherein a user local network 801 is providing storage (such as the external hard drive 865) for sale or usage by the AXEL blockchain, the AXEL DCA—Security 840 function will verify (utilizing the process above) both the user/owner of the storage device as well as any user(s) registered within the AXEL blockchain who is given permission to access the storage. The verification for the user(s) accessing the storage will include a check of permissions as set by the user/owner of the storage and hosted within the AXEL database 815 function. As stated previously, these permissions will be set at the time the distributed storage capability is offered publicly for use by the user/owner of the storage device.
The user verification process described above operates continuously throughout the AXEL blockchain at any time a user wishes to engage any device registered within the network. This prevents a user from logging into a network-accessible account on a registered device and then subsequently switching out that device for one that is not registered to the network.
The AXEL blockchain provides a payment and financial management mechanism (AXEL Pay) that enables a user to participate in a financial transaction without the need for the user to actively hold the currency (token) utilized on the AXEL network.
AXEL Pay allows the blockchain to engage with external financial institutions such as banks, cryptocurrency exchanges, and other financial facilitators to enable the user wallet to perform a currency exchange function automatically without the intervention of the wallet owner.
In one preferred embodiment, a user may execute a transaction within the AXEL blockchain without having any AXEL tokens (the native token for the AXEL blockchain) in their wallet. The AXEL wallet will automatically connect with the financial institution the user has pre-selected to manage the token exchange and perform this function. The external financial institution will remove currency (USD or other) from the user's pre-determined payment method (a bank account number, checking/savings account number, a debit or credit card, or other acceptable payment method) and exchange the currency for tokens to be used on the AXEL blockchain. The transaction requested by the user will then be executed through the wallet with the AXEL blockchain to pay for the subject transaction.
One purpose of AXEL Pay is to eliminate the need for a user to manually engage an external source such as a cryptocurrency exchange and move tokens between accounts in order to perform a purchase. AXEL Pay eases the adoption of blockchain technologies as it negates the need for any external currency exchange to be manually performed by a user.
A preferred embodiment of AXEL Pay will now be discussed with reference to
With reference to
Now that the user 905 has received an authentication 924 to create a secure connection with their AXEL blockchain account, the user 905 can begin the process to access their wallet admin 935 to make a transaction on the AXEL blockchain. The user 905 now sends a request 927 to the unified device info 925 to access their wallet admin 935 in order to facilitate the transaction. The unified device info 925 (provided by the PINApp) returns the wallet admin 935 location ID information 929, indicating the device (not shown) that the wallet admin 935 resides on. It is important to note that since the PINApp unifies all user devices (smartphones, tablets, external hard drives, laptop pc's, etc.) that the wallet may reside on a device other than the device hosting the AXEL gateway software.
With continued reference to
Now that the user 905 has access to the wallet admin 935 administration functions, the user 905 can request 941 a transaction. The wallet admin 935 reviews the contents of the wallet to determine if the wallet contains the (a) type and (b) amount of currency required to facilitate the subject transaction. If the wallet admin 935 determines that the wallet contains both the type and amount of the currency required for the subject transaction, the wallet administration 935 will return 943 an acknowledgement to the user 905, enabling the subject transaction to process.
If the wallet administration 935 determines that the wallet does not meet both of the required criteria (the amount and type of currency required to facilitate the transaction) the wallet administration 935 will engage 946 the financial administration 940 function that provides interaction with external banking and financial resources and governs the preset minimums and maximums that the user 905 has provisioned for their wallet administration 935 to govern financial transactions.
The financial administration 940 will notify 949 the secure API portal 945 of the AXEL blockchain that an external function is required. The secure API portal 945 will notify 951 the secure financial API portal 950 associated with the financial or banking institution 955 of the pending transaction 953. The secure financial API portal 950 will authenticate the user 905 info received 951 from the AXEL blockchain secure API portal 945 based on the criteria 957 determined by the financial or banking institution 955.
Once the authentication of the user 905 has been completed through the secure financial API portal 950 of the financial or banking institution 955, the wallet administration 935 and the financial administration 940 can authorize and send/receive funds based on the criteria set by the user 905.
For the purpose of this example, it is assumed that the user 905 has authorized their financial or banking institution 955 to release funds (in the associated currency type required for the user 905, the blockchain, and the geographic area where appropriate). The secure financial API portal 950 will notify 953 the financial or banking institution 955 of the authorized transaction request. The financial or banking institution 955 (assuming the funds in quantity and type are available) will reply 957 to the secure financial API portal 950 that the requested funds (quantity and type) are available for the subject transaction(s) and have been authorized. The secure financial API portal 950 will reply 959 to the AXEL blockchain secure API portal 945. The AXEL blockchain secure API portal 945 will notify 961 the financial administration 940 of the authorization of the transaction. In turn, the financial administration 940 will notify 963 the wallet administration 935 that the transaction has been authorized. The wallet administration 935 will then release the funds (not shown) to facilitate the transaction and notify 966 the user 905 that the subject transaction has been completed.
As previously discussed, the AXEL chain communications 960 and the AXEL database 965 record the communication between the user 905 and the subject modules discussed above to ensure that a permanent record of all transactions are available for the user 905.
While the discussion with reference to
It is important to note (with respect to
While the AXEL Pay discussion above with reference to
The AXEL Pay function allows the management of crypto-type currencies, utility tokens, fiat and other monetary/utility-type payment vehicles. AXEL Pay additionally provides for the use and provisioning/management of both user-owned and controlled wallets and other secondary online/offline fiat and/or token storage repositories, as well as the engagement of external third-party banking and other financial resources as discussed above with reference to
As previously discussed, the wallet and token management (via AXEL Pay) works in conjunction with the financial administration and secure API functions to engage external third-party financial institutions such as banks and token marketplaces. Internally, the wallet and token administration control the management of both fiat currency and tokens (or cryptocurrencies).
In one embodiment, the wallet and token management allows a party to manage the engagement of (a) an external banking or financial institution such as a token marketplace or a brokerage account; (b) a local wallet on a user owned device; (c) one or more secondary wallets such as an online/offline vault and/or hardware wallet(s); or, (d) any combination thereof.
In one embodiment, the local user wallet and all secondary token/fiat repositories are managed through the AXEL blockchain wallet and token administration function. While it is not necessary, and for security reasons, may not be advisable that all wallets (primary, secondary, vault or other) be located on the same device, AXEL Pay does not preclude such. The primary and secondary wallet management will now be discussed with reference to
With reference to
The wallet admin 1035 allows a user to provision the user wallet 1025 and the user vault 1030 with minimum and maximum parameters concerning the quantity of tokens, fiat currency or both that is carried and managed by the reference resource. In one embodiment, a user may set the wallet 1025 to a $10 USD minimum on fiat currency. Should the wallet 1025 drop below the $10 USD minimum, the wallet admin 1035 may query the user vault 1030 seeking the funds necessary to bring the user wallet 1025 back to the minimum requirement. If the funds exist in the user vault 1030, they will automatically be transferred to the user wallet 1025 and the user (not pictured) will receive a notification that the AXEL Pay system has moved the associated funds.
In a similar manner as above, the wallet admin may find that the user vault 1030 does not contain the funds required to satisfy the user wallet 1025 minimum and therefore query the third-party banking 1060 or other provider institution as chosen by the user. The wallet admin allows the provisioning of the user wallet 1025 and the 1030 to ensure that minimum and maximum funds in either tokens, fiat or both is managed to the user specifications. The wallet admin 1035 may also be provisioned to manage any and all transfer activity into and out of 3rd party institutions (such as the banking 1060 institution).
Should the wallet 1025, the user vault 1030 or the user third party banking institution 1060 become unavailable, the wallet admin will default to the next available repository and notify the user of the unavailability of the resource that cannot be contacted.
As with all functional aspects presented in this submission, all transactions that occur on the AXEL blockchain can be managed via the chain communications 1055. All transactions can be stored and managed by the AXEL database 1050. While
The AXEL blockchain provides a unique token identification system and method that allows the blockchain to assign a unique identifier to a token or a fractional component thereof. In one embodiment, the AXEL blockchain may generate a token through a process of mining. As the token is mined (generated by the blockchain as a potential reward to a node for resolving a contract) it may be assigned a unique identifier that allows the blockchain to identify the token in the presence of other tokens of the same or different denomination(s).
The token identification system facilitates for both native (tokens generated on the host blockchain, in this case, the AXEL blockchain) and tokens that are introduced to the AXEL blockchain from an external source. In one embodiment, a token such as Bitcoin may be introduced into the AXEL blockchain network. Upon initial introduction, the AXEL token identification system will assign the Bitcoin a unique identifier for the purpose of tracking the movement of the token through the AXEL blockchain. While native tokens within the AXEL blockchain network (AXEL tokens) will be provided a unique identifier as part of the original token generation and subsequently become a part of the token contract (the digital contract that is utilized to generate the tokens on their native blockchain, in this case the AXEL blockchain) itself, non-native tokens (such as Bitcoin) will be assigned an immutable identifier that does not modify the token contract in any way. Please note that the token contract may vary between blockchains, depending on the nature and usage of the token being generated by the contract and the subsequent needs of the blockchain. In the case of the AXEL token which is native to the AXEL blockchain, the tokens are generated at the genesis of the blockchain and will be created and subsequently governed by the criteria detailed by the subject token contract.
The token identification system and method provides a non-intrusive method to track the use and movement of tokens throughout the AXEL blockchain network, secure the AXEL blockchain network and tokens thereof, or both. In one embodiment, a user may report that their wallet (user-owned token repository) was breached and tokens were removed and/or stolen. The token identification system may identify the time, date, and address of the user wallet that each token was removed from, the path through the network they traveled, the repository they were moved to, and where they now reside (if the repository/wallet now hosting the subject stolen tokens resides on the AXEL blockchain network). The token identification system, working in conjunction with the AXEL A.I., the AXEL database, and the chain communications, may then choose to make those tokens invalid for use on the AXEL blockchain, rendering them useless as a currency on the network. Even if tokens are not able to be presently located, making the tokens invalid for use on the AXEL blockchain could potentially render the tokens unusable on the network whenever they return to it. If the tokens later become legitimate once again, for example, upon return or recovery of the tokens, they may again be activated by the AXEL blockchain and eligible for use. This function is uniquely designed to enable transactions between parties (such as a business-to-business environment) wherein managing the movement of funds is mandatory for authenticating valid transactions, as well as providing a layer of security for the subject transactions.
In instances wherein the token identification system and method is present during the generation of the native tokens (as is the case with AXEL tokens on the AXEL blockchain), the token identification system and method would prevent the duplication of these native tokens, as well as the use of similar tokens introduced to the network that did not contain a valid immutable identifier assigned by the token identification system. In one preferred embodiment, the token identification system and method would identify and subsequently deny the use of the AXEL token (forgeries) generated outside of the AXEL blockchain network. In a similar fashion, the token identification system and method would prevent the generation of, or introduction of, AXEL tokens with identical immutable identifiers. It is noted that tokens may be secured, such as by invalidation as described above, in response to duplication, double spending, unauthorized access/use, or other security events. It is important to note that the token identification system and method, like many of the functional elements of the AXEL blockchain, may be incorporated on a 3rd party blockchain or other networking configuration. In such cases, the functional elements of the token identification system described herein would perform in a similar manner. In cases wherein the token identification system and method is introduced into a blockchain where the native tokens are already created, the token identification system would provision for immutable identification of the existing tokens as well as provide for identification of tokens that are subdivided or otherwise partitioned, making multiple tokens from a single source token. As an example, if a native token has a value of 5 cents USD and is broken into 5 one-cent tokens, each of these tokens would be provisioned with an immutable identification by the token identification system and method.
The token identification system and method prevents duplication of a token on a blockchain network. In one embodiment, an AXEL token is generated by the network and is created with a unique immutable identifier. Should a second AXEL token be introduced to the network or otherwise appear either (a) without an identifier of any kind (b) containing a duplicate identifier (c) containing an identifier that is unauthorized by the network, or (d) any combination thereof, the newly introduced token would be invalidated.
The purpose of the token identification system is to enable the AXEL blockchain to account for, to track, to identify, and to protect all of the cryptocurrencies and/or tokens that are moving through the blockchain. In one preferred embodiment, a user wallet may be compromised or otherwise accessed by an unauthorized user. The wallet owner may report this wallet breach as a security event and the tokens (via the unique identification method) can be tracked to determine where they were moved to on the blockchain and what was done with them. Alternatively, or in addition, suspicious activity with regard to a wallet may be detected by AXEL DCA security, an A.I. (artificial intelligence) system, or the like.
In another embodiment using the same example (an unauthorized wallet breach) the tokens that were stolen may be disabled on the AXEL blockchain, rendering them useless. For tokens removed from the AXEL blockchain and taken to an external sales outlet such as a token exchange or other marketplace, the unique token identification can be shared with these 3rd party markets to ensure that if stolen tokens appear for sale they can be identified immediately and subsequently blocked from public exchange or sale or may otherwise be rendered ineligible for exchange or sale by the token marketplace (depending on how the 3rd party market chooses to deal with stolen tokens).
In applications such as business-to-business financial transactions, the token identification system may provide an added level of security for the subject transactions. All parties may be made aware that the tokens are identified and unique, and therefore harder to manipulate for fraudulent purposes.
One preferred embodiment of the token identification system will now be discussed with reference to
With reference to
The components of the token identification system on the private chain network layer 1110 are the network addressing 1135 function, the user self-sovereign ID 1140, the private chain communications 1145, the wallet and token administration 1150, and the private chain history 1155 functions. These functional elements work together to track the token movements on the private chain.
A monitoring system, the AXEL DCA security 1130, monitors the token movement both on the public chain network layer 1105, the private chain network layer 1110 and the movements of the tokens between these chains that is managed by the chain communications 1120 and 1145 respectively. While all of the functional elements of the AXEL blockchain have been detailed previously in this submission, some may be expanded on in the following example to provide clarity to the aspects each functional element provides in relation to the token identification system within AXEL
As an example of the functional implementation of token identification system (and with continued reference to
As previously stated, the AXEL blockchain has both a public chain and a private chain component. The token identification system and method also tracks and records the token movement on the private chain. As an AXEL token 1160 is moved to the private chain (via the public chain communications 1120, through the AXEL DCA security 1130 and into the private chain communications 1145), it is picked up by the wallet and token administration module 1150 enabling the AXEL token 1160 to appear in the user wallet (not pictured). As the AXEL token 1160 enters the private chain network layer 1110, it is recorded to the private chain history 1155. The private chain history 1155 records all token movement on the private chain held by each individual user.
The user self-sovereign ID 1140 is used by the AXEL blockchain to identify the user to ensure the tokens moving through the AXEL blockchain arrives at the appropriate destination. The record of a token being sent and/or received is tied to both the user self-sovereign ID 1140, the network addressing 1135 of the user and the wallet & token administration 1150. It is important to note that these functional modules work in conjunction with the AXEL DCA security 1130 to positively identify the user, ensuring that any access to the above modules (user self-sovereign ID 1140, wallet and token administration 1150, and private chain history 1155) are associated with the proper user.
In a similar fashion to the movement of an AXEL token 1160 from the public chain network layer 1105 to the private chain network layer 1110 and ultimately to the user wallet (via the wallet and token admin 1150), the transfer of tokens in the reverse direction takes a similar path. As an example (with continued reference to
Among other things, the token identification system and method detects and prevents security events that are common in blockchain, and which create doubt as to the authenticity of tokens, such as “double spending”. A double spending occurrence happens when a token is utilized in a transaction and the subject transaction is processed twice. The token identification system and method prevents this as the AXEL blockchain (in conjunction with the token identification system and method) does not allow a token that is currently in-use (being managed through a transaction) to participate in any additional transactions until such a time as the first transaction has been resolved and recorded to a block.
It is important to note that while the embodiments detailed herein, including the token identification system and method, are described as working in a multi-chain environment, all functional elements of the AXEL blockchain may be incorporated into any networking environment wherein digital or electronic transmissions occur.
As stated previously, AXEL can also interface with a distributed database to provide additional benefits. AXEL includes a distributed database function that allows the collection and storage of file and transaction data from a distributed database. A distributed database refers generally to the use of multiple computing and/or storage devices that are not all attached to a common processor to store data. For example, A distributed database may be deployed across multiple computing and/or storage devices that may or may not be collocated, and may or may not be within the same network. Portions of the database are stored in multiple physical locations (distributed) and the processing is distributed among the multiple database nodes (computing and/or storage devices). A transaction occurs when two or more of the storage devices interact with each other. For example, this may include storage or retrieval of data, and transaction data can include any data associated with a transaction. It is contemplated that AXEL can interface with a transaction database to preserve transaction records.
For example, in one embodiment, the transaction data stored by the distributed database creates a unique hash that allows the identification within the database of the data stored. One skilled in the art would understand that a “hash” is a record of an event that is intended to be immutable. It could include any data or record of that event and could be recorded and stored in any format. This hash is reported to the AXEL blockchain, which immutably stores this hash to preserve the record of the transaction. The database and the AXEL blockchain now both have a copy of the same hash.
The AXEL blockchain reports the newly created hash back to the distributed database which in turn, stores the hash created by the AXEL blockchain. With the AXEL blockchain and the distributed database each recording the unique transaction hash of the other for each transaction, the AXEL network can immutably store all transactions in addition to simultaneously creating a complete backup of each transaction record, and storing them separately in two completely different mediums. The separation of the storage mediums is vital in ensuring and maintaining the accuracy and integrity of the AXEL network.
The importance of a distributed database working in conjunction with a blockchain is shown in a variety of embodiments. In one embodiment, the blockchain and the database will carry the same transaction information along with historical data that can be used as both a backup and recovery mechanism for either the blockchain or the distributed database. By enabling both the blockchain and the distributed database to independently and collectively record all transaction information that occurs on the AXEL blockchain network, these two recording mediums can be used to cross-check each other to ensure accuracy of record for the entire network. In cases where a discrepancy exists between these two records, the AXEL network may revert to the last matching record and correct the network transaction records accordingly. It is important to note that while the distributed database is described as being deployed in conjunction with the AXEL blockchain, a distributed database may be deployed to interface with any blockchain architecture to achieve the benefits described herein.
The distributed database may be deployed in parallel to the AXEL blockchain, riding on all nodes within the AXEL network, or it may be deployed among a smaller group of nodes. In either deployment method, the distributed database may be configured to have the capability to capture and record transactions for the entirety of the AXEL network and across all nodes. More specifically, the distributed database may be used to mirror the transaction recording of the blockchain exactly. This enables the distributed database to act as a full backup of the records stored on the blockchain. Conversely, the blockchain may be used as a full backup of the records stored on the distributed database.
The distributed database can also serve as an alternative method to the traditional smart-contract management systems deployed within legacy blockchain networks. The distributed database provides more flexibility in data storage, metadata recording, and overall enhancement of transaction speeds within the AXEL blockchain network. One embodiment of a manner in which a distributed database is used as an alternative to a smart contract is described next, but it should be recognized that using the distributed database function in any blockchain to supplement or provide an alternative to a smart contract.
In one embodiment, the AXEL blockchain utilizes either the distributed database or the smart-contract methodology for creating transaction records, depending upon the needs of the specific transaction. For example, a simple transaction of sending a token from one person to another may be managed by a smart contract, whereas a folder being uploaded to the distributed decentralized storage may be managed by the distributed database. It is important to note that in either case, the transaction hashes created during the transactions will be stored in both the AXEL blockchain and the distributed database. Again, this ensures network integrity and accuracy of record.
The functional interaction between the AXEL blockchain and the distributed database will now be discussed with reference to
As can be seen in
The distributed database 1215 then sends the hash 1230 to the blockchain 1235 to be recorded. In turn, the blockchain 1235 receives the hash 1230 from the distributed database 1215 and generates a hash 1240 to represent the transaction and returns that hash 1240 to the distributed database 1215. The distributed database 1215 records 1245 the hash 1240 received from the blockchain 1235.
As can be seen in
By keeping identical running records of each transaction within two separate mediums, AXEL can ensure transaction and data storage custody and integrity throughout the network, as well as creating an immutable storage medium for transaction records. Though described above with regard to file folders, it will be understood that custody and integrity can be ensured for individual files or other content as well.
As previously stated, the distributed database 1215 and the blockchain 1235 are recording hashes created by one another that mirror the transactions, ensuring complete accuracy of record and a backup mechanism to ensure network integrity. Transactions involving the tokens are also managed and recorded in a like fashion as was presented with reference to
It should also be noted that it is recognized that the same function could be accomplished with fewer hashes. For example, in a token transaction on the blockchain, it is possible that the blockchain 1235 may create and record a hash and send it to distributed database 1215. The distributed database 1215 would receive and record that hash. It is contemplated that in one embodiment, the system may not create further hashes. Thus, while in the example above, the distributed database 1215 then creates another hash and returns it to the blockchain to be recorded, that step need not necessarily occur. One of skill in the art would recognize that a system could be designed to include more or fewer redundancies by creating and sending hashes by and between the distributed database 1215 and the blockchain 1235. However, at least some benefits of using a distributed database in conjunction with a blockchain will be realized so long as at least one recording is made on both such that if it is lost or altered in one place it will still exist in the other. Similarly, it is recognized that more hashes may be created and exchanged between the blockchain and the distributed database. This could be used, for example, for additional security or to ensure even better authenticity.
Functionally, the AXEL blockchain allows for transactions including the storage, sharing, streaming, and transfer of digital content such as files, folders, videos, audio recordings, and other content between both users and from a file owner to a distributed storage repository. An example of the interaction of the distributed database with the blockchain during a simple file upload to a network controlled distributed storage repository will now be discussed with reference to
With reference to
The AXEL network gateway/UI 1305 displayed on the user computing device (not shown) is collecting the user 1301 selections (1320, 1325 and 1330) to report to the AXEL network.
Once the user 1301 has completed their input (1320, 1325 and 1330) the AXEL network gateway/UI 1305 submits 1335 the client selections and file data to the decentralized storage system 1315. The decentralized storage system 1315 will calculate the storage costs based on the criteria (1320, 1325 and 1330) entered by the user 1301 and return a summary 1340 of the cost for storage and the user criteria (1320, 1325 and 1330) entered to ensure accuracy of the transaction. Assuming all of the information is satisfactory to the user 1301, the user 1301 will agree 1345 to the storage cost and parameters presented by the decentralized storage 1315/1340 and process the payment 1345.
The AXEL blockchain 1309 will create a unique hash of the token transaction (payment) and submit that hash to be recorded 1350 by the distributed database 1310. Once the payment record 1350 is completed, the file upload 1355 will take place. The decentralized storage 1315 receives and stores the file 1355 and notifies 1357 the AXEL network gateway/UI 1305. The newly uploaded file will appear 1359 on the AXEL gateway/UI 1305 as a confirmation that the file upload is complete.
Now that the file has been uploaded to the decentralized storage system 1315, the system creates a hash 1360 that points to the file location in the storage repository. The hash 1360 also contains information about the file size, storage duration, keywords, and other metadata pertinent to the identification of the file being stored. This hash 1360 from the decentralized storage 1315 is shared with the distributed database 1310. The distributed database 1310 records 1365 the transaction hash it has received from the decentralized storage 1315.
The distributed database 1310 now records 1370 the user generated file descriptions, keywords, and other metadata collected by the AXEL network gateway/UI 1305. The distributed database 1310 generates a hash 1375 to identify the user generated keywords and other metadata assigned to the stored file 1370 and reports this information hash 1375 to be recorded by the AXEL blockchain 1309. Once recorded by the AXEL blockchain 1309, the AXEL blockchain 1309 creates a hash 1379 of the newly stored information 1375 and returns the hash 1379 to the distributed database 1310.
The distributed database 1310 records the hash 1379 received from the AXEL blockchain 1309 and reports the completed transaction hash including all metadata 1380 and user entered keywords to the AXEL network gateway/UI 1305. The user 1301 now has a complete record 1385 of the entire transaction including all file locations, storage duration, cost, and metadata created to identify the file within the decentralized storage 1315.
As can be seen in
The distributed database and the blockchain work in conjunction for all transactions that occur within the network. This includes, but is not limited to, file uploads (as described above with reference to
Another example of the interaction of the distributed database and the blockchain can be seen in a transaction wherein a file is shared or transferred between a file owner and a recipient. A typical file share/transfer function within the AXEL system will now be discussed with reference to
It is also important to note that the following example assumes the file owner has already logged into the system and authenticated their access and rights to the file content being shared/transferred. The login and access information has been purposefully omitted from the example being presented to keep focus on the preferred embodiments.
As can be seen in the example depicted by
The decentralized storage 1413 initiates the file transfer/share 1465. The decentralized storage 1413 notifies the AXEL network gateway/UI 1405 that the file transfer/share has been initiated. The AXEL network gateway/UI 1405 notifies 1470 the recipient 1415 of the pending file share/transfer waiting. This notification is sent to the recipient 1415 in the manner selected by the user 1401 in step 1430. The AXEL network gateway/UI 1405 also notifies 1475 the user 1401 that the file transfer/share has been initiated.
The recipient 1415 now has access to the shared/transferred file 1180. Once the recipient 1415 accesses the file 1480, the decentralized storage 1413 creates a hash 1485 as an indication that the file has been accessed by the recipient 1415. The file hash created 1485 is reported to the distributed database 1410. The distributed database 1410 records the hash 1490 generated by the decentralized storage 1413, and then creates a hash to be shared to the AXEL blockchain 1407. The AXEL blockchain 1407 records 1492 the hash 1490 received from the distributed database 1410 and the hash 1485 received from the decentralized storage 1413. The AXEL blockchain then creates a new hash reflecting the recording of the hash received (1490) from the distributed database 1410 and the hash (1485) received from the decentralized storage 1413. The AXEL blockchain 1407 reports this new hash 1495 to the distributed database 1410. The distributed database 1410 records the hash 1495 created by the AXEL blockchain 1407.
Once the distributed database 1410 records the hash 1495 created by the AXEL blockchain 1407, the distributed database 1410 notifies 1497 the AXEL network gateway/UI 1405 that the recipient 1415 has accessed the shared/transferred file. The transaction is now complete 1499 and the information is immutably stored on both the AXEL blockchain 1407 and on the distributed database 1410, ensuring an accurate transaction record and a complete backup of all transaction information. Each hash shared and recorded between network elements (the AXEL blockchain 1407, the distributed database 1410 and the decentralized storage 1413) points directly to the associated transaction being recorded. Each hash represents metadata, file/folder information, user/recipient information, encryption information, file/folder location data, and any other information pertinent to the file/folder, the user/recipient, and the transaction taking place. This may include transaction cost information, time/date stamping, and a record of the node(s) performing the storage and the file share/transfer transactions. Other data such as regional information, network latency, transaction times, and additional metrics on the overall performance of the network may also be kept within the hash created by the referenced network elements.
AXEL also provides a novel public and private key generation protocol and method that is intended to enable advanced key security while also enabling the generation of the keys to be immediate and each key to be unique. As is known in the art, public and private keys are used to manage wallet access and functionality in a blockchain/token/cryptocurrency environment. Often, a public key is used to enable the wallet owner to receive tokens/cryptocurrency/funds from others. The public key is shared publicly to enable others to send tokens/cryptocurrency to the wallet owner. The private key is designated for use by the wallet owner to manage funds and transactions as the wallet owner/manager. The private key is used solely by the wallet owner and is kept private. The private key may be required for a client/user to transfer funds between wallets, or to transfer funds to one or more recipients.
The key creation functionality is managed by a wallet and token administration function. In one embodiment, each time a user account is created within the AXEL blockchain, a wallet is generated to enable that user to manage the native network tokens. Having a wallet allows the user to send, receive and otherwise manage all token transactions that occur within the wallet.
The functional elements of the wallet and token administration will now be discussed with reference to
With reference to
In one or more embodiments, a network node may be a computing device, such as a server, network appliance, or the like. A network node may comprise one or more processors and communication devices. A network node may be operated, setup, and maintained via local input/output devices, such as human interface devices, display devices, or the like. A processor, which may be a microprocessor, controller, integrated circuit, or the like, may provide the functionality of a network node disclosed herein by executing instructions integrated into its circuitry or stored and retrieved from a non-transitory storage medium for execution by the processor. In general, a communication device will be provided to implement communication with other devices, such as other network nodes and client devices 1555. One or more storage devices, memory devices, or both may be part of a network node as well, such as to provide long term (e.g., hard drive or solid state drive) or short term (e.g., random access memory or cache memory) data storage, respectively speaking.
In a preferred embodiment, prior to accessing any of the wallet 1501 functional modules, the client/user 1555 must be logged into the system and have passed security requirements managed through the AXEL DCA security 1560 as detailed previously with reference to
Wallet communications admin 1505 enables wallet and token operating system 1530 to directly engage with chain communications 1575, which in this embodiment manages communications for the entire AXEL system (not pictured). As communications and commands are received by wallet and token admin operating system 1530, they are directed out to the appropriate functional modules based on the commands being processed.
Transaction management module 1510 is responsible for tracking and reporting all aspects of wallet and/or token transactions that occur during operation. For example, the transaction manager may collect information about a token being transferred into or out of wallet 1501. This information may include the session ID, the quantity of tokens transferred and/or received, the time, date, MAC ID of the devices sending/receiving the token(s) being transferred, the sender/recipient wallet addresses, and other information. Once collected, some or all of this information is reported to and stored by database management module 1535. In a preferred embodiment, complete records of all transactions are also stored within the blockchain itself (not pictured).
In a preferred embodiment, database management module 1535 also reports to the AXEL database 1570, ensuring all information related to wallet and token activity is properly accounted for and stored. Confirmations are shared between AXEL database 1570 and database management module 1535 via chain communications 1575, wallet communications 1505 and through wallet and token admin operating system 1530. Any notifications related to client/user 1555 of the wallet will be managed through notifications and messaging module 1525.
Encryption function 1520 manages all aspects of encryption and decryption of the wallet itself, along with the encryption of the private key generated by key and PIN management function 1540. Details of the private key creation are discussed later in this submission.
Notifications and messaging function 1525 is responsible for communicating notifications and/or messages to client/user 1555 as well as to the network (not pictured) through wallet communications admin 1505 and chain communications 1575. Examples of messages or notifications processed by notification and messaging function 1525 may include a confirmation that a transaction has completed; one or more tokens have been transferred or received; the wallet has earned new tokens through the staking process; and the like.
Key and PIN management function 1540 creates all public and private keys for wallet 1501 to utilize for transactions. Key and PIN management function 1540 may create one or more public/private keys so that client/user 1555 may have multiple wallet addresses in which to receive tokens/cryptocurrency. While these wallet addresses may be intended to be utilized by the wallet generating the public key, it is also contemplated that these keys may be assigned to other wallets for the purpose of backup, redundancy or other needs.
Key and PIN management function 1540 also creates a private key for wallet 1501 that is intended to be used solely by client/user 1555. In a preferred embodiment, this private key is generated at the time of account creation during first access with AXEL wallet 1501. As stated previously, in a preferred embodiment, no access to wallet 1501 is granted before client/user 1555 has logged into the system and completed all the requirements for access as designated by AXEL DCA security 1560 and the reference login access information detailed with reference to
Key and PIN management function 1540 creates a public and private key for each wallet generated by the AXEL system, as well as a unique safeguard or PIN code that is to be used in conjunction with a unique hash code to encrypt with the private key as an additional layer of security for the private key. It is contemplated that a safeguard or PIN code may be numeric, alphanumeric, binary or other data, or various combinations thereof.
The hash code used to generate a key pair (public and private keys) can be acquired from a number of sources within the system, including utilization of the hash created during a session login wherein client/user 1555 enters a username and password to access the system (as discussed previously with reference to
Key and PIN management function 1540 is also responsible for generating unique PIN codes to be used in conjunction with the hash to add an additional layer of security to the private key. The hash and the PIN are combined and encrypted together by the encryption process 1520 to make it far more difficult for someone to decrypt the hash and acquire the private key that resides in the encrypted hash. Once the hash and the PIN are generated, they are sent to encryption function 1520 to be encrypted as stated above.
Once the encryption is complete, the resulting encrypted hash is stored in AXEL database 1570 as directed by database management function 1535. It is important to note that while the private key is encrypted, AXEL database 1570 may also be encrypted. The encryption methodologies may be AES-256-type encryption, pin and token encryption, ad-hoc encryption or any other encryption method that may be incorporated into the AXEL network at the time of deployment or update.
It is important to note that AXEL database 1570 can be utilized interchangeably with AXEL distributed database 1550 (AXEL DDB) or other data store. AXEL distributed database 1550 may allow client/user 1555 to engage distributed database capabilities from the node that resides closest to the client/user 1555 network access point. This will ensure the lowest possible latency for client/user 1555 as well as enhancing network performance.
As stated previously, in a preferred embodiment, the public and private keys are generated by AXEL Wallet 1501 each time a new user account is created within the AXEL network, or when an existing user wishes to create additional wallets for the purpose of managing the native AXEL tokens. It is important to note that the above described wallet may be configured to house and manage different kinds of coins or tokens. Thus, in this example, while the wallet is designed to support the use of the native AXEL tokens, it may also be used to house and manage non-AXEL tokens, also commonly referred to as “alternative coins” or tokens.
The creation of the public and private keys will now be discussed with reference to
The creation of the public and private keys (the key pair) generally relies on the utilization of a username and password as well as a unique PIN code generated by the AXEL wallet. These elements are utilized to create a unique hash code used to encrypt and decrypt the key pair generated by the wallet. The utilization of a unique hash adds an additional layer of security for the wallet and the AXEL blockchain.
With reference to
Request 1635 is sent to wallet communications module 1610. Wallet and token admin operating system 1685 works in conjunction with wallet communications 1610 to send wallet creation request 1640 to transaction manager 1615. Transaction manager 1615 records transaction request 1635 as well as the MAC ID (not shown) for client/user 1605 device, assigns a transaction ID number to the transaction for tracking purposes, and assigns a session ID that will be used by the AXEL database/DDB to store the session (and all transactions within the session) for recall at a later time. Once transaction manager 1615 has completed recording the MAC ID, session ID and transaction ID, a hash is generated representing this information and is sent 1645 to AXEL database/DDB 1630.
AXEL database/DDB 1630 sends an acknowledgement 1650 through the wallet and token admin operating system 1685 to notify the system that the information sent has been recorded. Wallet communications 1610 sends a notification 1655 (as instructed by the wallet and token administration operating system 1685) to key and PIN management 1620 that a key set (one each public and private keys) is to be generated. Key and PIN management 1620 sends a request 1660 to the AXEL database/DDB 1630 for the current client/user 1605 username and password. The username and password is used (in conjunction with a unique PIN generated by the key and PIN management 1620) to generate a hash code that will be used in the creation of the public and private key. The AXEL database/DDB 1630 responds 1665 to the key and PIN management 1620 with the requested username and password information. It is contemplated that the AXEL database/DDB may return a hash containing the username and password (instead of returning the actual username and password) that is captured during the initial login session instead of having the key and PIN management generate the hash required.
Key and PIN management 1620 generates a unique PIN code and creates a hash utilizing the newly generated PIN code along with authentication information, such as a username and password, obtained from AXEL database/DDB 1630 that contains client/user 1605 key pair (public and private key). (Again, it is contemplated that key and PIN management 1620 can utilize a hash captured at initial login instead of creating a new hash utilizing the username and password.) Once the key pair is generated, key and PIN management 1620 sends the newly created hash 1660 (containing the client/user 1605 public and private keys) to the encryption 1625 function with instructions to encrypt the hash prior to storage. Master encryption function 1625 then encrypts the hash as received 1660 from key and PIN management 1620 and sends a notification 1665 to key and PIN management 1620 that the encryption process is complete. Encryption 1625 function then sends the encrypted hash 1670 containing the public and private key (the key pair) to AXEL database/DDB 1630 for storage. AXEL database/DDB 1630 then notifies 1675 the wallet communications 1610 that the key pair generation event is completed. Wallet communications 1610 then provides the public key (only) 1680 to the client/user 1605.
The private key generated during the key pair generation event will remain stored in AXEL database/ddb 1630 for retrieval when a wallet process, such as a token transfer, purchase, or other event requiring the private key, is requested. The private key will remain stored in its encrypted state on either or both of the AXEL database and/or the AXEL distributed database (DDB) as represented by AXEL database/DDB 1630. It is important to note that it is contemplated that the entire database/DDB can be encrypted, adding additional protection to the storage of the private key. Since the PIN being utilized to generate the hash (username +password +PIN=hash) is randomly generated, it is contemplated that this PIN may expire over a period of time and need to be refreshed. Should a PIN be approaching an expiration date/time, the client/user will be notified to log into the system to allow a new hash to be created (with the newly assigned PIN) to ensure the integrity of the encrypted hash storing the private key.
The process for transaction authorization from the wallet (wherein a private key is required to confirm and/or authorize a transaction) is very similar to the process for key assignment discussed above with reference to
The process for transaction approval utilizing a private key will now be discussed with continued reference to
AXEL database/DDB 1630 sends an acknowledgement 1650 through the wallet and token admin operating system 1685 to notify wallet communications 1610 that the process has been recorded. Wallet communications 1610 then sends a notification 1655 (as instructed by the wallet and token administration operating system 1685) to key and PIN management 1620 that access to client/user 1605 private key is required to authorize a transaction. The key and PIN management 1620 sends a request 1657 to the AXEL database/DDB for a copy of the hash that was used to create the private key and subsequently encrypted by the encryption 1625 function. AXEL database/DDB 1630 will review the session information created by transaction manager 1615 (as discussed previously with reference to
Encryption function 1625 will decrypt the hash containing the private key and send a notification 1665 to key and PIN management 1620 that the process was accomplished. Encryption function 1625 sends a copy of the decrypted private key 1670 to the AXEL database/DDB to enable the process to be completed. AXEL database/DDB 1630 allows the transaction process to be approved utilizing the decrypted private key and sends a notification 1675 to the wallet communications 1610 that the process has completed. The wallet communications 1610 will then notify 1680 the client/user 1605 that the transaction has completed.
Once the process has been completed, the private key will be encrypted again (utilizing the process discussed with reference to
The AXEL wallet manages tokens entering and leaving the wallet controls based on the disposition (entering or leaving) of the tokens. Tokens entering the AXEL wallet (before the blockchain has completely confirmed the transaction) are managed by a key (receiving) that is visible to the blockchain itself. Once the blockchain has confirmed the transfer of an incoming token, the control of the incoming token may be passed to an internal address that is entirely controlled by the AXEL wallet. Once passed to the internal address, those tokens are not visible to the public blockchain. If the user later issues a transfer token command, the control of an outgoing token is passed from the internal address to an external key that is visible to the blockchain. By enabling an internal and external control mechanism in the AXEL wallet, access to tokens by outside entities is limited to only those tokens being addressed during the transaction interval. Once the transaction has been completed, the public keys (sending and receiving) that had control of the tokens will no longer have tokens associated with them. This effectively removes the threat of nefarious activities outside of the wallet such as hacks, breaches or other activities that could result in the loss of the tokens.
Functionally, the AXEL wallet passes control of tokens that are entering the wallet from the blockchain to an internal addressing and management scheme that is not visible to the public blockchain. As a token is received by the AXEL wallet, the blockchain authenticates the transaction, for example, by authenticating it a specified number of times prescribed by that particular blockchain, before it is considered validated. Once blockchain validation occurs, the token ownership can pass within the AXEL wallet from the public key or hash that received the token to a non-public, internal address that is created, managed and controlled by the AXEL wallet. This transfer to the non-public, internal address can be configured to occur either automatically or at the direction of the wallet user. For example, the user could configure the wallet to transfer every token received to the internal address, or to allow only a small number of tokens to remain in the externally addressed portion. As another example, the user could manually direct the transfer of tokens from the internal addressed portion to the external addressed portion. In a similar fashion, as a token in the internal addressed portion of the wallet is designated to be sent from the AXEL wallet to one or more second user wallets, the ownership of the token is passed from the internal, non-public address that is created and managed within the wallet to a public sending hash or key that is visible to the blockchain. By creating this transfer of ownership within the AXEL wallet, the tokens being managed are far safer and less subject to external nefarious threats. The functional elements of the wallet that relate to the generation and separation of the internal and external addressing schemes are now be discussed with reference to
With reference to
The key and PIN management 1740 performs two distinct functions within the AXEL wallet 1701. It generates public (blockchain visible) keys to be utilized for managing tokens coming into and going out of the wallet, and creates internal addresses used to manage and control tokens that reside within the wallet 1701 and remain under the wallets 1701 control. Details of this function are described later in this submission.
The notifications and messaging 1725 also provides two distinct functions within the AXEL wallet 1701. It provides notifications and/or messages that are designated for the wallet owner as well as creating internal messages such as error reporting and other system type messages that are used by the AXEL wallet 1701 to diagnose and troubleshoot errors within the wallet 1701 or within the system that appear at or to the wallet 1701.
The transaction management 1710 function is responsible for the management of both external and internal transactions. External transactions relate to tokens moving into and out of the wallet 1701 through the blockchain 1745. Internal transactions relate to token management being passed, for example, between the external public keys to the internal private addresses. Here again, these addresses within the wallet (being generated by the key and PIN management 1740) are not visible to the public blockchain 1745.
The encryption 1720 allows both internal and external transactions to be protected by encryption, as well as allowing for the wallet itself to be both encrypted and password protected. The encryption 1720 also controls the process of decrypting the wallet and any transaction information previously encrypted.
The database management 1735 function is responsible for storing all of the public and private keys as well as all of the internal addresses generated by the key and PIN management 1740 and utilized by the wallet 1701 to manage the tokens that are entering and leaving the wallet 1701. The database management 1735 function works in conjunction with the wallet and token administration operating system 1760 to keep track of a data generated by the wallet, including but not limited to token transactions, user identification information, encryption information, transaction metadata, internal or external messaging and the like. The database management 1735 function can also serve as a control to prevent transactions that do not comply with restrictions on a sending or receiving address.
As previously stated, the wallet provides the capability of passing ownership from an external set of keys used for the sending and receiving of tokens from the blockchain 1745 to a set of internal addresses that are not visible or accessible by the blockchain 1745. The purpose of this ownership transaction is to prevent unauthorized access to the tokens through any of the publicly visible keys that have been used in the sending and/or receiving of the subject tokens.
With continued reference to
As the blockchain 1745 provides final verification of the incoming token transaction by writing the info to a new block and updating the blockchain, the wallet communications admin 1705 notifies the wallet and token administration operating system 1760 that the transaction has been completed.
The wallet and token administration operating system 1760 notifies the key and PIN management 1740 once the token transaction has been authorized by the blockchain. The transaction management 1710 creates a transaction ID for the completed transaction and shares that information with the database management 1735. The database management 1735 records the transaction ID generated by the transaction management 1710 and notifies the wallet and token administration operating system 1760 of the completed transaction.
For the purposes of this example, to illustrate more steps that may occur, it is assumed that a new internal address will be created, either because one has not yet been created or because the user has configured the wallet to create a new one for the purposes of this transaction. In this situation, after the wallet and token administration operating system 1760 is notified of the completed transaction, the wallet and token administration operating system 1760 instructs 1755 the key and PIN management 1740 to create a new internal address for the purpose of managing the newly received token within the wallet. The key and PIN Management 1740 generates a new internal address 1765 and returns that address to the wallet and token administration operating system 1760. The wallet and token administration operating system 1760 shares the newly created internal address 1765 with the transaction management 1710, the notifications and messaging 1725 and the database management 1735, and authorizes the transfer of token control from the incoming public key 1750 to the newly created internal address 1765 that is not accessible or visible to the blockchain.
The transaction management 1710 creates the transaction authorized by the wallet and token administration operating system 1760. Once the transaction occurs within the wallet, the transaction management 1710 shares the newly created transaction ID with the notifications and messaging 725, the wallet and token administration operating system, the database management 1735 and the encryption 1720.
The database management 1735 records the transaction ID created by the transaction management 1710 and the process is completed. The newly received token is now under the direct control of the wallet 1701 utilizing an internal address that is not publicly accessible or visible to the blockchain 1745. As discussed above, in a preferred embodiment, the existence of the internal address, in addition to the information needed to access the newly received token, is preferably not disclosed to anyone in order to maximize security.
Based on the current configuration, the AXEL wallet 1701 may at this time delete the public key 1750 that initially managed the token as it was being received into the AXEL wallet 1701 and request a new public key to be generated by the key and PIN management 1740. This process enables an additional layer of protection against a potential wallet 1701 breach as the address 1750 that originally controlled the incoming wallet 1701 transaction is no longer available or accessible within the blockchain 1745. That is, any transaction attempted with a public key that has been deleted will not be completed. In a similar fashion, private addresses 1765 that are created to internally manage tokens being received can be changed each time a transaction has been completed to further enhance wallet 1701 security.
In a similar fashion as described above, the public keys of the AXEL wallet may be restricted in their usage by the wallet owner. As an example (and with continued reference to
As a specific example to demonstrate this functionality, an example where a wallet owner has designated a public sending or receiving address for single usage is now discussed. With reference to
In a preferred embodiment, the notification and messaging 1725 module confirms the configuration with the wallet owner (through the user interface), ensuring the wallet owner wishes to confirm the single-usage public address and the associated parameters of the transaction that were provided by the wallet owner. Upon confirmation from the wallet owner, the notification and messaging 1725 module confirms the parameters of the pending single-use transaction with the wallet and token admin OS 1760, which in-turn notifies the key and pin management 1740, the transaction management 1710 and the database management 1735 that the single use transaction (public address) is confirmed. The transaction parameters provided by the wallet owner are then carried out by the AXEL wallet.
It is important to note that in the example of an address configured for a single use, or configured with any other restriction, the wallet address is only be available for use as designated through the parameters set by the wallet owner. Should tokens be sent (as an example) to the address that do not comply with those parameters, they will not be accepted by the AXEL wallet. For example, if tokens are sent after a permitted single use transaction has been completed, the transaction cannot be completed as the subject address will no longer be available to the blockchain. In a similar fashion, should the wallet owner (or anyone else that accesses the wallet) try to execute a transaction against the subject single-use public address after the original transaction parameters have been completed, it will also fail. The wallet and token admin OS will send the wallet owner request to the associated wallet modules utilized in the initial configuration as described above, however the database management module 1735 will reject the usage of the wallet address as it has been closed. The notification and messaging module 1725 will report to the wallet owner (through the user interface) that the subject wallet address is no longer active and/or available to the system. In similar fashion, the database management module can reject any transaction that does not comply with the restrictions set by the wallet owner.
Multiple configurations may be provisioned to allow the AXEL wallet 1701 to generate public keys and private internal addresses based on metrics such as time passed, number of transactions processed, number of tokens processed and the like. These key and address generations may be controlled by the AXEL wallet 1701 or by the user (not pictured) depending on the needs of the user.
The token control process described above also takes place when the AXEL wallet 1701 is initiating a send transaction wherein a token that is under the control of the AXEL wallet 1701 will be transferred to another public wallet address. Though not detailed herein, it is also contemplated that a received token may be transferred from one internal address to another.
With continued reference to
The database management 1735 records the transaction ID and provides an acknowledgement to the wallet and token administration operating system 1725. The key and PIN management 1740 then passes control of the token being sent from an internal address 1765 that is not accessible to the blockchain to an external key 1755 that is accessible to the blockchain. Once the control of the token has been passed to the external key 1755, the token send transaction can take place. Each transaction (both internal and external) is recorded to the database management 1735 to ensure accurate recording of all transactions. Internal transactions are recorded at the time the wallet 1701 authorizes them. External transactions (visible to the blockchain 1745) are recorded when the blockchain authenticates the subject transaction(s).
The separation of control created by the internal addressing and external key management mechanism provides enhanced protection for all transactions being managed by the AXEL wallet 1701. This control separation negates the need for multiple layers of external wallet keys that are being governed by multiple layers of password protection and other schemes designed to protect the tokens managed through the blockchain wallet.
Each time a process requiring the private key is requested; the hash containing the private key will be decrypted to authorize the transaction and then re-encrypted utilizing a new PIN code that is randomly generated by key and PIN management 1740. This process will ensure the privacy and security of the user private key, and prevent it from being accessed from breach attempts such as phishing and/or hacking of the system.
Another embodiment of the AXEL wallet includes the application specific internal wallet component. The application specific wallet function enables tokens and/or cryptocurrency to be secured and designated for use-specific applications as defined by, for example, the network host or provisioner(s). While network hosts and provisioners are used as examples herein, the specific internal wallet component could be used by others as well. Any developer of a DAPP could configure an application specific internal wallet component such that certain tokens have restrictions. Any person with the power to configure wallets or tokens could make use of the features discussed herein.
The purpose of the application specific wallet is to enable a network host or provisioner to designate tokens and/or cryptocurrency to be utilized for a specific application or use. It is important to note that while the examples and disclosures herein focus on the AXEL blockchain and a single native token (AXEL token), the application specific wallet may be deployed in networks and blockchain environments wherein multiple tokens may be native to or operating on a network, such as the Ethereum network. In such instances, the application specific wallet function may be configured to hold multiple different tokens or cryptocurrencies designated for multiple specific applications.
One benefit of the application specific wallet function is to enable networks such as the AXEL network that are powered by utility tokens to designate the usage of those tokens for network specific applications. By designating certain tokens to the application specific wallet, these tokens are restricted and can only be used for functions designated by the network host or provisioner(s). For example, these tokens may not be allowed to be transferred to exchanges or other non-network usages, and may be permitted to be used only on one or more applications that are native to, or supported by the network such as a file storage and sharing application, or other application as chosen by the network host or provisioner(s).
The application specific internal wallet function will now be discussed with reference to
Functionally, the application specific wallet 1870 is controlled solely by the network provisioner or network host that has created and deployed, or otherwise is performing the administration function of the subject blockchain network. In the alternative, the application specific wallet 1870 may be controlled by the developer or administrator of a DAPP that is functioning on the network. In a preferred embodiment, to prevent nefarious or unwanted activities by the network host or provisioner(s), the application specific internal wallet 1870 does not allow the removal of tokens or cryptocurrency by anyone but the registered user of the AXEL wallet 1801. Tokens and/or cryptocurrency designated to be controlled by the application specific internal wallet 1870 may be spent and/or used by the AXEL wallet 1801 owner (not pictured) solely for the specific applications which are designated by the network host and/or provisioner(s).
In an exemplary embodiment, tokens may be preloaded into the application specific wallet 1870 by the network provisioner or administrator at the time of wallet deployment. The tokens (not pictured) will enter the AXEL wallet 1801 through the blockchain 1845. The wallet communications admin 1805 will accept provisioning commands from the network administrator or host and transfer those instructions to the wallet and token admin OS 1860. Since the tokens are being designated for use solely in the application specific wallet 1870, the wallet and token admin OS instructs that the tokens be sent to the application specific wallet 1870. The database management 1835 module is given instructions from the network administrator or host through the blockchain 1845, the wallet communications admin 1805 and the wallet and token admin OS, that tokens hosted within the application specific wallet are to be designated for a specific application or purpose and may not be used outside of these established and programmed parameters.
In instances wherein the application specific internal wallet module 1870 is preloaded as disclosed above, and the subject AXEL wallet 1801 has yet to be claimed and/or assigned to a registered user of the network, the network host and/or provisioner may remove tokens and/or cryptocurrency, or otherwise change the quantity of tokens managed through the application specific internal wallet module 1870. However, in a preferred embodiment, once a user has claimed the AXEL wallet 1801 and/or otherwise registered to the (AXEL) network with the associated AXEL wallet 1801, the network host and/or provisioner may no longer remove tokens and/or cryptocurrency from the application specific wallet module 1870, or exercise any remote control thereof, with the exception that additional tokens and/or cryptocurrency may be added or otherwise assigned to the control of the application specific internal wallet module 1870. As stated previously, this security feature is intended to prevent nefarious activities from persons who control and/or manage the subject network.
As an example of the above, a network provisioner or host (not pictured) may choose to add tokens to the application specific internal wallet 1870 for the purposes of enabling free trial access to a DAPP (Decentralized Application) that is operating on the AXEL or other subject network. Subsequent to the addition of these tokens, the AXEL wallet 1801 is then claimed by a user (not pictured). The user will have access to the tokens controlled by the application specific internal wallet module 1870 solely for the application(s) for which the network provisioner and/or owner has determined. Now that the user has control of the subject AXEL wallet 1801, the network provisioner and/or owner may no longer remove tokens from any part of the AXEL wallet 1801. This includes but is not limited to tokens that are under the control of other wallet modules disclosed in this submission.
In a typical usage scenario, the AXEL wallet 1801 has been claimed by a user (not pictured) and is currently deployed to the AXEL network. The network provisioner has provided a quantity of tokens to be managed by the application specific internal wallet 1870 module for the purpose of use in a file sharing application (not pictured). The user (not pictured) will engage the application through the blockchain 1845 network. The wallet communications admin 1805 will manage the AXEL wallet 1801 session of engagement with the subject file sharing application (not pictured). As the user (not pictured) chooses to share a file using the subject file sharing application, the tokens (not pictured) controlled by the application specific internal wallet 1870 module may be utilized by the wallet owner to enact the functional elements of the file sharing application.
The application specific wallet provides a locking capability that allows the wallet to be configured for locking, unlocking and relocking, either manually or automatically, based on criteria set by a network provisioner or administrator. The application specific wallet may be configured to prevent tokens from entering and/or leaving the wallet for any duration, time or interval as required by the network provisioner or administrator. As an example, a network provisioner or administrator may wish to set the application specific wallet to unlock (allowing tokens to move into and out of the wallet) on a specific date and/or time. The network provisioner or administrator may also choose to have the application specific wallet unlock at a first time and/or date selected, and then have the wallet relock at a second date and/or time selected. The network provisioner or administrator may set subsequent times for unlocking and relocking as desired.
In a similar fashion as above, the application specific wallet may be configured to perform the above functions at specified intervals, times and dates over a period. As an example, the application specific wallet may be configured to enable receipt of tokens on Fridays, but disallow tokens to be placed in the wallet on the remaining days of the week. The purpose of this function is to allow provisioning of the application specific wallet to coincide with the business or personal needs of the network provisioner or administrator. A business (as an example) may wish to have all deposits made to their account (through the application specific wallet) on Fridays. The flexibility of provisioning specified days, dates and/or times enables the application specific wallet to function in virtually any configuration as required by the needs of the provisioner or administrator.
The application specific wallet also provides the capability of sending and/or receiving tokens by quantity as well as by time and/or date. As an example, the application specific internal wallet may be configured to receive a specific quantity of tokens at predefined periods over an extended period. Conversely, the application specific wallet may also be configured to dispense a number of tokens at predefined periods over an extended period. As an example of the above, the application specific wallet may be set up to receive a timed payment from a party. The party sending the payment to the application specific wallet may be sending this payment on the first of each month. The application specific wallet can be configured to accept that payment (as it is being anticipated) but to block other tokens (payments) from entering the wallet. In a similar fashion, the application specific wallet may be configured to send a payment to a party on the first of every month. The wallet would send the referenced payment, but disallow any further payments to be made at that time or at other times. The flexibility of provisioning the sending and receiving of tokens and cryptocurrency allows the application specific wallet to be utilized by business and enterprise for the purpose of conduction automatic transactions over extended periods.
While the above examples involve times and dates, the system allows for the locking and unlocking mechanisms to work in conjunction with any parameter that might be desired by a provisioner or administrator. As some examples, the number of blockchain blocks could be used, or the number or frequency of token transactions or of transactions in a DAPP. For example, if the DAPP is a file sharing and storage application, the number or frequency of files shared or files stored could be used as parameters.
The functional elements of the application specific internal wallet locking and unlocking mechanisms will now be discussed with reference to
As can be seen in
The master wallet lock 1807 enables a provisioner to completely disable all timers associated with the application specific wallet and associated settings of such. Setting the master wallet lock 1807 to off will unlock the application specific wallet, allowing the associated timers and settings to be configured. Setting the master wallet lock 1807 to “on” will lock the application specific internal wallet and disallow any timers or other external provisioning to occur.
The wallet lock timer 1802 provides a timer on/off 1806 function that serves to enable or disable all functions associated with the wallet lock timer 1802. The lock timer 1806 must be in the “on” position for the associated timers to take effect. Setting the lock timer 1806 to the “off” position will disable the associated timers controlling the locking and unlocking time and date settings. The timer settings themselves provide for locking the wallet on a specific date and time, unlocking the wallet on a specific date and time, and then subsequently relocking the wallet on a specific date and time. As discussed above, dates and times are used as an example, and other settings can be utilized such that the wallet can be locked or unlocked based on other parameters.
The wallet lock timer 1806 provides for setting dates for locking 1811 the wallet, unlocking 1826 the wallet, and then relocking 1841 the wallet at intervals provisioned by the administrator or provisioner. Each timer configuration allows the date to be manually set 1816, 1836 and 1846, or to be configured using a pulldown menu 1811, 1826 and 1841 respectively. The time can also be set for the respective dates using the time 1821, 1831 and 851 settings associated with the referenced timers. The time can be configured in hours, minutes and seconds for each timer (1821, 1831 and 1851 respectively).
The wallet lock timer 1802 also provides a reset capability 1856 that allows the provisioner or administrator to clear the settings made in each timer setting (1811, 1816, 1821, 1826, 1831, 1836, 1841, 1846 and 1851). Actuating the reset 1856 will reset all associated timers to default and turn the reference indicators gray as a visual reminder that the referenced times and dates need to be configured to continue. The cancel 1866 setting will undo any changes made to any configuration indicated on the wallet lock timer 1802 except for the master lock 1807 and the lock timer 1806 settings. These settings are independent of the reset 1856 and cancel 1861 functions. Once all settings have been configured, they can be saved using the save 1866 function. As stated previously, configuring the restrictions based on timing is only one of many different configurations that may be utilized. Other functions exist within the application specific internal wallet to enable granular control of the tokens moving into and out of the wallet. This includes a menu (not pictured) that allows a provisioner or administrator to set a precise number/quantity of tokens to send and/or receive at precise date and time intervals. These settings allow the application specific wallet to function independently while also processing transactions as needed by the provisioner or administrator.
As discussed above, a timer is only one example of adjusting conditions that may be placed on tokens. The locking mechanism can be configured to allow manual adjustment of restrictions and also for automatic adjustment depending on any parameter desired by the provisioner. For example, restrictions could be configured to ease when the network or tokens achieve a certain usage, when the network achieves a certain number of nodes, after a certain number of token transactions occur, or any other parameter. From a regulatory perspective, it may be desirable to have restrictions ease for some tokens, wallets, or for token holders, once the network achieves certain usage milestones. It may be desirable to only ease restrictions for tokens, wallets, or token holders, for example, those that are known to be from or in certain countries. Or, it may be desirable to ease restrictions for tokens, wallets, or token holders where the same token holder possesses only a small number of tokens. In another example, it may be desirable to ease restrictions such that a limited number of tokens could be moved out of the wallet in a given time interval. A gradual ease of restrictions may also be beneficial to prevent the market from being flooded with tokens for sale. Moreover, the provisioner might retain the ability to manually adjust the restrictions, which may be desirable based on the changing nature of regulations. For example, if a new regulation is enacted, restrictions could be adjusted to conform with the changes. Perhaps at some time later, that regulatory change may be reversed, in which case, it may be beneficial to readjust restrictions.
In order to control the tokens and/or cryptocurrency assigned to the application specific internal wallet, the user must have visibility to the balance of tokens/cryptocurrency available, and must have a way to manage their use. A typical implementation of user control of these tokens/cryptocurrency will now be discussed with reference to
With reference to
The main balance 1905 is designated as the wallet balance. These tokens 1920 are not subject to restrictions, are managed solely by the wallet owner (not pictured) and may be spent or otherwise transferred into and out of the wallet at the sole discretion of the wallet owner. The fuel balance 1910 represents the application specific internal wallet managing tokens that are designated solely for the application for which the network host and/or provisioner(s) intended. The naming convention of the application specific internal wallet 1910 is designated as desired by the network host and/or provisioner to be used exclusively for the application or purpose for which the tokens and/or cryptocurrency is provided. In the current example (with reference to
In a preferred embodiment the network host and/or provisioner may choose at any time to add more tokens/cryptocurrency to the fuel balance 1910 (application specific internal wallet) to enable the user (not pictured) to continue to utilize the application for which the tokens are designated. The wallet owner (not pictured) may also choose to move tokens 1920 that exist in the users main balance 1905 (primary wallet designation) to facilitate further use of the subject application being powered by the fuel balance 1910 (application specific internal wallet). Should a user (not pictured) choose to transfer tokens 1920 from their main balance 1905 (primary wallet) to the application specific internal wallet 1910 (fuel balance) this transfer cannot be undone or reversed. Tokens 1925 that reside in the application specific internal wallet 1910 (fuel balance) can only be used in conjunction with the function for which they are intended. In this example shown in
As another example, the user interface 1901 may display the fuel balance 1910 (application specific internal wallet function) as “File Sharing” (not pictured). This designation may be applied to the application specific internal wallet 1901 by the network provisioner and/or host. This designation may enable a user (not pictured) to spend the tokens 1925 that reside in the application specific internal wallet 1910 on File Sharing functions as provided by the application specified by the network owner and/or provisioner(s). While the specific usage designation for the application specific wallet 1910 is not meant to be changed after the wallet is deployed, it is possible that the network host and/or provisioner may change this designation in cases wherein a previously specified application or use of the subject tokens 1925 changes or otherwise becomes unavailable or modified from the original intent.
As an example, (with continued reference to
The AXEL blockchain provides a digital signature capability that enables users to digitally sign or otherwise authorize or provide compliance/agreement to any article where such an authorization may be beneficial, including, for example legally binding agreements such as a contract, letter of intent or other article that requires a verified and authenticated signature in order to take effect. While the digital signature disclosed herein may be applied to any article of the signatories choosing, this disclosure focuses on articles requiring an authenticated and verified signature. It is understood that the amount of level of authentication or verification can be increased or decreased as desired to suit a particular situation. In a preferred embodiment, the participants in a transaction can select the level of authentication or verification desired for that particular transaction.
The digital signature system and method of the AXEL blockchain provides a mechanism in which one or more parties can agree and provide signatory verification of agreement. This mechanism can be treated similarly to a legally binding signature and can be used in business dealings such as purchasing a car, home or other agreement requiring an authenticated and verifiable signature from an agreement participant. While there are virtually limitless types of agreements, this disclosure focuses on the digital signature capability enabling these pieces to be authorized, and not the contents of the agreement(s) themselves.
The digital signature system and method is developed to support a variety of networking configurations, including the use of “smart contract” technology. As is known in the art, smart contracts are commonly used to enable a variety of transactions to be managed between one or more users within a given network.
The digital signature capability utilizes multiple elements previously discussed in this submission, including the user self-sovereign ID function (discussed with reference to
It is important to note that while the digital signature system and method disclosed herein is presented as part of the AXEL network, it can be applied to any existing or future network wherein positive verification or authentication of a signature in a digital environment is desired. Implementation of digital signature capabilities is not restricted to a decentralized, blockchain network and may be deployed in any networking situation.
As previously disclosed in this submission (with reference to
The discussion that follows details the primary elements of a digital signature. It is important to note that one skilled in the art will see a variety of other methods and systems of implementation as well as additional functional elements that could be incorporated into this system and method. This discussion and the associated diagrams provided herein are limited in scope to focus on the primary elements of this disclosure. The discussion that follows assumes a user wishing to create a digital signature has already created an account with the AXEL network.
Please also note that the following discussion makes reference to the AXEL identity vault that was previously disclosed in this submission. The AXEL identity vault is a private and secure gateway that enables a user device such as an external storage repository (hard drive, USB drive, flash drive, hardware wallet or other external storage device) to be granted access to the AXEL digital signature capability and the AXEL wallet. While a digital signature is effectively stored in the external storage repository, the usage of the digital signature itself is entirely governed by the AXEL identity vault. It is contemplated that the external storage device as referenced above may additionally require a separate authentication for use that resides outside the control of the AXEL blockchain. However, the usage of the external storage device in relation to the digital signature is governed by the AXEL blockchain and associated functional elements as described herein.
The digital signature system and method is now be discussed with reference to
The AXEL digital signature functional modules 2040 are separated from the AXEL wallet functional modules 2022 by a second application of the AXEL DCA security 2047. This is due to the fact that each primary functional element associated with a user 2005 (wallet 2022 and the digital signature 2040 as examples) is protected by an independent and separate layer of security. A user 2005 wishing to access wallet 2022 will pass through a layer of security (AXEL DCA security 2007) while digital signature 2040 requires an additional (AXEL DCA security 2047) security authentication prior to access.
In a typical application and implementation of the AXEL digital signature 2040, a user device 2005 is initially introduced to the network through primary blockchain chain communications 2017. As user 2005 requests access to their AXEL wallet 2022, AXEL DCA security 2007 prompts the user to enter their current identification information. This can include, for example, typical authentication information such as a username and password, or any other method of authentication that would be unique to a user, such as a code, fingerprint, facial recognition, retinal scan, or any other method. In some embodiments of the AXEL system, user ID info 2012 responds to the request of user 2005 for access to wallet 2022 prior to allowing the user to continue through the various levels of access to the system. In some embodiments, AXEL DCA security 2007 may not be enabled and/or deployed, depending on the needs of the network administrator. In another embodiment of the AXEL system, user ID info 2012 responds directly to the request of user 2005 for access to wallet 2022, and then passes the continued authentication and access requirements to AXEL DCA security 2007. This embodiment is typically used in instances wherein multiple tiers/layers of security are required. It is important to note that access to digital signature 2040 capabilities provided within the system preferably utilizes multiple tiers/layers of security, and therefore may be designed to require multiple authentications of the user 2005 wishing to access the system. It is also important to note that any single level of access such as to the system, a wallet, or a digital signature may itself require multi-factor authentication. Other capabilities may be used as part of, or in place of, the authentication process. For example, if a digital signature is to utilize video meeting capabilities as described above, those capabilities could serve as an additional layer of authentication, or else could be used in place of one or more levels of authentication that would be used when video meetings are not utilized.
Once user 2005 has provided the required access info (for example, a username and password) to AXEL DCA security 2007, AXEL DCA security queries AXEL database 2015 and AXEL decentralized database 2020 to verify whether the information provided by user 2005 is correct. Once verified, AXEL database 2015 and AXEL decentralized database 2020 acknowledge authentication of the required access info to AXEL DCA security 2007.
The AXEL DCA security 2007 then requests that user 2005 perform a second authentication utilizing their PIN (Personal Identification Number) or other unique (known only to the user) code or identification available only to the user (e.g., a fingerprint, facial recognition, retinal scan, or any other characteristic that may be unique to an individual). For the purpose of this example, a PIN code shall be used. Once user 2005 provides the requested PIN code, AXEL DCA security 2007 notifies AXEL database 2015 and AXEL decentralized database 2020 of the receipt of user 2005's unique identification or PIN code. AXEL databases 2015 and 2020 then authenticate that unique identification or PIN code and report an authentication acknowledgement to the AXEL DCA security 2007.
AXEL DCA security 2007 then (through chain communications 2017) notifies wallet and token admin 2030 that a requested access from user 2005 has been granted. Wallet and token management 2030 then queries AXEL database 2015, AXEL decentralized database 2020 and wallet database management 2027 to ensure that all of the information verified by the AXEL DCA security 2007 matches with each queried database (2015, 2022 and 2027). Any discrepancies between the information being shared between the subject databases (via the query) results in the access request to wallet 2022 being denied by wallet and token management 2030.
Assuming each of the subject databases (2015, 2020 and 2037) agree with the authentication as provided by AXEL DCA security 2007, wallet and token management 2030 grants user 2005 access to AXEL wallet 2022 and the subsequent features and functions of the wallet. User 2005 now has access to their AXEL wallet 2022.
With continued reference to
AXEL DCA security 2047 may request one or more pieces of authentication information, including but not limited to the user's (2005) name, password, PIN or authorization code, passphrase or other such personal identifying information that is intended to only be known by, or available to, the authorized user. The configuration and request sequence requested by AXEL DCA security 2047 is dependent upon the needs of the network administrator upon configuration, or as discussed above, may be dependent on options that the participants in a transaction select. As some networks or transactions require lower security, the request sequence from AXEL DCA security 2047 may be bypassed entirely, while other network deployments or transactions require the highest level of security, wherein AXEL DCA security 2047 can request more information and authentication sequences from user 2005.
As user 2005 enters the authentication information requested by AXEL DCA security 2047, the information entered (by user 2005) again passes through AXEL DCA security 2007 and/or user ID info 2012. On this pass, the subject modules (2007 and 2012) passively witness the information but take no action unless the information entered does not match the previously entered information. As an example, if user 2005 enters all of their information perfectly the first time through and was able to get access to wallet 2022, but then entered their information incorrectly the second time as requested by AXEL DCA security 2047, access to wallet 2022 would be terminated immediately. While this is an inconvenience to the user who may have created a typographical error, this extra precautionary step is taken by the system to ensure the integrity of the wallet contents to prevent theft, hacking, bots or other such nefarious engagement. User 2005 is then provided an opportunity to re-enter the requested information once wallet 2022 has been locked by AXEL DCA security 2007. However, the re-entering of the information would this time be requested by the AXEL DCA security 2007, as access to AXEL DCA security 2047 has been terminated by wallet 2022 and AXEL DCA security 2007. At this point, user 2005 is starting their access request as if they are requesting initial access to the system.
For the purpose of this example, we assume the identification information request by AXEL DCA security 2047 is sent to user 2005, and user 2005 enters the requested information properly and without error. AXEL DCA security 2047 asks wallet and token management 2030 to query database management 2027, AXEL database 2015 and AXEL decentralized database 2020 to ensure that all three of the subject databases agree with the information entered by user 2005. Assuming that the information entered by user 2005 is correct and entered properly, AXEL DCA security 2047 then queries AXEL digital signature 2040 functional modules through self-sovereign ID operating system 2045 to determine if the information entered and validated by the previous databases (2015, 2020 and 2027) matches the information contained in the database management 2050 portion of AXEL digital signature functional modules 2040. Assuming all of the information matches all of the subject databases, AXEL DCA security 2047 grants user 2005 access to AXEL digital signature 2040 functional modules.
It is important to note that in this embodiment, while the databases (AXEL Database 2015, AXEL decentralized database 2020, wallet database management 2027 and digital signature database management 2050) need to agree on the subject identity information provided by user 2005, the information requested by each AXEL DCA security module (2007 and 2047) may be entirely different. As an example, a first set of identity information such as a username, password, PIN code and passphrase may be requested by the first AXEL DCA security 2007, but an entirely different set of identity information may be requested by the second AXEL DCA security 2047. Again, this variation in information requests adds additional layers of security and protection for the system and subsystems that reside herein.
With continued reference to
In a preferred embodiment, identity vault 2054 controls a user owned storage device 2055 such as a USB storage, hardware wallet, external hard drive or other storage type device that can communicate through a computing device. It is contemplated that the user owned storage may also be storage that resides on a user device such as a smart phone, tablet, personal computer or other storage enabled client device.
It is important to note that in a preferred embodiment, if the user owned storage 2055 is not connected to the system, a digital signature creation or usage is not possible as the user owned storage 2055 is the repository for the digital signature, and the access for the user owned storage 2055 is governed by the identity vault 2054, which is required to authenticate user 2005's identity. In this embodiment, the user owned storage 2055 must be present and working in association with the aforementioned digital signature functional modules 2040 to create and/or apply a digital signature
The creation of a digital signature begins with user 2005 providing the required identification information for the system to use in generating and authenticating the user. The information required would typically be determined by the network administrator, and may include an AML/KYC audit which often itself includes a valid driver's license, a passport, birth certificate, proof of residence and other items that can verify one's identity. The AML/KYC elements of the AXEL system are discussed previously in this submission.
Once the ID information has been provided by user 2005, it is stored and managed by self-sovereign ID operating system 2045. The self-sovereign ID is discussed in detail with reference to
With continued reference to
Wallet and token management 2030 queries database management 2027, AXEL database 2015 and AXEL decentralized database 2020 to ensure the information entered and authenticated by AXEL DCA security 2007 is all correct prior to allowing user 2005 access to the wallet functional modules. Once the authentication has been granted, user 2005 will then request access to the digital signature 2040 functional modules. Wallet and token management 2030 forwards this request to the AXEL DCA security 2047 which then requests additional authentication information as stated previously. This additional information may or may not include information previously requested by AXEL DCA security 2007 and may or may not have already been provided by user 2005. As stated previously, this additional step adds a layer of protection to guard the functional elements of AXEL digital signature 2040.
Again, as user 2005 enters the authentication information requested by AXEL DCA security 2047, the information entered (by user 2005) passes through AXEL DCA security 2007 and/or the user ID info 2012. On this pass, the subject modules (2007 and 2012) will passively witness the information but take no action unless the information entered does not match the previously entered information. Assuming the information requested by AXEL DCA security 2047 is entered correctly and without error, AXEL DCA security 2047 asks wallet and token management 2030 to query database management 2027, AXEL database 2015 and AXEL decentralized database 2020 to ensure that all three of the subject databases agree with the information entered by user 2005. Assuming that the information entered by user 2005 is correct and entered properly, the AXEL DCA security 2047 then queries AXEL digital signature 2040 functional modules through the self-sovereign ID operating system 2045 to determine if the information entered and validated by the previous databases (2015, 2020 and 2027) matches the information contained in the database management 2050 portion of AXEL digital signature functional modules 2040. Assuming all of the information matches all of the subject databases, AXEL DCA security 2047 grants user 2005 access to the AXEL digital signature 2040 functional modules.
User 2005 may now apply a digital signature to any agreement or other document they choose. Once the digital signature has been applied, database management 2050 records the signature transaction and captures the details of the agreement or document that is being signed, including, for example, a logical address where the document signed can be found, a date and timestamp of the signature itself, any party information associated with the agreement or document and a summary of the agreement or document that was digitally signed.
As an example, if user 2005 digitally signs an agreement to purchase a product from an online store, database management 2050 could capture all of the information typically found on a receipt for goods purchased. This would include the date and time of the purchase, the amount of the purchase, the item(s) purchased, the vendor details from which the item(s) was/were purchased and other associated information to detail the transaction in its entirety. In a similar fashion, if the document signed was a contract or a smart contract, the database would also capture the appropriate details to ensure accuracy of record and of the blockchain ledger.
The database management 2050 stores the information as stated above, and notifies self-sovereign ID operating system 2045 and digital signature operating system 2042 that the storage of the information of the purchase has been completed. The AXEL system generates a hash code (as is common with each transaction occurring on the blockchain) and the hash code is also stored in database management 2050.
The hash code generated by the system and stored in database management 2050 is shared to wallet and token management 2030 for storage in wallet database management 2027. In a preferred embodiment, the transaction information will not be captured or stored in the public branch of the database (AXEL database 2015 and/or AXEL decentralized database 2020) as the transaction contains a digital signature and is therefore kept on the user's private chain (not pictured) where wallet 2022 and the AXEL digital signature 2040 functional modules reside. The public blockchain (not pictured) would contain a record of the transaction itself, but as detailed previously within this submission, the details of the transaction would be hidden from view of the public blockchain.
As with all transactions that occur on the AXEL network, witness 2010 also has a record of the blockchain hash to prove that they were a witness to the subject transaction. This ensures the trust within the network as all transactions are required to be witnessed. However, since the subject transaction contains a digital signature, the witness admin 2010 would not collect or otherwise have visibility to the digital signature itself. The witness will only know that the transaction/document was digitally signed by the signatory.
AXEL digital signature 2040 provides the capability of encryption 2053 of all content associated with digital signature 2040. In one or more embodiments, all transactions records, including those with or without digital signatures attached are encrypted. The encryption is vital to ensuring the security of record as well as the privacy and security of the information entering and exiting identity vault 2054, and ultimately the user owned storage 2055. Database management 2050, through the self-sovereign ID operating system 2045, may share transaction information with the wallet 2030. Any information shared from the AXEL digital signature 2040 functional modules with wallet 2022 is encrypted by encryption function 2053, and requires authentication through AXEL DCA security 2007 and 2047, along with the AXEL wallet 2022 private key utilized for a signature and/or a transaction to access.
As an example of the above disclosure, if a user 2005 wishes to access transaction history information from AXEL digital signature 2040 or from AXEL wallet 2022, they must first validate and verify their identity through AXEL DCA security 2007 and 2047. Once these verifications have been passed, user 2005 provides the proper private key utilized during the transaction for which a record is being sought in order to access and decrypt that record. Any invalid entries made during this process (as with other processes utilized to access wallet 2022 or digital signature 2040) result in user 2005 being denied access to any and all functional elements of the AXEL network, and require user 2005 to begin the access process from the very beginning. This includes initial login and password authorization. As with many existing systems know in the art, cumulative failed attempts can be configured to result in user 2005 being locked out of the system entirely.
In one or more embodiments, and with reference to the AXEL digital signature 2040 functional modules, (including identity vault 2054 and the user owned storage 2055) all records stored or otherwise collected are encrypted. With continued reference to
Storage of the encrypted transaction records generated by AXEL wallet 2022 and AXEL digital signature 2040 can be managed by AXEL wallet database management 2027 and by AXEL digital signature 2040 database management 2050. In one or more embodiments, AXEL wallet 2022 database management 2027 may manage the storage of encrypted transaction records that do not contain a digital signature, whereas AXEL digital signature 2040 database management 2050 would manage the storage of encrypted transaction records that do contain a digital signature. In either embodiment, recall of any encrypted transaction record involves AXEL DCA security 2007, AXEL DCA security 2047, AXEL wallet 2022 encryption 2037 and database management 2027 and the AXEL digital signature 2040 database management 2050 and encryption 2053 functional elements.
As previously disclosed, the identity vault governs the user owned storage 2055 which is a physical device residing outside the AXEL blockchain that may be connected by the user. The user owned storage 2055 can take the form of a USB storage device, a flash drive, a hardware wallet, an external hard drive or any other storage repository that can be connected to the AXEL blockchain through the host computing device. It is contemplated that the user identity and digital signature information may alternatively reside on a user computer, laptop, tablet, smartphone or other device with storage capability.
While the user digital signature and identity information reside on the user owned storage 2055 that is outside the AXEL blockchain and is owned and managed by the user (not pictured) of the AXEL blockchain, access to the AXEL blockchain by the user owned storage 2055 is controlled and managed by the identity vault 2054 and by AXEL blockchain functional modules and elements including (but not limited to) the AXEL wallet 2022, AXEL digital signature functional modules 2040, the AXEL database 2047, 2015, 2027 and other modules that govern the usage of, or access to the AXEL blockchain. The purpose of creating access for an external storage repository (2055) is to enable the storage of personal and private information to be entirely disconnected from the blockchain, the network and the AXEL system itself. This separation ensures that the privacy and security of this vital and personal content may be taken entirely off the network, making nefarious access to the content contained within the identity vault highly restrictive to compromise.
The privacy and security of user information within the AXEL network is paramount to ensuring trust and enabling the engagement of online services such as the management of contracts and signatures in a digital realm.
As previously disclosed, the AXEL wallet enables public and private key generation to support the movement of tokens within the AXEL network and blockchain system. In some embodiments, the AXEL network may utilize an AXEL WebWallet that is hosted on the AXEL network itself to generate public and private keys for use on client devices (e.g., a personal device of an AXEL network user) and within user-owned wallets hosted on user-owned devices. The purpose of this alternative method for public and private key generation is to enable a network provisioner or host to determine how best to enable security protocol for the network itself.
Public and private keys may be managed in a variety of methods through both centralized and decentralized systems. Each public and private key system and method provides security at different levels and locations within networks. In a preferred embodiment, the AXEL network provides capabilities for both network-generated (through the AXEL WebWallet) and user-generated (through the AXEL desktop wallet) public and private key sets in order to enable activation of third-party security protocol to overlay within the AXEL Network.
In some embodiments, the AXEL WebWallet is a centralized, network-based wallet administration system and method that provides management and administration capabilities for public and private keys as well as for tokens (both native and third-party) that may exist or be present within the AXEL network. The AXEL WebWallet is deployed to the AXEL decentralized and distributed database (DDB) that is hosted in parallel with the AXEL blockchain across network nodes throughout the global network swarm.
In a preferred embodiment, the AXEL WebWallet will generate the key pair (public and private keys) for a user/client wallet that is installed on the user/client personal device and interfaces with the AXEL network. In this embodiment, the user/client private key generated by the AXEL WebWallet is not stored on, and does not have direct access to, the AXEL blockchain. These two elements are kept completely separate to ensure security of the user private key.
In this embodiment, the user/client private key is managed by the network decentralized distributed database (DDB) while the private key itself is stored in a fractionalized and encrypted fashion across the network swarm. More specifically, the private key is broken apart into fragments. Each fragment is then encrypted and stored within various locations (storage repositories such as nodes and/or storage servers/devices) across the AXEL network. The private key may not be recalled or otherwise accessed by the blockchain or by the AXEL network itself. The private key can only be called and accessed by the user's AXEL wallet located on the client device, and only when the user who owns the wallet has successfully passed all enabled wallet-access protocols including, but not limited to, providing a username and password, passphrase, multifactor authentication, PIN number and other security protocols that may be enabled. It is contemplated that any type of authentication methodology may be enabled. Should the user (wallet owner) lose their access information, for example, their username, password, passphrase or other necessary access keys, unless the system is specifically configured to allow for the recovery and/or reset of those access keys, the subject AXEL wallet and the tokens managed by the wallet will be inaccessible.
In another embodiment, the AXEL WebWallet controls AXEL tokens being managed through the network in a network wallet instance that is separate from the user/client key management system. As an example, the WebWallet, through a separately managed instance may delegate tokens to nodes to pay for their services in support of the networks. As is commonly known in the art, blockchains may be arranged to pay rewards in the form of tokens to node holders and operators for their services in supporting network. Two known methods of such rewards including proof of work and proof of stake. One type of blockchain protocol that utilizes a rewards concept, and is often set up as a proof of stake based rewards system, is a blockchain that is powered by Masternodes, whereby the Masternode operators are the nodes that run the network through consensus, and are rewarded with tokens for doing so. While Masternodes are referred to herein, they are one example of a node that participates in a distributed network. It is contemplated that any node that is participating could be used where a Masternode is referenced herein. In this embodiment, the AXEL WebWallet will control and track payments made to the supporting nodes.
In another embodiment, the AXEL WebWallet is responsible for collecting the fees associated with conducting transactions within the network. As an example, a network user may wish to upload a file and store it to the AXEL network. The AXEL network may be configured to charge a fee in the form of tokens to pay for the required storage to be allocated to the file being uploaded, as well as to compensate one or more Masternodes for conducting the transaction. The AXEL WebWallet would collect this fee from the user at the time of the upload transaction, and delegate the proceeds to the associated storage repository and/or network Masternodes, depending on the configuration defined by the network provisioner.
In one embodiment, the AXEL WebWallet is located on a single node and managed through the AXEL decentralized and distributed database (DDB). It is contemplated that the AXEL WebWallet can be entirely encrypted to prevent unauthorized access to the WebWallet and any key information being generated by the WebWallet. In a preferred embodiment of the AXEL WebWallet, a user creating an account on the AXEL network may be assigned a key pair by the AXEL WebWallet. This key pair would include a publicly visible key used to enable the receipt of crypto tokens through the network, and a private key that is not publicly visible and stored in a fragmented and encrypted fashion within the DDB.
In fractionalized file storage, and in reference to this submission, files are broken apart into small pieces. These pieces are then encrypted and a hash is created for each of the encrypted file components. Once the fragmentation and encryption has been completed, the encrypted file fragments are then stored in multiple locations throughout the AXEL network. By encrypting each fragment and applying a random algorithm to manage the storage locations of each fragment, unauthorized access to the key is restricted.
As stated above, in one embodiment, the DDB controls the fragmentation and encryption of each file fragment and the associated storage location. It is important to note that although the DDB may be configured to run on only a subset of the total network nodes, it could be configured to manage key storage on all nodes. More specifically, even though the DDB may not be present on a specific network node, the DDB may utilize the storage of that node to manage one or more encrypted file fragments for the purpose of enabling completely decentralize and distributed storage of the file fragments holding the private key. The DDB will store multiple copies of each fragment throughout the network to ensure the ability to call the fragments for reassembly when the private key is used.
The usage of the private key generated by the AXEL WebWallet is facilitated by the user who created the subject AXEL Wallet on their personal device and within their account. As an example, if a user wishes to send a blockchain token to another user, the AXEL Wallet that caused the AXEL WebWallet to generate the private key may call that private key at any time for usage. In order for a private key to be called from the AXEL WebWallet, the user calling the key (through their mobile or desktop AXEL Wallet) must first authenticate their access to the subject account. This process includes, but is not limited to providing a username, a password, a passphrase, performing a multifactor authentication and the like. Further authorization for the private key usage may be obtained by the AXEL WebWallet DDB by accessing the user device information such as the MAC code for the device hosting the wallet, the IP address accessing the wallet, the geolocation information associated with the user wishing to access the wallet and other criteria that may be used to identify the device and the subject device location to enable private key access.
Assuming a user has successfully completed the authorization and access criteria to enable the usage of their wallet private key to transfer blockchain tokens, the AXEL WebWallet will recall the fragmented portions of the private key and apply the decryption algorithm required to unlock each fragment of the private key, and to subsequently recombine them. The private key will not be transferred to, stored on, or otherwise hosted at the client location. They private key will only be available for the authorized user to authorize a transaction using their private key that is hosted within the AXEL WebWallet.
In a preferred embodiment, the private key may only be recalled while the user wallet that created the key generation event (the actual creation of the original public and private key pair) is online and currently active. As an example, if a user has created an AXEL WebWallet key pair and is using their client AXEL wallet as a cold storage wallet (where the wallet itself is hosted on a USB type storage device and only present when the USB device is actively connected to a computing device that is also synchronized with the blockchain), the private key may not be polled and decrypted for use as the host wallet generating the key will appear offline. This is an additional layer of security to prevent a wallet from being breached should the user's confidential access information be compromised. Even if a hacker has attained all of the required authentication information to breach a user AXEL WebWallet, the wallet itself may not be accessed if it is not actively connected to the network.
A typical key generation and recall event within the AXEL WebWallet will now be discussed with reference to
With reference to
Once user 2195 has generated a wallet 2199 on their device 2190, the wallet 2199 will submit a request to the AXEL WebWallet 2165 to generate a key pair. The key pair will include a public key used to enable receipt of crypto tokens, and a private key used to enable transmission of the crypto tokens from AXEL wallet 2199. The AXEL WebWallet will seek authorization for the key pair generation from the AXEL network itself utilizing user 2195 information that was captured and stored during the account creation event discussed previously in this submission.
The public key generated by the above request will be provided to user wallet 2199 from AXEL WebWallet 2165. Since this key is public, it is not necessary to encrypt or otherwise protect it beyond normal encryption and transaction protocols as the key will be used by user 2195 to share among other people, allowing user 2195 to receive blockchain tokens at the user's wallet 2199.
The private key generated by the above request will subsequently be broken into smaller file fragments, encrypted and then stored on approved storage locations distributed throughout the network. Hash codes will also be generated to track where the various fragments are stored. In a preferred embodiment, the hash codes also track the information that each fragment includes to allow the fragments to be recalled and the private key to be reconstituted. As an example, and with continued reference to
Once a private key has been generated by the AXEL WebWallet 2165 and stored in an encrypted and fragmented fashion, it may then be called by the user 2195 who owns the wallet 2199 to perform a transaction. Specifically, the private key is called by the wallet 2199 for transactions involving blockchain tokens leaving the subject wallet 2199. Private keys generated by the AXEL WebWallet are not stored on, shared with or otherwise transferred to any user wallet or any repository outside of the storage hosting the encrypted key fragments. The private key will remain under complete control of AXEL WebWallet 2165 and the encrypted fragments stored on the approved network storage repositories. In this example, the repositories reside on node 22140, hosting fragment 2185, node 42180, hosting fragment 2180 and node 72130, hosting fragment 2175. The purpose of restricting access, storage and control over the private key is to ensure security and limit access to the key, protecting the assets stored in the user 2195 wallet 2199.
As a private key is called by user 2195 through the wallet 2199, the request is sent to the AXEL WebWallet 2165. Assuming all of the subject security protocol has been satisfied, the AXEL WebWallet 2165 will call each of the encrypted file fragments 2180, 2185 and 2175 for decryption and recombining using the hash codes assigned to the reference fragments by the AXEL WebWallet 2165. Specifically, in one embodiment, the reference encrypted file fragments (2180, 2185, and 2175) being called by the WebWallet 2165 are activated by a hash code stored in the WebWallet and activated by the user private key. The unique hash that calls the reference encrypted file fragments is stored in the WebWallet 2165 as well as in the decentralized distributed database. A validation of the hash is performed (not pictured) wherein the hash stored in the WebWallet 2165 is compared to the hash stored in the decentralized distributed database. Assuming these hash codes match (and the user has logged in and has fully completed the authentication process that has been put in place, including, for example, by connecting a cold storage wallet such that it is noted to be online) the reference file fragments will be called. Once the key is recombined in AXEL WebWallet 2165, the user 2195 transaction request made through wallet 2199 will be executed.
The private key is utilized by user 2195 by accessing their wallet 2199 and passing the required login and access protocol. As discussed previously, accessing the wallet 2199 may include, but is not limited to providing a username, password, passphrase, multifactor authentication, a MAC code verification from the device the host wallet is stored, an IP verification from the location of the device and other criteria as required by the network administration or provisioning host.
The private key is utilized solely for the purpose of approving a transaction for blockchain tokens leaving the subject user 2195 wallet 2199. Therefore, access to that key is only required momentarily to verify the user 2195 and the subject wallet 2199 are approved to utilize the wallet for transmitting tokens out of the wallet 2199.
Upon completion of the executed wallet transaction 2199, the AXEL WebWallet 2165 will again fragment the private key, encrypt each of the fragments, assign a hash code to each of the fragments and again store them on the network 2105. In a preferred embodiment, the fragments and the associated hash codes are different than those used for previous instances where the private key was stored, and no fragments or hash codes are repeated. Using new fragments and hash codes adds additional security to the network. It is also possible to reuse some or all of the hash codes. For example, fragments could be reused and stored in different locations. For example, referring to the previous description reference to
In a preferred embodiment, once fragments are recalled and recombined into a complete digital asset such as a file, folder or the like, the remaining duplicate and unused fragments are destroyed and/or rendered useless. For example, destroying the hash code used to recall these fragments would make the recombination of any remaining existing fragments impossible. In a preferred embodiment, since the remaining and unused fragments are now orphans, they will be recognized as such by the system and will be subsequently removed as they will no longer have an association with a hash to recall them. If the same private key information is again fragmented, encrypted, and stored within the system, the fragments themselves will be different from the previously created fragments, making the previous fragments incompatible with the new. Moreover, the quantity of fragments and the storage locations of these fragments will be randomized by the system to ensure security of the private key being sharded. It is important to note that the randomization within the system allows for fragment quantities, sizes and storage locations to be created by an algorithm that purposely randomizes this process each time to ensure maximum privacy and security of the asset being stored and recalled.
The AXEL network also provides a system and method for management of user accounts being created throughout the global network by a method called shards. A shard is a flexible and movable repository to manage user account creation, network access, AXEL WebWallet creation and access, and other user-specific elements within a group of one or more users. Shards are intended to host a flexible number of users and/or user applications such as wallets in a grouping that can be easily moved to any appropriate location on the network in order to enable a seamless balance of network resources and unlimited scalability of the network itself. Shards can be relocated by the network itself or by a programmer/administrator to other areas of the network during unforeseen service outages or diminished service levels.
In a preferred embodiment, a network shard may exist on one or more network nodes and limit the number of user accounts being created on and/or accessed through the subject shard, based upon available network resources such as bandwidth, processing power, memory, latency, traffic, geographic location, uptime and other factors that can impact network performance.
In one or more embodiments, network users may be assigned to a specific shard based on their geography or origin of access. This assignment ensures the best possible connectivity to the network resulting in lower latency, faster access and faster overall network response times. A user assigned to a shard can be moved by the network to a different shard for reasons such as load balancing, improving network access and/or latency, Masternode status and other elements that can impact the performance of one or more Masternodes provisioned within a network.
In another embodiment, one or more users from within a shard may be reassigned by the AXEL network to one or more varying shards based on load balance needs of the network. As an example, if a specific area of the network is experiencing an extreme resource load, one or more users, or the entire shard of users may be relocated by the network to one or more different Masternodes in order to improve latency, access and resource distribution. It is contemplated that a network administrator may also choose to move shards manually as opposed to allowing the AXEL network itself to manage shard administration.
Users within a shard may be assigned individually or as a shard. A shard can be relocated from one or more Masternodes to one or more second Masternodes, or may be removed entirely, assigning the one or more user accounts to one or more different shards hosted within the network.
The purpose of managing user accounts within a shard architecture is to enable the movement of the subject user accounts and respective shards in whole or in part, to portions of the network that are experiencing less traffic volume, lower resource usage or may be moved during a crisis event such as a failed Masternode or partial network outage.
A shard may also be configured to control resource distribution for specific aspects of a blockchain network such as the AXEL network. As an example, a shard may contain a disproportionate number of users as compared to AXEL wallets. A shard may be generated to host user wallets in order to move them to a network location that has more immediately available network resources to manage wallet and transaction traffic. Shards can be fragmented, disassembled, reassembled, combined or absorbed into other shards, or dismantled entirely based on the needs of the network and the associated load and resource management.
A typical implementation of the shard management module will now be discussed with reference to
In
The AXEL DDB is shown running at node 12125, node 32135, node 42110, node 62115 and node 72130, as depicted by the double-line as referenced in the diagram legend on the right-hand side of
The blockchain network 2105 diagram also depicts multiple shards running through a various number of network nodes at various locations. Specifically, shard 22150 is shown running through node 42110, and node 52120. Shard 3 is shown running through node 62117, and node 72130. Shard 42160 is shown running on a single node 2145 and shard 12170, is shown running through node 12125, node 22140 and node 32135. Additionally, a WebWallet 2165 is shown running on node 32135.
As stated previously, the purpose of a shard is to manage user access in addition to user tools, apps and utilities such as cryptocurrency wallets, network access, user device access and other attributes associated with functions and devices a user of a blockchain network would employ. As can be seen in
As an example, and with continued reference to
Some network shards such as shard 42160, running on node N 2145, may be limited to a single node. This may be the result of the network administrator or provisioner choosing to limit the node 2145 to a single shard, or may be provisioned as a result of limited network resources as stated above. Network shards may also be provisioned to handle specific network elements. As an example, (with continued reference to
Shards may be combined in any fashion and may similarly be broken down and divided in any fashion, limiting the functional elements within a shard (as stated in the wallet example above). Shards may be configured an unlimited amount of time to facilitate the network configuration, resource needs, or simply the needs of the network administrator or provisioner.
This application is a continuation-in-part of U.S. patent application Ser. No. 17/032,272, filed on Sep. 25, 2020, which is a continuation-in-part of U.S. patent application Ser. No. 16/900,771, filed on Jun. 12, 2020, which is a continuation-in-part of U.S. patent application Ser. No. 16/856,017, filed on Apr. 22, 2020, which is a continuation-in-part of U.S. patent application Ser. No. 16/438,299, filed Jun. 11, 2019, which is a continuation-in-part of U.S. patent application Ser. No. 16/271,694, filed Feb. 8, 2019, which is a continuation-in-part of U.S. patent application Ser. No. 16/035,658, filed Jul. 15, 2018, which is a continuation-in-part of U.S. patent application Ser. No. 15/961,521, filed Apr. 24, 2018.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 17032272 | Sep 2020 | US |
| Child | 17308354 | US | |
| Parent | 16900771 | Jun 2020 | US |
| Child | 17032272 | US | |
| Parent | 16856017 | Apr 2020 | US |
| Child | 16900771 | US | |
| Parent | 16438299 | Jun 2019 | US |
| Child | 16856017 | US | |
| Parent | 16271694 | Feb 2019 | US |
| Child | 16438299 | US | |
| Parent | 16035658 | Jul 2018 | US |
| Child | 16271694 | US | |
| Parent | 15961521 | Apr 2018 | US |
| Child | 16035658 | US |
