CA3175232A1 - A system and method using a web3.0 digital self-sovereign-identity wallet, digital identity tokens, blockchain, and identity based authentication to deliver assets, more specifically electronic signatures and electronic prescriptions bound with validated digital identity credentials - Google Patents

Abstract

An exemplary digital identity token includes a token ID, identity components, and a payload (assets). The identity component consists of validated identity and credentials. The architecture includes a document signing coordinator and a title office that manages ownership of tokens and records proof of ownership on the blockchain. Each party participating in e-signature and e-prescription transactions using the token has a digital wallet. The document signing coordinator coordinates the wallet owner's document signing activities and acts as an arbiter for wallet owners to resolve disputed transactions. Each time a validated wallet owner electronically signs a digital document (asset), the signee adds their electronic signature to the digital document or an electronic prescription with proof of validated identity and credentials. The system provides the wallet owner or pharmacy receiving the electronic document a means to validate the document and the sender's credentials. E-signed documents and e-Prescriptions are stored on the device.

Description

A SYSTEM AND METHOD USING A WEB3.0 DIGITAL SELF-SOVEREIGN-IDENTITY WALLET, DIGITAL IDENTITY TOKENS, BLOCKCHAIN, AND IDENTITY BASED AUTHENTICATION TO DELIVER
ASSETS, MORE SPECIFICALLY ELECTRONIC SIGNATURES AND
ELECTRONIC PRESCRIPTIONS BOUND WITH VALIDATED DIGITAL
IDENTITY CREDENTIALS
CROSS REFERENCE TO RELATED APPLICATIONS
[0001] This application is a continuation-in-part of application no.
17,503,307 filed on Nov. 16, 2021, the content of which is incorporated by reference herein in its entirety.
Application no. 17,503,307 is, in turn, a continuation-in-part of both application no.
16,391,259 filed on April 22, 2019, and application no. 16,218,385 filed on Dec. 12, 2018 (now US Patent 11/139,976), the contents of which are incorporated by reference herein in their entireties. The applicant claims full priority based on all the parent applications.
TECHNICAL FIELD

[0002] This patent application relates to electronic transactions involving cryptographic tokens, such as tokens used in blockchain systems and other business transactions.
Further, the present invention involves systems and methods for secure electronic recordation of commercial transactions and transaction participants by exploiting techniques including cryptography, blockchain, and distributed ledgers.
BACKGROUND

[0003] Traditional paper-based commercial documentation is nowadays routinely recorded electronically, such as with agreements and contracts. Such documents may be signed by the participating parties with wet signatures or electronic signatures. No matter how the signatures are obtained, the documents can be preserved permanently without risk of subsequent fraudulent altering by tokenizing the document and the transaction and storing this recordation of all the material on a blockchain. However, even then, questions and issues can arise as to the true identity of a signatory on the document and/or as to whether a signature on the document is a true record of that person's participation in the document. As an illustration, later denial of correctness or validity can occur in agreements with relatively low watertightness, such as agreements signed with a wet Page 1 of 59 Date Regue/Date Received 2022-09-21 signature. In such agreements, a signatory may subsequently claim that he never made a deal for some reason. For example, the signatory may argue that the signature on the document was forged without his knowledge.

[0004] Accordingly, it would be beneficial to provide an electronic recordation system with mechanisms that require the secure identification of users and secure authentication of signatories' participation in a commercial transaction. Similarly, it would be advantageous to provide a method having such characteristics.

[0005] In the field of medical prescriptions, generally, most prescriptions are written by hand by a doctor (physician) on paper or generated by computer software. Then the prescription is either taken to a pharmacy by the patient or electronically transmitted (e.g., faxed) by the doctor directly to the patient's pharmacy (drugstore). However, hand-written prescriptions are subject to transcription errors or forgery, or they may be lost or misplaced by the patient. In addition, faxed prescriptions are subject to insecure or incorrect transmission. Furthermore, transcription errors may occur on data entry into the pharmacy's prescription management software.

[0006] Thus, it would be beneficial to provide an electronic system with mechanisms that require the secure identification of doctors, patients, and pharmacies, with secure authentication and execution of medical prescriptions. Similarly, it would be advantageous to provide a method having such characteristics.
BRIEF SUMMARY

[0007] It is an object of the present invention to mitigate limitations in the prior art relating to electronic recordation of commercial transactions. More particularly, to achieve systems and methods for providing secure tokenized assets, using electronic signatures coupled with validated identity credentials. The combination of an electronic signature and a validated identity credential constitutes a secure digital signature.
This is achieved by exploiting cryptography, digital signatures, self-sovereign-identity, digital identity tokens, blockchain, and strong authentication, including biometric authentication. Such systems and methods provide certainty and confidence to the commercial world and government digital identity programs.
Page 2 of 59 Date Regue/Date Received 2022-09-21

[0008] Another object of the present invention is to attain systems and methods for providing secure recordation of assets, benefits, rights, value, obligations, limitations, etc., of various kinds. Examples are currency, real estate, gold, works of art, collectibles, tickets to events, lottery tickets, rewards points, gift cards, pre-prepaid card values, e-coupons, carbon credits, electronic signatures, processing power, data storage space, and any asset that an individual can own or create.

[0009] An exemplary digital identity token of the present invention includes a token ID, identity components, and a payload (asset component). The identity components relate to proof of identity of persons who own or have owned the token.

[0010] In an exemplary arrangement of participants using a system in accordance with certain embodiments of the present invention, the system includes a system administrator's air gap servers and a blockchain. The air gap servers include a document signing coordinator, a Title Office that controls ownership of tokens and records the ownership on the blockchain, and an escrow service.

[0011] Each party participating in an electronic signature transaction using the system has a mobile, desktop, or server-based digital wallet. The document signing coordinator functions as a point of connectivity where signers can coordinate their signing activity with reasonable automation.

[0012] Each time a party digitally signs a document, they add their electronic signature to the document and simultaneously provide an electronic third-party validated identity. Both the electronic signature and the validated identity are contained in a digital identity token having the document, and the digital identity token is then processed in the next stage of the electronic signature transaction. Thus, a digital signature performed by any given party is essentially a combination of their electronic signature and their validated identity.
The combination of the electronic signature and the validated identity constitutes a secure digital signature. That is, the combination provides excellent assurance that the digital signature is indeed valid and genuine.

[0013] In accordance with embodiments of the present invention, there are provided at least three methods as follows.
Page 3 of 59 Date Regue/Date Received 2022-09-21

[0014] In one method, the creation and storage of a digital identity token are effected.
The token includes an identity component. The token does not include an additional payload representing an item of value. The token represents the validated digital identity of a digital wallet owner.

[0015] In another method, the creation and storage of a digital token are effected, wherein the token includes a representation of an item of value in addition to an identity component.

[0016] In a further method, the transfer of a digital token from a current owner to a new owner is effected, wherein the token includes a representation of an item of value.

[0017] In accordance with more embodiments of the present invention, there are provided at least three methods as follows. All these methods use digital tokens and employ systems of the present invention.

[0018] In one method, a final, valid, digitally signed, and non-repudiated document is created and stored on a blockchain. The document can, for example, be a contract. The system utilized provides proof of the authenticity of the document. That is, proof that the document has not changed since it was stored at a specific point in time. This is accomplished by digitally signing the document and thus creating a hash of the digitally signed document, the hash being the document's unique digital identifier. The identifier is then stored on the blockchain, and the transaction having the document is timestamped. Since every entry in the blockchain is immutable, the system administrator has proof that the specific document in its form as recorded on the blockchain existed at a specific point in time.

[0019] In another method, a medical e-prescription is created and utilized through to delivery of the medical good or service. A characteristic of the method is that a doctor tokenizes an e-prescription and transmits the token to a pharmacy. All this occurs prior to a patient becoming involved.

[0020] In a further method, a medical e-prescription is created and utilized through to delivery of the medical good or service. A characteristic of the method is that a doctor Page 4 of 59 Date Regue/Date Received 2022-09-21 tokenizes an e-prescription and sends the token to a patient. All this occurs prior to a pharmacy becoming involved.

[0021] Other aspects and features of the present invention will become apparent to those of ordinary skill in the art upon review of the following description of specific embodiments of the present invention in conjunction with the accompanying figures.
BRIEF DESCRIPTION OF THE DRAWINGS

[0022] Embodiments of the present invention will now be described, by way of example only, with reference to the attached figures.

[0023] Figure 1 schematically depicts a digital self-sovereign-identity (SSI) token according to embodiments of the present invention.

[0024] Figure 2 schematically depicts two different types of servers of an administrator of a token management system, according to two embodiments of the present invention.

[0025] Figure 3 schematically depicts the network connectivity of major participants of an exemplary token management system according to the present invention.

[0026] Figure 4 shows an exemplary arrangement of participants using a system in accordance with certain embodiments of the present invention.

[0027] Figure 5 shows exemplary electronic devices used to create a digital SSI token of the kind shown in Figure 1 and details of a person's e-signature stored in an exemplary digital SSI token.

[0028] Figure 6 shows two electronic signatures being used in an exemplary transaction document.

[0029] Figure 7 shows a manual change made to the document of Figure 6.

[0030] Figure 8 shows an exemplary digital identity token stored on a blockchain when an electronic signature transaction involving a non-repudiated document is underway or completed.

[0031] Figure 9 is a flowchart of creating a final, valid non-repudiated document in accordance with one embodiment of the present invention.

[0032] Figure 10 is a flowchart of an exemplary method for creating, using, and storing a medical e-prescription in accordance with one embodiment of the present invention.
Page 5 of 59 Date Regue/Date Received 2022-09-21

[0033] Figure 11 is a flowchart of an exemplary method for creating, using, and storing a medical e-prescription in accordance with another embodiment of the present invention.
DETAILED DESCRIPTION

[0034] The present description is in one aspect directed to electronic recordation of commercial transactions. More particularly, to systems and methods for providing secure tokenized assets having electronic signatures coupled with validated identity credentials.
The combination of an electronic signature and a validated identity credential constitutes a secure digital signature. This is achieved by exploiting cryptography, self-sovereign-identity, digital identity tokens, blockchain, and strong authentication, including biometric authentication. Such systems and methods provide certainty and confidence to the commercial and the governmental worlds.

[0035] The ensuing description provides representative embodiments only and is not intended to limit the scope, applicability, or configuration of the disclosure. Rather, the ensuing description of the embodiments will provide those skilled in the art with an enabling description for implementing them. It is understood that various changes can be made in the function and arrangement of elements without departing from the spirit and scope as set forth in the appended claims. Accordingly, an embodiment is an example or implementation of the present invention and not the sole implementation.
Various appearances of "one embodiment," "an embodiment," or "some embodiments" do not necessarily all refer to the same embodiments. Although various features of the present invention may be described in the context of a single embodiment, the features may also be provided separately or in any suitable combination. Conversely, although the present invention may be described herein in the context of separate embodiments for clarity, the present invention can also be implemented in a single embodiment or any combination of embodiments.

[0036] Reference in the specification to "one embodiment," "an embodiment,"
"some embodiments," or "other embodiments" means that a particular feature, structure, or characteristic described in connection with the embodiments is included in at least one embodiment, but not necessarily all embodiments, of the present invention. The phraseology and terminology employed herein are not construed as limiting but are for Page 6 of 59 Date Regue/Date Received 2022-09-21 descriptive purposes only. It is to be understood that where the claims or specification refer to "a" or "an" element, such reference is not to be construed as there necessarily being only one of that element. It is to be understood that where the specification states that a component feature, structure, or characteristic "may," "might," "can,"
or "could" be included, that particular component, feature, structure, or characteristic is not required to be included.

[0037] Any reference to terms such as "left," "right," "top," "bottom,"
"front," and "back" are intended for use with respect to the orientation of the particular feature, structure, or element within the figures depicting embodiments of the present invention. It would be evident that such directional terminology with respect to the actual use of a device or system has no specific meaning, as the device or system can be employed in a multiplicity of orientations by the user or users.

[0038] Reference to the terms "including," "comprising," "consisting," and grammatical variants thereof do not preclude the addition of one or more components, features, steps, integers, or groups thereof; and the terms are not to be construed as specifying components, features, steps, or integers. Likewise, the phrase "consisting essentially of"
and grammatical variants thereof, when used herein, is not to be construed as excluding additional components, steps, features, integers, or groups thereof; rather, the additional features, integers, steps, components, or groups thereof do not materially alter the basic and novel characteristics of the claimed composition, device, or method. If the specification or claims refer to "an additional" element, that does not preclude there being more than one of the additional elements.

[0039] As used herein and throughout this disclosure, a "portable electronic device" (PED) refers to a wireless device used for communications and other applications that requires a battery or other independent form of energy for power. This includes, but is not limited to, devices such as a cellular telephone, smartphone, personal digital assistant (PDA), portable computer, pager, portable multimedia player, portable gaming console, laptop computer, tablet computer, wearable device, and electronic reader.

[0040] A "fixed electronic device" (FED), as used herein and throughout this disclosure, refers to a wireless and/or wired device used for communications and other applications which require connection to a fixed interface to obtain power. This includes, but is not Page 7 of 59 Date Regue/Date Received 2022-09-21 limited to, a laptop computer, personal computer, computer server, kiosk, gaming console, digital set-top box, analog set-top box, internet-enabled appliance, internet-enabled television, and multimedia player.

[0041] A "server" as used herein and throughout this disclosure refers to one or more physical computers co-located and/or geographically distributed and running one or more services as a host to users of other computers, PEDs, FEDs, etc. to serve the client needs of these other users. This includes, but is not limited to, a database server, file server, mail server, print server, web server, gaming server, and virtual environment server.

[0042] An "application" (commonly referred to as an "app") as used herein may refer to but is not limited to a "software application," an element of a "software suite," a computer program designed to allow an individual to perform an activity, a computer program designed to allow an electronic device to perform an activity, and a computer program designed to communicate with local and/or remote electronic devices. An application thus differs from an operating system (which runs a computer), a utility (which performs maintenance or general-purpose chores), and a programming tool (with which computer programs are created). Generally, within the following description with respect to embodiments of the present invention, an application is presented in respect of software permanently and/or temporarily installed upon a PED and/or FED.

[0043] An "enterprise" as used herein may refer to but is not limited to a provider of a service and/or a product to a user, customer, or consumer. This includes, but is not limited to, a retail outlet, a store, a market, an online marketplace, a manufacturer, an online retailer, a charity, a utility, and a service provider. Such enterprises may be directly owned and controlled by a company that may be owned and operated by a franchisee under the direction and management of a franchiser.

[0044] A "service provider" as used herein may refer to, but is not limited to, a third-party provider of a service and/or a product to an enterprise and/or individual and/or group of individuals, and/or a device comprising a microprocessor. This includes, but is not limited to, a retail outlet, a store, a market, an online marketplace, a manufacturer, an online retailer, a utility, and an own-brand provider, wherein the service and/or product is at least one of marketed, sold, offered, and distributed by the enterprise solely or in addition to the service provider.
Page 8 of 59 Date Regue/Date Received 2022-09-21

[0045] A "third party" or "third-party provider" as used herein may refer to, but is not limited to, a so-called "arm's length" provider of a service and/or a product. The service and/or product is provided to an enterprise and/or individual and/or group of individuals and/or a device comprising a microprocessor, wherein the consumer and/or customer engages the third party, but the actual service and/or product that they are interested in and/or purchase and/or receive is provided through an enterprise and/or service provider.

[0046] A "user" as used herein may refer to but is not limited to an individual or group of individuals. This includes but is not limited to private individuals, employees of organizations and/or enterprises, members of community organizations, and members of charity organizations. In its broadest sense, the user may further include, but not be limited to, software systems, mechanical systems, robotic systems, android systems, etc., that may be characterized by an ability to exploit one or more embodiments of the present invention. A user may be associated with biometric data, which may be, but is not limited to, monitored, acquired, stored, transmitted, processed, and analyzed either locally or remotely to the user. A user may also be associated through one or more accounts and/or profiles with one or more of a service provider, third-party provider, enterprise, social network, social media, etc. via a dashboard, web service, website, software plug-in, software application, and/or graphical user interface.

[0047] A "wearable device" relates to miniature electronic devices worn by the user, including those under, within, with, or on top of clothing. Wearable devices are part of a broader general class of wearable technology, including "wearable computers,"
which in contrast are directed to general or special purpose information technologies and media development. Such wearable devices and/or wearable sensors may include, but not be limited to, smartphones, smart watches, e-textiles, smart shirts, activity trackers, smart glasses, environmental sensors, medical sensors, biological sensors, physiological sensors, chemical sensors, ambient environment sensors, position sensors, neurological sensors, drug delivery systems, medical testing and diagnosis devices, and motion sensors. The wearable devices and/or wearable sensors may also include, but not be limited to, devices that can stimulate and/or measure parameters that are designed to fit on or near the perineum, anal area, vagina, clitoral area, and nipples.
Page 9 of 59 Date Regue/Date Received 2022-09-21

[0048] "Biometric" information as used herein may refer to, but is not limited to, data relating to a user characterized by data relating to a subset of conditions including, but not limited to, their environment, medical condition, biological condition, physiological condition, chemical condition, ambient environment condition, position condition, neurological condition, drug condition, and one or more specific aspects of one or more of these conditions. Accordingly, such biometric information may include, but not be limited to, blood oxygenation, blood pressure, blood flow rate, heart rate, temperature, fluidic pH, viscosity, particulate content, solids content, altitude, vibration, motion, perspiration, EEG, ECG, energy level, etc. In addition, biometric information may include data relating to physiological characteristics related to the shape and/or condition of the body, wherein examples may include but are not limited to fingerprint, facial geometry, baldness, DNA, hand geometry, odor, retinal patterns, iris patterns, eye vein patterns, and scent. Biometric information may also include data relating to behavioral characteristics, including but not limited to typing rhythm, gait, and voice.

[0049] A "reward" or "rewards" is referred to in the context of rewards programs, loyalty programs, or incentive programs. Such rewards programs, loyalty programs, and incentive programs typically relate to a structured marketing strategy designed by merchants, employers, organizations, users, etc., to encourage customers to continue to shop at or use the services of businesses associated with each program. These programs cover most commerce types, each one having varying features and rewards schemes.
Such programs may be so-called business-to-consumer (B2C) or business-to-business (B2B) programs. They may relate to one or more physical transactions, electronic transactions, mail orders, physical retailing, online retailing, etc.

[0050] A "blockchain" (originally block chain) as used herein may refer to, but not be limited to, a continuously growing list of records, called blocks, which are linked and secured using cryptography. Each block typically contains a cryptographic hash of one or more other blocks in the chain, a timestamp, and transaction data. By design, a blockchain is inherently resistant to modification of the data. It provides an open, distributed ledger that can efficiently record transactions between two or more parties in a verifiable and permanent way. A blockchain is typically managed by a peer-to-peer network collectively adhering to a protocol for inter-node communication and validating Page 10 of 59 Date Regue/Date Received 2022-09-21 new blocks for use as a distributed ledger. Once recorded, the data in any given block cannot be altered retroactively without the alteration of all subsequent blocks. Blockchains are secure by design and exemplify a distributed computing system with high Byzantine fault tolerance. Therefore, decentralized consensus is achieved with a blockchain, making them suitable for recording events, medical records, and other records management activities, such as identity management, electronic signatures, financial transaction processing, documenting provenance, food traceability, voting, etc. Within embodiments of the present invention, the cryptographic hash may also include a pointer (and possibly a hash) of the address of the next block in the chain. In general, a blockchain can be considered to be an immutable data store.

[0051] A "distributed ledger" as used herein may refer to, but not be limited to, a database that is consensually shared and synchronized across one or more networks spread across multiple sites, institutions, and/or geographies. It allows transactions to have public "witnesses," thereby making a cyberattack more difficult. The participant at each node of the network can access the recordings shared across that network and own an identical copy. Further, any changes or additions made to the ledger are reflected and copied to all participants quickly, usually within seconds or minutes. Underlying distributed ledger technology are blockchains.

[0052] "Self-Sovereign-Identity" as used herein may refer to, but not be limited to, an identity which is created and managed by the individual and enables him/her to maintain their digital identity independent from national or state/provincial electronic identity credential infrastructure, and service providers. According to Allen (2016, "The Path to Self-Sovereign Identities"), a self-sovereign identity can be characterized by the ten commandments. These being, existence of the identity of a person independent of identity administrators or providers, the person being in control of their digital identities, the person having full access to their data, systems, and algorithms, the data systems and algorithms being transparent, digital identities being persistent, digital identities being portable, digital identities being interoperable, a data economy being enforced, and the rights of the person being protected.

[0053] In the following description, unless the context indicates otherwise, a "relying party"
is or includes a website or other entity on the internet that uses an identity provider to Page 11 of 59 Date Regue/Date Received 2022-09-21 authenticate a user who wants to log in, which logging in is a grant of access to information or a system. Examples of relying parties are a bricks-and-mortar retailer, an online retailer, a government department or agency, an enterprise, an organization, and so on.

[0054] Certain embodiments of the present invention relate to a hybrid blockchain/mutual distributed ledger that utilizes digital tokens. Some aspects and features of the blockchain, digital tokens, and associated systems and methods are described below.
Any system described may be referred to as a CoR.io system. In the following description, a hybrid blockchain/mutual distributed ledger may simply be referred to as a "blockchain."

[0055] Blockchain

[0056] Globalization and population growth increase the pressure to find cost-effective solutions to prove individuals' identities and validate their transactions.
The following embodiments are based on a hybrid blockchain/mutual distributed ledger system called CoRChain. CoRChain may also be referred to herein as the "CoR.io blockchain"
or simply a "hybrid blockchain token system" or a "digital token management system." An administrator oversees the running of the token management system, and in this description, the administrator is called CoR.io. CoRChain is an immutable digital ledger;
that is, an unalterable register. CoRChain allows groups of people to validate, record, and track transactions which involve data transmissions across a network of decentralized smart devices (including smartphones, tablets, and PCs) and cloud-based systems. That is, the smart devices are typically PEDs and FEDs. Participants follow a common protocol that allows individuals to add new transactions and distribute them using a peer-to-peer architecture. CoRChain employs multiorganizational databases with multiple layers of protection against cyberattacks. The protection layers include controlled access to cloud-based instances and an immutable audit trail.

[0057] CoRChain improves upon current blockchain technology to provide a secure and reliable method of recording transaction information for a variety of uses.
The individual entries on the blockchain ledger can be any digital record. Further, embodiments of the present invention utilize an electronic wallet (or digital wallet) of the CoR.io system, CoRWallet. For the CoR.io electronic wallet (or e-wallet), digital assets include identity documents; third-party validations of CoR.io digital tokens and digital identity tokens Page 12 of 59 Date Regue/Date Received 2022-09-21 (CoRTokens); tokenized retail transactions and receipts; records of financial cards, direct bank transactions; tokenized digital reward coupons; tokenized electronic signatures; and CoRTokens representing identity and assets. Other assets include validated and identity assured digital signatures on the blockchain. Every CoR.io digital token resides on the blockchain. The expressions "CoR.io token" and "CoRToken"
are used interchangeably in this description.

[0058] CoRChain is cryptographically secured since every transaction in the ledger is digitally signed. While ledgers are managed as a service, all transactions are signed using relevant digital keys belonging to the transaction participants.
Participants can access the blockchain by using their digital keys and biometric authentication. Digital keys that decrypt and use the information on the ledger exist solely in a secure personal data storage area (personal data store) in each participant's digital wallet, with the current owner of a recorded asset being the only holder of the keys to that asset. A
consumer's CoRWallet blockchain node is embedded in the consumer's CoRWallet, which resides in the consumer's smart device (such as a smartphone). The CoR.io digital wallets of retailers, service providers, organizations, and other transaction participants reside on their respective computing devices such as servers.

[0059] CoR.io cannot access hashed information or raw transaction data held in the retailer's transaction server. Instead, this data is distributed on a need-to-know basis by each transaction participant to their CoR.io blockchain server and a CoR.io administrator server. The CoR.io administrator server is also referred to herein as the "CoRChain server" or the "CoR.io cloud server." The CoR.io cloud server is located behind a gateway of a CoR.io cloud. Transaction confirmation and account reconciliations are in real-time because the CoRChain server exposes simple endpoints that easily connect to CoRWallet and utilize CoRToken.

[0060] CoRChain architecture allows three different modes of asset storage: in a reader-accessible format, an encrypted format, and a one-way hash that provides proof that an asset holder is the legitimate controller of that asset.

[0061] The ledger is distributed at the level of a digital asset. Most "local copy" ledgers contain only assets that are important to the individual holding the copy.
Page 13 of 59 Date Regue/Date Received 2022-09-21

[0062] At the CoR.io administrator server-side "nodes," CoRChain relies on unidirectional "air-gapped" networking hardware to isolate the "ledger of record" from potential cyberattack threats. Communication with this air gap employs one-time-pad encryption technology for maximum cyber threat avoidance and high-speed performance. The hardware currently supports data transfer rates of up to 9 GB/sec.
Typically, a CoRChain transaction consists of 128 bytes of data. This equates to a raw throughput of 9/6 million transactions per second through a single air-gapped networking unit. These rates are easily scalable upward with additional hardware.
Contents of the ledger are encoded using protocols that exceed SHA256 standards.

[0063] Every participant's CoR.io blockchain is concerned only with information of interest to that participant. The general concept of CoRChain consensus is not the same as that used by public blockchains such as Bitcoin or Ethereum. Each participant's CoR.io blockchain contains immutable proof that the identity attributes, transaction records, and incentive values continue to exist in the original form. Local copies of the digital assets are distributed among all the holders of a CoR.io digital wallet. These copies contain assets of interest only to the wallet holder. A
multi-phase commit process ensures that all updates are completed. The commit process deals with e-wallets that are temporarily offline, and it also negates spoofing via "replay" of cryptographic sequences between multiple service/server "nodes."

[0064] CoRChain's distributed ledger shares the core value of trust across boundaries without putting any single party in charge. CoRChain lets participants in a transaction achieve real-time reconciliation of validated, authenticated, and timestamped transactions without the cost, aggravation, and risk of relying on intermediaries.
CoRChain provides meaningful value because it is maintained by the consensus of the commit process between multiple nodes controlled by transaction participants, each with common yet different interests. It prevents individual participants or small groups from corrupting or deleting past transactions. CoRChain includes databases secured against internet tampering.

[0065] CoRChain and its mutual distributed ledger are designed to fit in the CoR.io e-wallet on a smart device, such as a consumer's (wallet owner's) smartphone.
The CoR.io e-wallet stores hashed validated identity credentials, hashed transactions, and Page 14 of 59 Date Regue/Date Received 2022-09-21 one or more hashed CoRTokens. The blockchain embedded on the smart device with the wallet owner's transactions gives the owner offline access to the data stored on the distributed ledger. In addition, it provides an extra layer of security to keep identity credentials, personal information, and token-based assets safe and secure.
The third-party and/or government validated identity credentials reside on the smartphone or similar device, and the CoRToken resides on the blockchain/ledger.

[0066] In some embodiments herein, the CoR.io blockchain and distributed ledger, called "CoRChain," can be compared to a "Title Office" such as that used for recording real estate deeds and similar documents. In essence, the Title Office is designed to ensure that the ownership of a particular asset is securely and immutably recorded, requiring the consent and participation of the owner of an asset to transfer ownership to another. The technology ensures that an asset cannot be "doubly transferred."

[0067] In particular, the CoR.io cloud server acts as the Title Office, transferring assets and recording the ownership of the new asset owner on the blockchain/ledger.
It also stores all transactions conducted on the CoRChain network.

[0068] The technology is agnostic to the nature of the assets themselves. The assets can be documents stored in an open format, encrypted documents, tokens representing assets or value, or even one-way hashes of original material. The latter can be used to ensure that the asset's chain of ownership is immutably preserved while also ensuring that only the owner/possessor of the original information can know the nature of the original information. This capability is essential for CoR.io's self-sovereign-identity management solutions.

[0069] While an individual with sufficient knowledge and experience in highly technical cryptography and identity management processes would be able to infer the usefulness of the blockchain technology, it would not be immediately obvious to a "casual"
observer.

[0070] CoR.io's Mutual Distributed Ledger

[0071] Mutual distributed ledgers (MDLs) utilize blockchain technology. MDLs are unalterable registers that allow groups of people to validate, record, and track a given transaction across a network of decentralized computer systems involved in the transaction. In this description, a mutual distributed ledger may simply be referred to as Page 15 of 59 Date Regue/Date Received 2022-09-21 a "distributed ledger." A distributed ledger, often known as a blockchain, is a computer data structure.

[0072] Blockchains are shared across organizations and individuals participating in a given transaction, including CoR.io as the administrator of the token management system. As for being distributed, blockchains are inherently multi-locational data structures. Each blockchain user keeps their copy of the blockchain on their mobile device, thus providing resilience and robustness. Blockchains and distributed ledgers are immutable. Once a transaction is written, it cannot be erased.
Furthermore, because there are multiple copies of the ledger, the ledger's integrity can be easily proven.

[0073] Unlike some blockchain technologies, the CoR.io relying party wallet, located at various relying parties, does not save all the transactions on the blockchain between relying parties and users. Instead, the wallet located at a given relying party's location only stores on the blockchain transactions that concern the relying party and all others involved in a particular transaction. For example, a retailer's wallet stores the transactions involving a particular purchaser (CoRWallet owner). For each such transaction, the wallet also stores all associated transactions involving a financial institution, a shipping company, and a payment processor, which are also involved in the transaction.

[0074] Each consumer's CoRWallet stores on CoRChain only those transactions that involve the consumer. Each retailer's server-based CoRWallet stores on CoRChain only those transactions that involve the retailer. Similarly, CoRWallet's servers used by other entities involved in transactions store only the part(s) of the transaction involving the particular entity. In comparison, the CoR.io administrator, a document signing coordinator server (see below), and a referee server (if applicable, see below) store all parts of the transactions of all the parties involved in the transactions. In other words, the CoR.io administrator, the document signing coordinator server, and the referee server store every transaction conducted on the CoR.io network.

[0075] For example, a Title Office used by a relying party, e.g., a retailer involved in a transaction, can obtain details of a sale from the retailer's transaction server. Such Page 16 of 59 Date Regue/Date Received 2022-09-21 details include items purchased, taxes paid, rewards points issued, gift card balances used, and e-prepaid card balances.

[0076] The retailer's server sends a copy of the transaction to the purchaser (CoRWallet owner). Once the purchaser confirms the transaction on their CoRWallet, a copy of the confirmed transaction is sent back to the retailer. Proof of the existence of the transaction and or the hashed transaction is placed on the blockchain, including the blockchain in the wallet owner's smart device. Other participants in the transaction receive elements of the raw transaction data depending upon their need to satisfy legal and corporate requirements. The CoR.io blockchain server retains all hashed/encrypted elements of the transaction, but it does not receive nor store the raw transaction data.

[0077] The transaction in raw data format is retained by the retailer and the purchaser.
In addition, other entities involved in the transaction are forwarded the raw data concerning each entity. Each of these other entities' CoRWallet hashes/encrypts the transaction and stores the proof of the existence of the transaction and or hashed transaction data involving the entity on the blockchain. In contrast, each entity's transaction server retains the raw transaction data.

[0078] CoR.io's proof of existence refers to a specific document or object with an unalterable date and timestamp. The object can be an email or an electronic image, for example. It means that CoR.io can prove that a particular document or object, like an email, or image, existed at a specific point in time.

[0079] Furthermore, CoR.io provides proof of authenticity of a document or object. That is, proof that the document or object has not changed since it was stored at the indicated specific point in time. This is accomplished by digitally signing the document or object and thus creating a hash of the digitally signed document, the hash being the document's unique digital identifier. The identifier is then stored on CoRChain's distributed ledger, and the transaction having the document or object is_timestamped.
Since every entry in the blockchain is immutable, this means that CoR.io has proof that the specific document or object in its form as recorded on the blockchain existed at the specific point in time.
Page 17 of 59 Date Regue/Date Received 2022-09-21

[0080] CorWallet is a digital, blockchain-based electronic wallet that uses an internally generated unique multi-factor tokenization process. CoRWallet resides in a smart device and operates on a CoR.io platform, which uses blockchain technology. A
smart device, for example, can be a smartphone, a tablet, a PC, or any device with a computing system.

[0081] A node of CoRChain is embedded in CoRWallet, giving it strong security and its owner greater privacy. Upon enrolling in CoRWallet, the owner embeds their self-asserted identity and photo ID credentials in CoRWallet. Typically, this is done using a camera of the owner's device. The information is encrypted and stored in the personal data store in a secure element or enclave of the wallet owner's device. The information is sent to a CoR.io partner for identity verification (photo-ID, Know Your Customer, and AML). The proof of the existence of the identity verification performed by the CoR.io partner is hashed and stored on the blockchain, including the blockchain in the wallet owner's device. This is done for future validation by an entity with whom the wallet owner is transacting at that point in time. CoR.io does not store any identity or identity credential information, as such information is in possession of the wallet owner who decides whom to share it with. Up to four levels of user authentication are available for the wallet owner to employ to gain access to the personal data store of their device.
These levels range from device-only authentication, password-based authentication, passwordless authentication, one-time-password-based authentication, and dual-biometric authentication. Dual biometric authentication combats biometric forgery by using the results of two different biometrics to authenticate a CoRWallet owner.
CorWallet and its platform offer a programmable cryptographic token as a store of value, which can represent, for example, e-signatures, e-prescriptions, loyalty points, e-prepaid cards, e-gift cards, digital currency, fiat currency, a ticket to an event, a building, and so on.

[0082] Digital Tokens

[0083] CoRToken is designed to augment the growth of great products by building upon the network ownership effect. Digital tokens are sometimes also referred to as crypto tokens, utility tokens, security tokens, digital coins, or often simply "tokens" or "coins."
Page 18 of 59 Date Regue/Date Received 2022-09-21

[0084] A digital token represents value or rights offered and sold to facilitate access to, participation in, or development of a distributed ledger, blockchain, or other digital data structure.

[0085] People carry out online business and social transactions, and people are known by their identities. Therefore, identities are a critical component of online business and social interaction.

[0086] An individual's identity is defined by a collection of attributes including, but not limited to, name, age, address, identity and financial credentials, work history, and social history. These attributes work together dynamically to define an individual.

[0087] Identity data in today's world is typically decentralized. For example, the Virginia Department of Motor Vehicles issues driver's licenses, the U.S. Department of Homeland Security issues passports, and banks issue banking credentials based on third-party validated identities. This makes identity management and identity verification cumbersome and costly for enterprises, governments, and retailers.

[0088] It takes little more than one click to buy an airline ticket or a new sweater. Still, it takes time to buy stocks or get a mortgage because verifying identity is a critical component of buying stocks or obtaining a mortgage online or in-person.
Whether it is waiting for documents or settlement, many types of transactions are not instant. In addition, assets like gold, real estate, fine art, or carbon credits are more difficult to transfer, often obligating buyers and sellers to contend with mountains of paperwork and lengthy procedures. By representing assets as digital tokens on a distributed ledger and blockchain, it is possible to unlock the value of real-world assets and exchange them in real time.

[0089] Digitization of assets is a process in which the rights to an asset are converted into a digital token on a blockchain. Ownership rights are transmitted and transferred or traded on a digital platform, and real-world and digital assets on the blockchain are represented by digital tokens.

[0090] In an embodiment of the present invention, digital tokens are created as part of the CoR.io platform built on CoRChain. The CoRToken resides on CoRChain, located on the administrator's computing device and users' mobile devices.
Page 19 of 59 Date Regue/Date Received 2022-09-21

[0091] An asset's economic definition is a resource with an economic value controlled by an individual, a legal entity, or a country. The legal definition of an asset is anything with a monetary value attached to it. Ownership right is a legal right to possession of a thing, including all usage rights (physical and intellectual).

[0092] CoR.io Digital Token ¨ Properties

[0093] 1) CoR.io's digital tokens are programmable. Programmable means that they run on software protocols composed of smart code that outline the features and functions of the token and the network's rules of engagement.

[0094] 2) CoRToken can be transferable or non-transferable or have restricted transferability. Depending on the application, unique (non-fungible) tokens can be transferable or non-transferable. For example, a plane ticket might be transferable or non-transferable, depending on the type of ticket purchased. In contrast, a piece of art, or the registration paper of your car, is unique but transferable. Identity-bound tokens like certificates or licenses are usually non-transferable.

[0095] 3) Expiration date - Any fungible token might be programmed by the token issuer in a way such that it expires after a certain date. Practically speaking, the token would expire. However, technically speaking, the token would change state.

[0096] 4) If tokens represent assets, they act as a passive payload managed by a distributed ledger, including all properties, rights, and obligations in the system. Asset-backed tokens can be (I) fungible or (II) non-fungible. Fungible tokens represent ownership of any fungible physical goods like money, silver, petrol, gold, diamonds, shares in a company, or any collateralized debt instrument. They could be compared to commodity money and are sometimes referred to as crypto commodities. Asset-backed tokens can also be unique and therefore non-fungible. Some refer to them as crypto goods. Examples are real estate tokens, crypto-collectibles, or tokens representing unique pieces of art. Representing such assets with a token makes the asset more easily tradable and divisible, thus creating more liquidity for some assets that might not have been easily tradable off-chain. Tokens can also represent access rights that are limited in time or in the scope of using an asset someone else owns or a service someone else provides. They can provide access to network services, an entry ticket to a concert, a public transport ticket, apartment sharing access, car-sharing access, a Page 20 of 59 Date Regue/Date Received 2022-09-21 time slot for a doctor's appointment, or membership access to a club, to name a few examples. They could be used to allow you to start your car, which might have a smart lock; access alcoholic beverages by proving that you are above a certain age;
board an airplane; enter your home; vote; cross a border; collect a tax refund; or get a discount.

[0097] 5) Fungible Non-Fungible Tokens (FNFT). Token issuers can issue an FNFT
in which the financial value of the CoR.io digital token is preset into a number of portions predetermined at the time of issuance.

[0098] 6) Redeemable ¨ The CoR.io token can be redeemable or non-redeemable.
Exactly one digital token can be equal to one unit of a good or service delivered or provided by the issuer of the digital token. Redeeming a digital token for the underlying good or service can cause the digital token to be destroyed. However, a digital token, after re-programming, can also be reused.

[0099] 7) Divisible ¨ The CoR.io digital token is divisible to an unlimited number of decimal places. The default is 18 digits, but the digital token's divisibility can be set to one digit, eighteen digits, and even 0 digits.

[0100] 8) Fixed Price ¨ In an embodiment of the present invention, the CoR.io digital token is pegged to the value of the country's currency or bank-issued currency from where it was issued. In this embodiment, a CoRWallet owner may hold a CoR.io digital token with the asset component representing, for example, US$100. Suppose the CoRWallet owner is in Canada and redeems the digital token at an entity located in Canada. In that case, the entity accepting the token for redemption or for the purchase of goods or services pays the equivalent of US$100 in Canadian dollars, based on the value of the US dollar at the time of redemption. The digital token works with entities that use the CoR.io network and CoRWallet owners, no matter where such entities are geographically located. A change in the value of a fixed price digital token on the positive or negative side can occur due to fluctuations in currency market exchange rates between the time a token owner becomes the owner of the digital token and the time when the token owner redeems the digital token. The token owner absorbs a change in the value of a fixed price digital token, be it a relying party or a CoRWallet owner. The token is issued by a relying party such as a retailer and redeemed by the same retailer or a financial institution associated with the token issuer.
Page 21 of 59 Date Regue/Date Received 2022-09-21

[0101] 9) Digital Identity Token ¨ In an embodiment of the present invention, the CoR.io digital token is used to represent the validated digital identity of a CoRWallet owner. The creation of a digital identity token representing the validated digital identity of a CoRWallet owner typically occurs as follows.

[0102] An identity validator is a government agency service provider. For example, a wallet owner is typically a consumer of goods and services. The identity validator validates the wallet owner's personal information, photo-ID credentials, and an image of the wallet owner captured at the time of wallet enrolment. Such validation can take place at the premises of the identity validator, with the wallet owner attending in person.

[0103] The identity validator digitally signs a timestamped digital statement.
Such a signed statement constitutes evidence that the identity validator has validated the wallet owner's identity, including the wallet owner's identity credentials. The wallet owner then creates a digital identity token using their CoRWallet and incorporates the digital statement as an asset in the payload of the digital identity token. The digital identity token thus represents the validated digital identity of the wallet owner. The wallet owner then stores the digital identity token on the blockchain. The digital identity token contains the digital statement but does not contain the wallet owner's identity credential&

[0104] Thus, proof of the existence of a validated identity, including proof of the existence of validating information such as photo-ID credentials, resides on the CoR.io token that resides on the CoR.io blockchain. In another iteration of the invention, the validated identity and the validated photo-ID credentials reside on the CoR.io token, which resides on the blockchain.

[0105] An authorized relying party involved in a transaction with the wallet owner can confirm the identity of the wallet owner by digitally confirming the proof of the existence of the identity which resides in the digital identity token. In the event the relying party still needs further confirmation of the CoRWallet owner's identity, the relying party can request the wallet owner to provide one or more identity credentials, or part thereof, residing in the wallet owner's CoRWallet. Alternatively, the relying party can seek Page 22 of 59 Date Regue/Date Received 2022-09-21 identity credentials from one or more identity validators. If an identity validator has a service of confirming its issuance of validated identity, the relying party can duly obtain the needed identity credentials.

[0106] In one forthcoming example, the Province of Ontario in Canada proposes to issue strong digital identity credentials in 2022, using in-person identity validation procedures. Each of these digital identity credentials can reside in a CoRWallet owner's CoRToken, which resides on the CoR.io blockchain, including the blockchain in CoRWallet. The Ontario digital identity credential certifies that the wallet owner is who they claim to be. An authorized relying party with a CoRWallet can verify the wallet owner's identity by checking the Ontario digital identity credential in the CoR.io token on the CoR.io blockchain.

[0107] While CoR.io's digital token can hold exchangeable assets and value, it can also be configured to represent physical assets and digital assets or a particular utility or service. For instance, certain crypto tokens represent tangible assets such as real estate and art and intangible assets such as processing power and data storage space.
Tokens can also be used as a governance mechanism for voting on elections and for specific parameters like protocol upgrades and other decisions that dictate the future direction of various projects.

[0108] Digital Signatures

[0109] A digital signature is a mathematical technique used to validate the authenticity and integrity of a message, software, or digital document. It is the digital equivalent of a handwritten signature or stamped seal, but it offers more inherent security. A
digital signature is intended to solve the problem of tampering and impersonation in digital communications. Digital signatures can provide evidence of origin and identity and the status of electronic documents, transactions, and digital messages. Signers can also use them to acknowledge informed consent. In many countries, including the United States, digital signatures are considered legally binding in the same way as traditional handwritten document signatures.

[0110] Unlike traditional e-signing systems, CoR.io does not store digital signatures inside a document or object. Rather, digital signatures stored on the CoR.io_blockchain Page 23 of 59 Date Regue/Date Received 2022-09-21 reside independently of a document or object to which the signatures have been applied. Unlike existing e-signature systems, there is no need for a central certificate authority or central timestamping server. Furthermore, with conventional electronic signature software, for an individual to check whether a document was electronically signed, the individual would have full read access to all the document's content. The CoR.io system does not require such full read access.

[0111] Because documents on CoRChain are not changed by electronic signatures, this enables multiple signees to sign respective copies of a document in parallel at around the same time. This can make remote signings of a document quick and efficient.

[0112] Overall, CoRChain establishes an audit trail that can be verified by authorized third parties, providing transparency, compliance, and trust.

[0113] CoR.io's Electronic Signature

[0114] Research shows that paper documents are on their way out, and e-signatures are replacing wet and digital signatures on e-documents. Wet signatures are ink-based signatures, while digital signatures are mathematical schemes for validating the authenticity of individuals and digital messages or documents. An e-signature refers to data in electronic form, which is logically associated with other electronic data and is used by an authenticated signatory to sign a document or transaction. An electronic signature can also be described as any electronic symbol, process, or sound associated with a document such as a record or a contract, where the document was electronically signed by the party involved.

[0115] CoRSig is the name of CoR.io's electronic signature system. CoRSig improves e-signatures beyond digital and advanced e-signatures by utilizing a programmable digital token (CoRToken) that resides on CoRWallet's blockchain (CoRChain) and tokenizes e-signatures.

[0116] CoR.io's electronic signatures play a significant role in guaranteeing the integrality, privacy, and non-repudiation of documents. Each such electronic signature also links the validated and authenticated identity of the signee to the e-signature and the document. Proof of the wallet owner's (user's) identity and proof of the existence of the electronic signature and or the electronic signature and the document to which the Page 24 of 59 Date Regue/Date Received 2022-09-21 electronic signature is attached is stored on the CoR.io digital token, which resides on CoRChain.

[0117] Proof of authenticity asserts that a document is authentic, i.e., it has not changed since it was stored at the indicated instant. This is accomplished by digitally signing an object and thus creating a hash, which is a digitally signed object's unique digital identifier. The identifier gets stored on CoRChain's distributed ledger, and the transaction gets timestamped. Since every entry in the blockchain is immutable, permanent proof that this specific object existed at a certain point in time is always available.

[0118] CoR.io's electronic signature establishes that the signee is the person who signed the document, which becomes legally binding once all parties have digitally signed it.

[0119] In summary, CoRChain records digital transactions on its distributed ledger.
Therefore, it is an appropriate platform for preserving digital signatures and key pairs.
Common recordation infrastructures use digital certificates issued by certification authorities to assert the authentication of digital signatures and key pairs.
The blockchain hash functions of CoRChain, initiated by a biometrically authenticated user with bound identity, replace third-party digital certificates used by conventional electronic signature systems. Thus, CoRChain provides better security and privacy.

[0120] Identity Validation and Verification

[0121] This application relies on U.S. patent application no. 16,218,385 (now US Patent 11,139,976), US Patent 11,171,781 and US Patent 10,171,476 for features relating to an e-wallet, digital onboarding, validating identity and identity credentials, identity credential storage on the blockchain, validation, authentication, and verification.

[0122] Data Diodes and Unidirectional Network

[0123] A data diode is a network component device that only allows data to flow through the device in one direction. It is named in analogy to the electronic diode circuit component that allows current to flow in one direction only.

[0124] Data diodes are used to segregate networks. Data diodes are critical components of the most secure "cross-domain solutions," where combinations of one-Page 25 of 59 Date Regue/Date Received 2022-09-21 way flow control and careful content inspection are used to ensure malware cannot cross the boundary from an untrusted to a trusted network.

[0125] A unidirectional network (also referred to as a unidirectional gateway or data diode) is a network appliance or device that allows data to travel in only one direction.
Data diodes can be found most commonly in high-security environments, such as defense, where they serve as connections between two or more networks of differing security classifications. Given the rise of industrial loT and digitization, data diode technology can now be found at the industrial control level for such facilities as nuclear power plants, power generation, and safety-critical systems like railway networks.

[0126] Originally, data diodes were merely network appliances or devices allowing raw data to travel only in one direction. They have been used in guaranteeing information security and protection of critical digital systems, such as industrial control systems, from inbound cyberattacks. After years of development, data diodes have evolved to be, for example, combinations of hardware and software running in proxy computers in the source and destination networks. The hardware enforces physical unidirectionality, and the software replicates databases and emulates protocol servers to handle bi-directional communication. Data diodes are now capable of transferring multiple protocols and data types simultaneously. A typical data diode contains a broader range of cybersecurity features like secure boot, certificate management, data integrity, forward error correction, and secure communication via Transport Layer Security. A unique characteristic is that data is transferred deterministically (to predetermined locations) with a protocol "break" that allows the data to be transferred through the data diode.

[0127] One-Time Pad Encryption

[0128] The one-time pad is an encryption technique that cannot be cracked in cryptography. However, the technique requires a single-use pre-shared key that is no smaller than the message being sent. In this technique, a plaintext is paired with a random secret key (also referred to as a one-time pad). Then, each bit or character of the plaintext is encrypted by combining it with the corresponding bit or character from the one-time pad using modular addition.

[0129] Fractals Page 26 of 59 Date Regue/Date Received 2022-09-21

[0130] The generation of a fractal image is disclosed in US Pat. App. No.
14/958,267 (Pat. App. Pub. No. US 2016/0210621 Al). In addition, a detailed description of principles and methods involving the generation of a fractal is provided below.

[0131] A fractal image is a geometric image that follows a precise mathematical algorithm, wherein the geometric image exhibits a repeating pattern that displays at a large range of scales. Fractal images are self-similar patterns that are nearly the same at every scale, making every part of the fractal image characteristic of the whole.

[0132] Fractal images can be either deterministic or stochastic (random) or a combination of the two. If a combination of the two, some parts of the fractal image are deterministic and some stochastic. The fractal image is generated using a fractal generation process that is both deterministic and stochastic.

[0133] Fractal images can be generated and used as unique identifiers for ID
documents, either solely or in combination with other data. Such data may include data embedded within the fractal image at its generation. In one example, the data is embedded into only a predetermined portion of the fractal image.

[0134] In one aspect of the present invention, verifying an electronic transaction includes providing a fractal image as part of the electronic transaction wherein data is embedded within the fractal image. Such data typically includes a predetermined portion of the electronic transaction.

[0135] Further, a random component can be incorporated into a fractal image, rendering reproduction of the fractal image mathematically impossible.

[0136] Data embedded in a fractal image can be encrypted data. For example, data to be embedded may be encrypted using a hash function from the Secure Hash Algorithm 2 (SHA2) family; whereupon a fractal image is generated, for example, via an Integrated Function System (IFS). The hashed data is then hidden within the fractal image using a methodology such as chaos theory and applied through a process such as a generalized Fibonacci sequence. Subsequently, the encrypted and hidden data may be extracted through a reverse process applied to a scanned image of the fractal image.
The hashed value is extracted through a hashing algorithm applied to the scanned data to separate the hashed value from the fractal image data.

[0137] In one application of a data embedded fractal image, biometric data is established for embedding within the fractal image. In one exemplary process, biometric data such as a fingerprint is converted into digital data for embedding within the fractal Page 27 of 59 Date Regue/Date Received 2022-09-21 image during a process of generating the fractal image. The fingerprint is initially processed to establish minutia points upon the fingerprint, these being the locations of major features of the fingerprint ridges such as ridge endings, bifurcation, and short ridges (or dots). The minutia points are then used to generate a minutia map, which is converted to digital data stored in a data file. As is or encrypted, this digital data is then embedded into the fractal image during the fractal image generation.

[0138] An exemplary process flow for embedding data within a fractal image according to an embodiment of the present invention is summarized as follows. Within a first sub-flow, the data to be embedded is acquired and encrypted. The fractal image is established within a second sub-flow and generates data acquired. The second sub-flow includes selecting a fractal type; establishing an IFS for the fractal type selected, and retrieving affine transformation coefficients for generating the fractal image.

[0139] In the above-described process flow, the embedded hashed value is not added to the fractal image once generated but rather merged during the generation of the fractal image. In this manner, the resulting combined image is immune to many common stenographic algorithms typically employed to extract data hidden conventionally via stenographic techniques. It would be evident that an SHA-2 cryptographic hash is a one-way function in that it cannot be decrypted back.
This makes the SHA-2 cryptographic hash particularly suitable for anti-tampering and digital signatures. A hashed value retrieved from the fractal image may be compared to a second hash value obtained from a separate source.

[0140] Fractal images allow embodiments of the present invention to take full advantage of the ability to use well-defined mathematical algorithms that exhibit repeating patterns at multiple scales and can be combined with deterministic and stochastic characteristics. For this reason, a fractal image can be generated and used as a unique identifier of an ID document such as an e-signature.

[0141] It would be evident to one skilled in the art that the fractal image techniques according to embodiments of the present invention support the evolution of all-digital ID
documents. The fractal image variable security pattern concepts solve the problem of Page 28 of 59 Date Regue/Date Received 2022-09-21 making a unique, valid digital document available on mobile devices. This is because the fractal image can be easily displayed upon a PED's display and captured through a camera or other image capturing device. Still, the visual camera-friendly security feature cannot be reverse engineered.

[0142] As noted above, encrypted or not, digital data can be encoded into the fractal image during its generation for subsequent extraction. However, it would also be evident that stenographic techniques may also be applied to add digital data, encrypted or not, to a fractal image after its generation. While not as secure as embedding during fractal generation, stenographic techniques can be beneficial in some instances.

[0143] Exemplary embodiments of systems and methods for providing secure tokenized assets having electronic signatures coupled with validated identity credentials will now be described.

[0144] Referring to Figures 1 and 3, Digital Tokens 601 reside on CoRChain as well as in an individual CorWallet (e-Wallet) of a given Smart Device 800. In general, each Digital Token 601 is typically a holder of assets. Such assets can, for example, be identity, identity and financial credentials, rewards points, gift cards, pre-prepaid card values, e-coupons, electronic signatures, real estate, artwork, tickets to events, etc.
Each Digital Token 601 typically includes a Token ID 611, an Identity Component 612, and an optional Payload (Asset Component) 613.

[0145] The Token ID 611 can be used to track the history of a particular token on the blockchain. As the token changes owners, or as it is updated by the current owner, the primary portion of the Token ID 611 never changes; only a sequence number increments with each new posting to the blockchain.
The Identity Component 612 is a hashed representation of the owner's identity, an identity that has been validated by a trusted third party. To prove ownership of a Digital Token 601, its owner can present the raw identity information and the name of the third-party validator or identity issuer to a requestor. The requestor can hash these two pieces of information together and verify that the Identity Component 612 on the token matches the hash they produce.
Page 29 of 59 Date Regue/Date Received 2022-09-21

[0146] The Payload 613 may consist of almost any digital information.
Depending on the particular application, it may be encrypted, hashed, or stored in its original form. The Payload 613 can be a digital document or a digital representation of a title deed to a physical asset. Digital Tokens 601 can be initially created with parameters that prohibit any modification to the Payload 613. Alternatively, Digital Tokens 601 may permit additions to the original Payload 613 (e.g., multiple e-signers of a document) or may permit changes to an asset of the Payload 613 itself (e.g., reducing the currency value of a digital debit card or rewards points).

[0147] When Payload 613 includes identity attributes of the owner of the Digital Token 601, The owner has the ability to decide which of the identity attributes can or should be shared with others. This is outlined in more detail below in relation to specific examples.

[0148] In some embodiments, an image is used with the token for display and additional encryption processes. The image may, for example, be a fractal or an image of a company's prepaid or gift card. The image can also indicate, among other things, the issue value of the card or a retained value on the card.

[0149] Referring to Figure 2, this schematically depicts two different types of administrator servers of a token management system, according to two embodiments of the present invention. In this description, the administrator is called CoR.io.

[0150] In the first type of administrator server, at the server-side "nodes"
of CoR.io, CoRChain relies on unidirectional "air-gapped" networking hardware to isolate the "ledger of record" from potential cyberattack threats. Communication with this air gap employs one-time-pad encryption technology for maximum cyber threat avoidance and high-speed performance. As illustrated, an Air Gap Server 710 includes an Isolated Server 711 and a Web Server 712. The Servers 710, 711 are interconnected by a Data Diode 713 that allows transmission of data from the Web Server 712 to the Isolated Server 711, and by a Data Diode 714 that allows transmission of data from the Isolated Server 711 to the Web Server 712. The Web Server 712 is connected to a Network 715, such as the internet with full mesh connectivity.

[0151] Alternatively, as illustrated, a Non-Isolated Server 720 of CoR.io is connected to a Network 725, such as the internet with full mesh connectivity.
Page 30 of 59 Date Regue/Date Received 2022-09-21

[0152] Referring to Figure 3, this schematically depicts network connectivity of major participants of an exemplary token management system according to the present invention. The server-side "nodes" of CoR.io are shown as at least one CoR.io Cloud Gateway 810. Each CoR.io Cloud Gateway 810 includes a plurality of air gap servers.
Two air gap servers, 811 and 812, are illustrated. Each air gap server 811, 812 is independently connected to the internet 840, having full-mesh connectivity.

[0153] In the exemplary token management system, there is also at least one Gateway Referee 820. Each Gateway Referee 820 includes an air gap server. Two air gap servers, 821 and 822, are illustrated.

[0154] In Figure 3, the Relying Parties 830 each have a server. In the illustration, there are two Relying Parties 830 who have Relying Party Servers 831, 832, respectively.
Furthermore, although not illustrated, certain Relying Parties 830 may employ an air gap server. Such an air gap server is configured in much the same way as the Air Gap Server 710 of Figure 2. The Relying Parties 830 that employ air gap servers may, for example, be government departments or agencies or other organizations.

[0155] In one embodiment utilizing the token management system, a digital token that can present specific identifying information to a requestor is created and stored. An e-Wallet owner wanting to create a digital token retrieves the identity information desired and identity validator/issuer information stored in the secure personal data store of their Smart Device 800. The owner can be described as an initiator. The owner hashes the identity information and identity validator/issuer information. Using code on the Smart Device 800, a unique set of "unlock keys" are also generated by the owner and stored in the personal data store. The result of the hash and the unlock keys are together referred to herein as "initiator information."

[0156] The initiator information is delivered by the initiator via the internet 840 to the Cloud Gateway 810 operated by the administrator of the token management system.
The Cloud Gateway 810 makes use of "air-gapped" connections to the Air Gap (secure) Servers 811, 812 to pass the initiator information along. Taking the Air Gap Server 811 as an example destination, it records the token on the blockchain. That is, the token is stored on the blockchain by the Air Gap Server 811. A copy of the token is sent via the Page 31 of 59 Date Regue/Date Received 2022-09-21 Cloud Gateway 810 and Internet 840 to the initiator at the Smart Device 800 and is stored on a blockchain in the Smart Device 800.

[0157] In another embodiment utilizing the token management system, a digital token that represents a digital asset in addition to providing proof of identity and ownership is created and stored. The process of creation is essentially the same as the above-described process of creating a digital token that can be used to present specific identifying information to a requestor. The main difference is that the information passed by the Smart Device 800 to the Internet 840 further includes the Payload 613 of the Digital Token 601. This information is included in the created token that is stored on the blockchain by the Air Gap Server 811. A copy of the stored token is sent to the Smart Device 800.

[0158] In another embodiment utilizing the token management system, a current owner of an asset-bearing digital token transfers ownership of the asset to another person.
The recipient can either be a Relying Party 830 or an owner of another Smart Device 800 (not shown). In the following description, it will be assumed that the recipient is an owner of another Smart Device 800.

[0159] The current owner of the token stored on the current owner's Smart Device 800 sends an image of the token to the recipient via the Internet 840. The current owner can be described as an initiator. In addition, the current owner sends the identity information needed to ensure that the initiator of the transaction is the current owner of the token and sends information regarding the third-party validator or issuer of the identity information. The recipient can use all this information to verify the originator's identity in much the same way as described above. The originator also sends the unlock keys that the recipient will need to create a new token instance.

[0160] Then the recipient hashes the received identity information and the information regarding the third-party validator/issuer in order to verify that the initiator is the current owner of the token. The recipient uses code on the recipient's Smart Device together with the unlock keys to generate a set of new unique unlock keys. The result of the hash, the original unlock keys, and the new unlock keys are together referred to herein as "recipient information."
Page 32 of 59 Date Regue/Date Received 2022-09-21

[0161] Next, the recipient communicates with the Cloud Gateway 810 via the internet 840 by passing along the recipient information provided (as well as any updates or changes to the payload as are appropriate - see below). Also passed along is the recipient's appropriate identity and identity validation information to enable the recipient to become the new asset owner. As before, all this information is passed to, for example, the Air Gap Server 811. The Air Gap Server 811 determines whether the received original unlock keys match the unlock keys currently on the blockchain and determines whether the original token is valid and correct. Assuming that both determinations are "yes," a new version of the token is created. In the new version of the token, the new owner's identity is recorded in the Identity Component 612, the Payload 613 remains unchanged, and the original Token ID 611 is maintained. A
copy of this new token, together with an image of the new token, is passed back to both the initiator and the recipient and stored on their local blockchains.

[0162] In one particular example of transfer of ownership of an asset-bearing digital token, when the asset is a document, the transfer of ownership of the digital token constitutes delivery of an electronic signature affixed to that document.

[0163] An alternative embodiment of a current owner of an asset-bearing digital token transferring ownership of the asset to another person will now be described.

[0164] The current owner of the digital token stored in a secure data store on the current owner's Smart Device 800 (first Smart Device 800) selects the digital token to be delivered to a recipient. The first Smart Device 800 sends first data to a second Smart Device 800 operated by the recipient. The first data includes original identity information used by the current token owner to secure ownership of the digital token, an indicator of the name and nature of an identity validator that digitally signed validation of the identity of the current token owner, information describing an item of value represented in the digital token, and an existing unlock key that was stored in a secure data store on the first Smart Device 800 when the current token owner secured ownership of the digital token.

[0165] The second Smart Device 800 sends second data to the Air Gap Server 811 operated by an administrator of a token management system, the second data comprising the digital token.
Page 33 of 59 Date Regue/Date Received 2022-09-21

[0166] The Air Gap Server 811 verifies that the digital token supplied in the second data represents a valid digital token on a blockchain of the Air Gap Server 811.
Then the Air Gap Server 811 sends third data to the second Smart Device 800, acknowledging the validity of the digital token.

[0167] The second Smart Device 800 applies a hashing algorithm to a combination of digital identity components of the recipient and an indicator of a name and a nature of an identity validator of the recipient. The result of the hash is a new first portion of the digital token.

[0168] The second Smart Device 800 combines the new first portion and an original second portion of the digital token to form a new digital token, the second portion being the representation of the item of value contained in the digital token. Then the second Smart Device 800 uses the new digital token to generate a proposed new token image.
The second Smart Device 800 also calculates a new, unique unlock key, which indicates ownership of the new digital token by the recipient.

[0169] The second Smart Device 800 sends fourth data to the Air Gap Server 811, the fourth data including the proposed new token image, the current unlock key, and the new unlock key.

[0170] The Air Gap Server 811 verifies whether the current unlock key is valid. In the event that the current unlock key is verified as valid, the Air Gap Server 811 creates a new token image on the blockchain. The new token image includes an identifier of the digital token and a sequence number indicating a new owner of the digital token.

[0171] The Air Gap Server 811 sends fifth data to the second Smart Device 800, acknowledging the new token image on the blockchain.

[0172] The second Smart Device 800 sends sixth data to the first Smart Device 800, the sixth data including the new token image.

[0173] The first Smart Device 800 stores the new token image in the secure datastore on the first Smart Device 800.
Page 34 of 59 Date Regue/Date Received 2022-09-21

[0174] The second Smart Device 800 stores the new unlock key and the new token image in a secure data store on the second Smart Device 800.

[0175] An asset-bearing digital token can have many applications in commerce and elsewhere. For example, the asset can be a document such as a commercial contract.
The contract can be in electronic form and can be entered into by various parties electronically and remotely. This is done by utilizing electronic signatures affixed to the document in accordance with embodiments of the present invention. An example of preparation of such kind of electronic document, and permanent and unalterable recordation and storage of the document utilizing a digital token, will now be described in detail.

[0176] Referring to Figure 4, this shows an exemplary arrangement of participants using a system in accordance with certain embodiments of the present invention. The system includes CoR.io Air Gap Servers 1008, and a Blockchain 1006. In the illustration, the Air Gap Servers 1008 include a Document Signing Coordinator 1004, a Title Office 1005, and an Escrow 1007.

[0177] Each party participating in an electronic signature transaction using the system has a mobile, desktop, or server-based CoRWallet. Such parties can include persons, businesses, governments, retailers, and other organizations. In the illustration, there are three parties named Persons 1001, 1002, 1003. The electronic signature transaction can, for example, be the signing of a contract.

[0178] The Title Office 1005 also has a CoRWallet. The Title Office 1005 attaches digital titles to an electronic document, with the names of all persons, companies, organizations, retailers, and governments involved in an electronic signature transaction. A digital title indicates ownership of the document.

[0179] CoRWallet has built-in web browsers and apps, including an app for document signing called eSig. eSig is the app of CoRSig.

[0180] An electronic signature transaction is conducted using the eSig apps of all the parties.
Page 35 of 59 Date Regue/Date Received 2022-09-21

[0181] The Document Signing Coordinator 1004 functions as a point of connectivity where a group of signers such as Persons 1001, 1002, 1003 can coordinate their signing activity with reasonable automation. The Document Signing Coordinator facilitates the distribution of information and point-to-point connectivity between the CoRWallets of Persons 1001, 1002, 1003, and the Title Office 1005. The Document Signing Coordinator 1004 needs to communicate with the various other CoRWallets, and the CoRWallets of Persons 1001, 1002, 1003 need to communicate with the Title Office 1005. All communication between the Document Signing Coordinator 1004 and the CoRWallets of Persons 1001, 1002, 1003 is through the eSig apps. The Document Signing Coordinator 1004 may be, e.g., an escrow agent, a notary, a solicitor, a bank, a trustee, or a CoR.io entity.

[0182] In a typical electronic signature transaction, a document that has been agreed to as final by all the parties is digitally signed by all the parties. Each time a party digitally signs the document, such party adds their electronic signature to the document and simultaneously provides electronic third-party validated identity. Both the electronic signature and the validated identity are contained in a digital identity token having the document, and the digital identity token is then processed in the next stage of the electronic signature transaction, as detailed below. Thus, a digital signature performed by any given party is essentially a combination of their electronic signature and their validated identity.

[0183] In an exemplary electronic signature transaction, a document that has been agreed to as final by all the parties is digitally signed by all the parties a first time. To begin this process, a Digital Identity Token for the purposes of the electronic signature transaction is created. Typically, the Digital Identity Token is created by one of Persons 1001, 1002, 1003; for example, Person 1001. The Digital Identity Token is created by Person 1001 in an interchange between the mobile device of Person 1001 and the Title Office 1005. The mobile device has the capability of generating a one-time token in the interchange with Title Office 1005. A processer in the mobile device generates a one-time code, which in the interchange with the Title Office 1005 generates the Digital Identity Token. The Digital Identity Token incorporates the document to be signed.
Page 36 of 59 Date Regue/Date Received 2022-09-21 Thus, the document is a digital asset within the Digital Identity Token (see below). The Digital Identity Token resides on the Blockchain 1006.

[0184] Subsequently, the Title Office 1005 transfers ownership of the Digital Identity Token to the Document Signing Coordinator 1004. Then one or more servers of the Document Signing Coordinator 1004 facilitate the eSig apps to coordinate the gathering of all the e-signatures into a first master copy of the document containing all the e-signatures. Such a first master copy is also referred to herein as a "first bundle." In the following description, it will be assumed for convenience that the Document Signing Coordinator 1004 has only a single server.

[0185] The signed document in the form of the first master copy is then sent by the Document Signing Coordinator 1004 to the Title Office 1005. The first master copy is digitally non-repudiated for authenticity by Title Office 1005, digitally signed by Title Office 1005, and then identical copies of the non-repudiated document are sent to all the signees for their respective e-signatures a second time.

[0186] The signees then attach their e-signatures to the copies of the non-repudiated document. This ensures that all persons who are signatories to the document have e-signed the document to acknowledge that the already-signed first master copy is authentic. The signees then send the copies of the e-signed non-repudiated document back to Title Office 1005 via their respective eSig apps.

[0187] The Document Signing Coordinator 1004 compiles the signees' e-signatures attached to the copies of the non-repudiated document onto one master non-repudiated document. Such master non-repudiated document is also referred to herein as a "second bundle." The Document Signing Coordinator 1004 then sends the master non-repudiated document back to each signee. Once the master non-repudiated document is received by all the signees, each signee presses a confirmation button in the app, finalizing the transaction.

[0188] The master non-repudiated document is stored on the Document Signing Coordinator 1004. The master non-repudiated document is also sent to Title Office 1005 and placed on the Blockchain 1006 after hashing (see below). The master non-repudiated document may also be stored on the Escrow server 1007.
Page 37 of 59 Date Regue/Date Received 2022-09-21

[0189] Further, the master non-repudiated document is encrypted by the Title Office 1005, and the encrypted document is sent to and stored in each signee's computing device. The encrypted document is also stored on the Document Signing Coordinator 1004.

[0190] Thus the Title Office 1005 facilitates proof of ownership of the master non-repudiated document, which in turn facilitates proof of identity of the signees of the master non-repudiated document. Ultimately, each signee's CoRWallet is the authority;
Le., it has a copy of the master non-repudiated document.

[0191] Moreover, proof of the existence of the master non-repudiated document and or the document is stored on the CoR.io blockchain as described below.

[0192] Each signee's electronic (digital) signature embedded in the Digital Identity Token is digitally signed by the Title Office 1005. All the digital signatures provide proof that every party has signed the second master copy.

[0193] The master non-repudiated document is hashed by the Title Office 1005, and the hash value is stored in the Digital Identity Token. The Digital Identity Token resides on the Blockchain 1006, the blockchain in the Title Office 1005, the blockchain in the Document Signing Coordinator 1004, the blockchain in each signee's computing device, and optionally on the blockchain in the Escrow 1007. The Blockchain 1006 comprises blocks, each of which consists of one transaction. The blockchain in the CoRWallet of each signee's mobile device contains only the CoRWallet owner's transactions.

[0194] A detailed example of the Digital Identity Token stored on the Blockchain 1006 is described below in relation to Figure 8.

[0195] Thus each CoRWallet contains proof of the existence of the master non-repudiated document and or the master non-repudiated document.

[0196] Referring to Figure 5, shows electronic devices used to create a Digital Identity Token of the kind shown in Figure 1 and details of a person's e-signature stored in a Digital Identity Token 1104.

[0197] Mobile devices of various users each contain CoRWallet, and validated identity and validated photo-ID credentials of the user. The validated photo-ID
credentials include government-issued identity credentials.
Page 38 of 59 Date Regue/Date Received 2022-09-21

[0198] The Digital Identity Token 1104 (CoRToken) is generated by mobile devices such as a smartphone 1101, a laptop 1102, or a tablet 1103, in sync with the Title Office 1005 and other CoR.io systems. The Digital Identity Token 1104 contains proof of the existence of the wallet owner's validated identity and validated identity credentials and also contains the wallet owner's digital signature (e-signature).

[0199] The e-signature includes a fractal 1105 generated explicitly for the wallet owner.
Typically, the fractal 1105 replaces the wallet owner's wet signature. Further or alternatively, an electronic image 1106 of the wallet owner's wet signature can be included in the wallet owner's digital signature.

[0200] The e-signature also contains the wallet owner's photo image on the wallet owner's validated photo-ID credential (e.g., driver's license, passport, government-issued ID card) and the wallet owner's home or office address 1109. In the illustration, two photo images 1107, 1108 of two different validated photo-ID credentials are shown.

[0201] Optionally the e-signature can also include a corporate logo 1110 and a corporate seal 1111 of the wallet owner's employer, or a logo owned by the wallet owner if the wallet owner is self-employed.

[0202] Finally, the wallet owner can also optionally include a short video 1112, audio message 1113, and/or text message 1114 in the e-signature. The blockchain 1115 is also shown in Figure 5.

[0203] Figure 6 shows two electronic signatures 1201, 1202 being used in an exemplary transaction document. The electronic signatures 1201, 1202 are attached to a place in the document where signers would have signed their wet signatures.

[0204] The e-signatures 1201, 1202 are titled by the Title Office 1005 and hashed by the Title Office 1005. The hashed value constitutes proof of the signees' identities and identity credentials. Both the e-signatures 1201, 1202, and the hash value are also placed on the blockchain 1205.

[0205] Miniature versions 1203, 1204 of the signees' fractals are used as initials of the signees if needed.

[0206] Figure 7 shows a manual change to the document shown in Figure 6. A
process similar to the process described below in relation to Figure 9 is followed.
The manual Page 39 of 59 Date Regue/Date Received 2022-09-21 change 1301 is initialed in the margin by miniature versions 1302, 1303 of the signees' fractals. In the illustration, the foot of the page containing the manual change is also initialed in the margin by the miniature versions 1302, 1303.

[0207] Then a process similar to the process described below in relation to Figure 9 is once again followed to finalize the document and thus obtain the master non-repudiated document. The blockchain 1306 is also shown in Figure 7.

[0208] Non-repudiated documents

[0209] The following is a brief overview of the principle of non-repudiation in digital signatures.

[0210] Non-repudiation is achieved through cryptography, just like digital signatures;
and includes other services for authentication, auditing, and logging. In online transactions, digital signatures ensure that a party cannot later deny sending information or deny the authenticity of his/her signature.

[0211] As an illustration, denial can occur in agreements with relatively low watertightness, such as agreements signed with a wet signature. In such agreements, a signatory may subsequently claim that he never made a deal for some reason.
For example, the signatory may argue that the signature on the document was forged without his knowledge.

[0212] Denials like this can be prevented using the principle of non-repudiation. This can be achieved with technology and digital identity. Conventionally, the non-repudiation principle is contained in signatures and documents that have been legally registered for company purposes. The document is signed by the relevant parties, and witnesses are appointed to oversee the signing process.

[0213] The identities of the parties involved must be clearly stated to avoid misunderstanding in the future. Next, the authenticity of the parties involved must also be checked for correctness and legality. Evidence of identity concerning the parties involved is required. This is especially the case with digital signatures, which use encryption codes, wherein the codes are only owned by those who have permission.
Page 40 of 59 Date Regue/Date Received 2022-09-21

[0214] The non-repudiation principle can be applied using a number of technologies.
The most advanced method is through state-of-the-art technology such as HMAC
(hash-based message authentication code). HMAC, a sophisticated method, allows authentication and data integration through document hashing and transmission using a shared encryption key. Although it appears to be quite sophisticated, in practice, it is not so sophisticated where non-repudiation is concerned.

[0215] The most common attack on non-repudiation is the occurrence of objections due to incorrectly entered data in the log files. This, if left unchecked, leads to spoofing of a digital document and is liable to cause harm. Therefore, CoR.io stores the log files on an immutable digital ledger, CoRChain.

[0216] To prevent unwanted occurrences when dealing with digital documents, one should use digital signatures with a high level of non-repudiation in internet communication technology. The highest level of the non-repudiation principle is embodied in a digital certificate signed by a trusted authority. The hash value is encrypted using a private key owned by the trusted authority and stored on the blockchain.

[0217] Document senders can use the private key to encrypt the hash attached to the sent digital document. The recipient can then decrypt the digital signature using the public key. By looking at the match, the recipient can confirm who the message's sender is. Digital signatures ensure that the right person signed the document. In addition, since the digital signature can only be made by one person, the person in question cannot deny that they are the originator of the transmittal. Increasing security and identity integrity can also be done by implementing a biometric-based user identity verification protocol that ensures that personal data cannot be used by other parties.
That way, the integrity of the signed document can no longer be denied or "repudiated."

[0218] Figure 8 shows details of an exemplary Digital Identity Token 1400 stored on the CoR.io blockchain 1006 when an electronic signature transaction involving a non-repudiated document is underway or completed.
Page 41 of 59 Date Regue/Date Received 2022-09-21

[0219] The exemplary Digital Identity Token 1400 is specifically designed for Self-Sovereign-Identity (SSI) and includes a Token ID 1401, Identity Components 1402, and a Payload (Asset Component) 1403.

[0220] Token ID 1401 involves a process not immediately visible or obvious to wallet owners. Token ID 1401 gives a wallet owner control over their tokenization strategy, allowing them to utilize different types of digital services, including e-signatures. In addition, Token ID 1401 lets token issuers control e-signature tokenization.
That is, token issuers are able to build and manage their tokenization capabilities and deliver identity components for on-premise generated enriched e-signatures. Token ID

includes Links 1404.

[0221] Identity Components 1402 include Personal ID 1405, Civil ID 1406, Proof of Existence of Digital ID 1414 (also called "Digital ID 1414"), Identity Validation 1407, Decentralized Identifiers 1413, and Security Technologies 1408.

[0222] Payload 1403 includes on-premises generated e-Signatures 1409, a link to Document Non-Repudiation 1410 being e-signed or already fully e-signed, e-Prescriptions 1411, and Digital Assets 1412.

[0223] Links 1404 are various Title Offices and third-party providers such as third-party service providers.

[0224] Personal ID 1405 includes information not found in Civil ID 1406. Such information includes date and place of birth, father's and mother's name, current and past residential address, sex, height, weight, and marital status. Such information can also include financial card information.

[0225] Civil ID 1406 is the establishment of a unique identity of an individual through the verification, registration, management, and conservation of personal data.
Civil ID 1406 is usually used to identify or verify the identity of individuals when interacting with government bodies. However, Civil ID 1406 is increasingly being used for regulated private industries, such as in banking, for financial cards, mobile phone accounts, and more.
Page 42 of 59 Date Regue/Date Received 2022-09-21

[0226] In general, civil ID is used to identify or verify the identity of individuals when interacting with governments. It is the establishment of a unique identity of an individual through the verification, registration, management, and conservation of personal data by a government, business, or educational organization.

[0227] Civil ID can be a unique identity number, signature, photograph, or biometric data in addition to existing biographic data (such as those found in Personal ID 1405).
The goal is to establish a unique civil identity in the public sector space for each individual. The purpose of civil ID is for validation and authentication of citizen identities and permission to provide access to a benefit or service.

[0228] Some civil ID programs are identity management applications used by governments to verify a citizen and establish a link of trust, typically on a large scale. A
civil ID (sometimes in the form of a national ID or elD) is one means of identifying citizens, permanent residents, and temporary residents for work, taxation, government benefits, health care, and other government-related functions. For example, this can be for issuing official documents, managing borders, registering voters, or employment background checks. Another subset of civil ID is the biometric e-passport, a travel document with a computer chip.

[0229] Types of civil ID commonly issued include driver licenses, passports, health-related documents, and national ID cards.

[0230] Digital ID 1414 is an electronic way to verify who a person is online in a secure manner that offers data protection and safeguards personal information. The proof of the existence of validated Digital ID 1414 can be securely stored in a digital wallet app for smartphones and other digital devices (like tablets or computers) and on a blockchain. It allows people and businesses to prove who they are, both online and in person. The proof of the existence of validated Digital ID 1414 on a blockchain is a crucial element that enables the most effortless, most secure, and most privacy-compliant access to online government, business, and e-commerce services.

[0231] Identity Validation 1407 is where an individual's personal information, such as their name, address, phone number, email address, and government-issued photo-ID, Page 43 of 59 Date Regue/Date Received 2022-09-21 has been checked by commercial service providers and/or photo-ID issuers to confirm that they are valid and exist in the real world.

[0232] This process ensures that the individual is the person they claim to be. Many private service providers offer identity validations and Know Your Customer (KYC) services. Additionally, in 2022, the Province of Ontario in Canada intends to provide validated identity credentials to accredited identity services providers using government-issued digital identity credentials. These digital identity credentials will reside in an app on mobile devices for use online and in-person in a brick-and-mortar location.
In addition, four US states offer validated driver's licenses through a smartphone manufacturer.

[0233] Decentralized Identifiers (DID) 1413 enable a provable, decentralized digital identity without the need for a central registration agency. DIDs are grounded on the self-sovereign identity concept. DIDs identify entities (e.g., a person, organization, or thing) as decided by directors of the DIDs. DIDs are constructed to enable the directors to exercise control over them and be implemented independently of any centralized registry, identity provider, or certification authority. DIDs link a DID
entity with a DID
document, allowing dealings with that DID entity. Each DID document can express cryptographical information, validation methods, or service endpoints, which provide a set of processes enabling a DID director to prove control of the DID. DIDs are primarily used with blockchain and distributed ledger technology.

[0234] Security Technologies 1408 typically include but are not limited to digital signatures, public key infrastructure (PKI), public-key encryption, and the latest in encryption techniques.

[0235] As for e-Signatures 1409, the US Electronic Signatures in Global and National Commerce (ESIGN) Act granted electronic signatures the same legal status as handwritten signatures throughout the US. This has greatly simplified and expedited how organizations gather, track, and manage signatures and approvals on agreements and documents of all kinds. In the US Electronic Signatures in Global and National Commerce Act, an electronic signature is defined as "an electronic sound, symbol, or Page 44 of 59 Date Regue/Date Received 2022-09-21 process attached to or logically associated with a contract or other record executed or adopted by a person with the intent to sign the record."

[0236] CoRSig is CoR.io's e-sig nature service. CoRSig advances e-signatures beyond digital and advanced e-signatures by utilizing a programmable cryptographic token (CoRToken) that resides on CoRWallet's blockchain (CoRChain) and tokenizes e-signatures.

[0237] Whether a signature is paper-based or electronic, a signature links a person to a document (or transaction) and typically provides evidence of that person's intent to approve or be legally bound by its contents. The primary function of a signature is to provide evidence of the signatory's identity, intent to sign, and an agreement to be bound by the contents of the document. Advanced e-signatures meet US National Institute of Standards and Technology-Digital Signature Standard (NIST-DSS) and EU
electronic identification and trust services (eIDAS) regulations.

[0238] Electronic signatures play a significant role in guaranteeing documents' integrity, privacy, and non-repudiation. They also enable the validated (authenticated) identity of the signee to be bound to the e-signature and the e-document. In addition, CoRSig provides features such as fraud-proof e-signatures and non-repudiated e-documents, and instant document verification.

[0239] As for Document Non-Repudiation 1410, non-repudiation is the assurance that someone cannot deny the validity of something. Non-repudiation is a legal concept widely used in information security and refers to a service that provides proof of the origin of data and its integrity. Identity, strong authentication, digital signatures and certificates, public and private key infrastructure, and tokenization provide a non-repudiation guarantee about the authenticity of a document or message. A non-repudiated document assures that individuals who signed the document cannot deny the document's validity. Furthermore, sending parties cannot deny that they sent a non-repudiated document or message, and a receiving party cannot deny they received the non-repudiated document or message. In the exemplary electronic signature transaction described below in relation to Figure 9, the document is a contract being signed or already fully signed.
Page 45 of 59 Date Regue/Date Received 2022-09-21

[0240] [E]-Prescriptions 1411 is one class of digital assets relating to medical prescriptions. See also the following description about Digital Assets 1412.

[0241] As for Digital Assets 1412, a digital asset is digital or physical material owned by an individual, organization, or enterprise. Some digital assets include PDF
files, videos, presentations, audio files, images, spreadsheets, graphics, design files, spreadsheets, image files, cryptocurrency, e-gift cards, e-prepaid cards, e-vouchers, a ticket to an event, a building, a piece of art, and e-coupons. Digital assets are stored on digital appliances such as; personal computers, laptops, portable media players, tablets, and data storage devices. Digital assets can be added to the Digital Identity Token 1400, which binds them to e-Signatures 1409 and Document Non-Repudiation 1410.
Neither the sender nor the receiver of the e-signature with the attached digital asset can deny that the asset was sent or received. In one example, the photo on a CoRWallet owner's government-issued photo-ID credential (see ID Validation 1407), and the photo of the same CoRWallet owner captured when the CoRWallet owner enrolled in CoRWallet (see Security Technologies 1408), are embedded in the Payload 1403 displayed in the printed e-signature.

[0242] Referring to Figure 9, this is a flowchart of creating a final, valid non-repudiated document in accordance with one embodiment of the present invention.

[0243] In step 1501, an electronic document to be signed by plural parties (herein, "participants") arrives in a user's CoRWallet. Such a user is referred to herein as the "initiator." The initiator may or may not be one of the participants who is to sign the document.

[0244] In step 1502, the initiator uses the eSig app in their CoRWallet to create a Digital Identity Token containing an asset, the asset being a form of the document that can be utilized by the eSig app. In the following description, unless the context indicates otherwise, the Digital Identity Token containing the asset may simply be referred to as the "asset."
Page 46 of 59 Date Regue/Date Received 2022-09-21

[0245] In step 1503, the eSig app of the initiator registers ownership of the asset with the Title Office (see Figure 4). That is, the initiator is registered as the owner of the asset.

[0246] In step 1504, the eSig app of the Title Office transfers ownership of the asset to the Document Signing Coordinator (see Figure 4).

[0247] In step 1505, the eSig app of the Document Signing Coordinator creates new tokens, one for each intended signer, all with the identical document contents as the original token. The Document Signing Coordinator transfers the new tokens to the eSig apps of all the participants who are to sign the document (hereinafter, "signing parties"
or "signers"). The eSig app of each signing party notifies the signing party that there is a document to sign.

[0248] In step 1506, each signing party updates their token by appending an electronic signature to the token, using their eSig app. Each signing party then transfers the token back to the Document Signing Coordinator.

[0249] In step 1507, the Document Signing Coordinator takes possession of each returned token containing an electronic signature.

[0250] In step 1508, the Document Signing Coordinator waits until all of the signed tokens are received from the signing parties. The Document Signing Coordinator periodically sends reminders to the signing parties if and as necessary.

[0251] In step 1509, the Document Signing Coordinator creates a new token containing the document contents and all electronic signatures returned on the earlier tokens. The Document Signing Coordinator now has the first bundle of signed copies of the document with proof of who signed them in the bundle. The Document Signing Coordinator is the owner of the first bundle.

[0252] In step 1510, the Document Signing Coordinator creates identical copies of the token containing all signatures of the signers and transfers the copies to the signing parties.
Page 47 of 59 Date Regue/Date Received 2022-09-21

[0253] In step 1511, each signing party uses their eSig app to add his/her electronic signature to the token containing all prior signatures to indicate acknowledgment that all signing parties have signed the document.

[0254] In step 1512, each signing party transfers the token containing their electronic signature, which acknowledges prior signatures, to the Document Signing Coordinator.

[0255] In step 1513, the Document Signing Coordinator waits until all of the signed tokens are received from the signing parties. The Document Signing Coordinator periodically sends reminders to the signing parties if and as necessary.

[0256] In step 1514, the Document Signing Coordinator creates a new token containing all the signed copies of the tokens received. The Document Signing Coordinator now has a second bundle containing proof that all the signing parties agree that the document has been signed by all the signing parties. The Document Signing Coordinator is the owner of the second bundle.

[0257] In step 1515, signing of the document twice by all the signing parties is thus completed.

[0258] If agreed changes need to be made to the document, a process similar to the above-described process is followed to obtain signed or initialed changes to the document.

[0259] In medical prescriptions, CoR.io provides e-prescription software suitable for the patient, the doctor, and the commercial marketplace. The CoR.io e-prescription system enables doctors to electronically generate and send a prescription to a patient through CoRWallet. E-prescribing software eliminates faxed prescriptions and significantly reduces paper and data entry and dosage errors. It enhances patient safety, simplifies the medication supply workflow, and increases patient satisfaction. E-prescribing software results in a significant reduction in paper prescriptions; a decrease in the number of unfilled prescriptions; an improvement in the documentation of patient medication; and a stronger relationship between medical practices and pharmacies.
With e-prescription software, the prescribing doctor and payer know immediately when Page 48 of 59 Date Regue/Date Received 2022-09-21 the prescription is picked up or a lab requisition completed. E-prescription software can be used by health care professionals, patients, pharmacists, labs, hospitals, and other medical service providers. E-prescriptions also help keep accurate records of patients' prescription medicine picked up. E-prescriptions prevent or avoid unwanted inter-medicine interactions, which can occur, for example, when different doctors prescribe the same medication to the same patient for the same illness. In addition to reducing errors that may cause harm to patients, the e-prescription system reduces costs. For example, the e-prescription system saves the pharmacy time in not having to manually enter data into its prescription management system.

[0260] Adding CoR.io's digital identity tokens, blockchain, Title Office, biometric user authentication, and digital wallet to the e-prescribing process adds layers of privacy, security, and immutability of transactions to e-prescribing software. The digital identity tokens contain the validated and encrypted identity and identity credentials of the patient, the doctor, the pharmacy, and the patient's representative (if any) designated to pick up the prescription medication. Among other items described above, the token assets include the encrypted prescription authorized by the doctor's electronic signature and biometric user authentication. The token containing the e-prescription and proof of validated identity is generated on the doctor's PC, smartphone, or tablet. The token is sent directly to the patient and if required to the patient's designee. In addition, the token is stored on the blockchain, where it resides permanently. This includes the blockchain node in the patient's mobile device or PC.

[0261] Referring to FIG. 10, in a typical implementation, a doctor sends an e-prescription directly to a pharmacy and a copy of the e-prescription to the patient and the patient's designee, if any.

[0262] In the following description, a digital signature securely associates a signer with an electronic or physical document in a recorded transaction; and the recipient is assumed to be a pharmacy, a lab, a patient, a hospital, a clinic, or a patient's designee.
It is assumed that the prescription specifies a medication such as medicine or a lab procurement. [E]-prescribing transmits prescription data directly from a doctor's computer to a pharmacy management system, preventing fraudulent, lost, and misused Page 49 of 59 Date Regue/Date Received 2022-09-21 prescriptions. In an embodiment of the present invention, the digital token is considered to contain an e-prescription.

[0263] In step 1101, the doctor creates (generates) a digital token. The digital token contains the doctor's identity information, the doctor's medical credentials, the identity of the doctor's identity credential verifier and place of work, a digital identifier obtained from the identity credential verifier which validates the doctor's identity, the prescription information, and the identity of the intended recipient of medication or service specified in the prescription. The doctor also creates a first set of unlock keys needed to indicate ownership of the digital token.

[0264] In one embodiment, the digital identifier is a digital signature of the identity credential verifier. In other embodiments, the digital identifier is simply an organization name, a company name, an organization logo, a company logo, or some other watermark-like image of the identity credential verifier. The digital identifier can have been obtained according to processes described in US Patents 11/139,976, 11,171,781, and 10,171,476. US Patents 11/139,976, 11,171,781 and 10,171,476 describe identity verification by the creation of a hash that includes identity information.
This hash or digital identifier can be "looked up" on the blockchain to confirm that the identity information is valid.

[0265] In step 1102, the digital token and first set of unlock keys are electronically sent over the internet to the Title Office for verification. In this description, the Title Office is also referred to as a token administration authority.

[0266] In step 1103, the Title Office assigns an ID to the digital token and stores (or records) the digital token on the blockchain. The token ID is then returned to the token creator, Le., the doctor.

[0267] In step 1104, the doctor sends the digital token (including the token ID) and the first set of unlock keys to the agency that will deliver the good or service, e.g., a pharmacy.

[0268] In step 1105, the doctor sends the token ID to the patient.
Page 50 of 59 Date Regue/Date Received 2022-09-21

[0269] In step 1106, the pharmacy uses its CoRWallet app to create a second set of unlock keys. The pharmacy then sends the first and second sets of unlock keys and the digital token (including the token ID) to the Title Office.

[0270] In step 1107, the Title Office verifies that the second set of unlock keys are valid.

[0271] In step 1108, the Title Office records a new instance of (Le., updates) the digital token using the second set of unlock keys while invalidating the first set of unlock keys.
The Title Office then updates the blockchain with the digital token. At this point, the pharmacy "owns" the e-prescription, and the doctor cannot inadvertently duplicate its dispensation to another patient.

[0272] In step 1109, the patient uses their CorWallet app to send their identity information and the token ID to the pharmacy.

[0273] In step 1110, the pharmacy verifies the identity of the patient and the validity of the token ID.

[0274] In step 1111, the pharmacy delivers the medicine to the patient.
[0275j] In step 1112, the pharmacy uses its CoRWallet app to create a third set of unlock keys. The second and third sets of unlock keys, dispensing information, and the digital token (including the token ID) are sent to the Title Office.
[0276] In step 1113, the Title Office verifies that the third set of unlock keys are valid.
[0277] In step 1114, the Title Office records a new instance of the digital token using the third set of unlock keys while invalidating the second set of unlock keys. At this point, the pharmacy "owns" the e-prescription, and the e-prescription indicates that the medicine has been dispensed.
[02781] Step 1115 is optional. In this step, after the patient (or their designee) picks up the medicine, the Title Office sends token image information of the digital token to each of the doctor's CoRWallet and the patient's (or designee's) CoRWallet to confirm the pickup. The Title Office can also send the token image information to the pharmacy's CoRWallet. Suppose the patient does not pay for the medicine themself. In that case, a Page 51 of 59 Date Regue/Date Received 2022-09-21 message is also sent by each of the patient's (or designee's) CoRWallet and the pharmacy's CoRWallet to the patient's payer's CoRWallet, be it an insurance company or a government agency. The completed transaction is hashed and stored on the blockchain, including the blockchain in the patient's computing device. The raw prescription is encrypted and stored in both the patient's and the pharmacy's CoR Wallets.
[0279] In step 1116, providing the good or service by the pharmacy to the recipient is thus completed.
[0280] Referring to FIG. 12, in another typical implementation, a doctor sends an e-prescription to a patient prior to a pharmacy becoming involved.
[0281] In the following description, a digital signature is an authentication signature. In addition, the intended recipient is assumed to be a patient, and it is assumed that the prescription specifies a medication such as medicine. The digital token can be considered to be an e-prescription.
[0282] In step 1201, a doctor creates (generates) a digital token. The digital token contains the doctor's validated identification information, the identity of the doctor's identity credential verifier, a digital identifier obtained from the identity credential verifier which validates the doctor's identity, the prescription information, and the identity of the intended recipient of the good or service specified in the prescription. The doctor also creates a first set of unlock keys needed to indicate ownership of the digital token.
[0283] In one embodiment, the digital identifier is a digital signature of the identity credential verifier. In other embodiments, the digital identifier is simply an organization name, a company name, an organization logo, a company logo, or some other watermark-like thing of the identity credential verifier. The digital identifier can have been obtained according to processes described in US Patent 11/139,976. In such processes, a hash with the identity information is created at the time of identity verification by the identity credential verifier. From that time on, the digital identifier can be looked up, on the blockchain to confirm that the identity information is valid.
Page 52 of 59 Date Regue/Date Received 2022-09-21 [0284] In step 1202, the digital token and first set of unlock keys are electronically sent over the internet to the Title Office for verification. In this description, the Title Office is also referred to as a token administration authority.
[0285] In step 1203, the Title Office assigns an ID to the digital token and stores (or records) the digital token on the blockchain. The token ID is then returned to the token creator, Le., the doctor.
[0286] In step 1204, the doctor sends the digital token (including the token ID) and the first set of unlock keys to the patient.
[0287] In step 1205, the patient uses their CoRWallet app to immediately create a second set of unlock keys. The patient then sends the first and second sets of unlock keys and the digital token (including the token ID) to the Title Office.
[0288] In step 1206, the Title Office verifies that the second unlock keys are valid.
[0289] In step 1207, the Title Office records a new instance of (Le., updates) the digital token using the second set of unlock keys while invalidating the first set of unlock keys.
The Title Office then updates the blockchain with the digital token. At this point, the patient "owns" the e-prescription, and the doctor cannot inadvertently duplicate its dispensation to another patient.
[0290] In step 1208, the patient sends the digital token (including the token ID) and the second set of unlock keys to a dispensing entity (e.g., a pharmacy) of his/her choice from their CoRWallet. The e-prescription is received by the pharmacy's CorWallet and is transferred electronically to the pharmacy's prescription management system to prepare for dispensation and pickup. Alternatively, the e-prescription can be transcribed via a keyboard into the pharmacy's prescription management system.
[0291] In step 1209, the pharmacy verifies the identity of the patient and the validity of the token ID.
[0292] In step 1210, the medicine is dispensed for pickup by the patient (or their designee).
Page 53 of 59 Date Regue/Date Received 2022-09-21 [0293] When the patient (or designee) arrives at the pharmacy to pick up the medicine, they authenticate themselves and present a OR code generated by CoRWallet.
This is done by clicking on (or tapping) the encrypted e-prescription stored in the patient's CoRWallet. The pharmacy employee scans the OR code, and the pharmacy CoRWallet determines whether there is a match with the encrypted e-prescription stored in the pharmacy's CoRWallet. If there is a match, the pharmacy's CoRWallet instructs the employee to give the go-ahead to dispense the medicine. More particularly, the pharmacy asks the pharmacy's CoRWallet to verify that the digital token matches what is on the blockchain, including the token ID. The wallet also verifies the patient's identity by checking the proof of validated identity stored on the blockchain; and, if necessary, the doctor's authorization to issue e-prescriptions. Assuming that all checks are satisfactory, the pharmacy hands the medicine over to the patient (or designee).
[0294] In step 1211, the pharmacy creates a third set of unlock keys. The second and third sets of unlock keys, the dispensing information, and the digital token (including the token ID) are sent to the Title Office.
[0295] In step 1212, the Title Office verifies that the third set of unlock keys are valid.
[0296] In step 1213, the Title Office records a new instance of the digital token using the third set of unlock keys while invalidating the second set of unlock keys. At this point, the pharmacy "owns" the e-prescription, and the e-prescription indicates that the medicine has been dispensed.
[0297] Alternatively, the patient prints out the e-prescription and takes a paper copy to a brick-and-mortar pharmacy. The e-prescription is transcribed via a keyboard into the pharmacy's prescription management system for pickup by the patient. The patient presents a OR code generated by CoRWallet after the authentication of the patient.
This is done by clicking on the encrypted e-prescription stored in the patient's CoRWallet. The pharmacy employee scans the OR code, and the pharmacy's CoRWallet determines whether there is a match with the e-prescription on the digital token sent by the doctor. If there is a match, the patient picks up the medicine.
Optionally, the patient can send the e-prescription to a designee with a CoRWallet, with Page 54 of 59 Date Regue/Date Received 2022-09-21 the designee authorized to pick up the patient's medicine. The designee picks up the medicine by presenting a OR code generated by CoRWallet. The pharmacy employee scans the OR code. If the pharmacy's CoRWallet determines a match, it gives the go-ahead to dispense the medicine.
[0298] Step 1214 is optional. In this step, after the patient (or designee) picks up the medicine, the Title Office sends the token image information of the digital token to each of the doctor's CoRWallet and the patient's (or designee's) CoRWallet to confirm the pickup. The Title Office can also send the token image information to the pharmacy's CoRWallet. In the event the patient does not pay for the medicine, a message is sent by each of the patient's (or designee's) CoRWallet and the pharmacy's CoRWallet to the payer's CoRWallet, be it an insurance company or a government agency. The completed transaction is hashed and stored on the blockchain, including the blockchain in the patient's computing device. The raw prescription is encrypted and stored in both the patient's and the pharmacy's CoRWallets.
[0299] In step 1215, providing the good or service by the pharmacy to the recipient is thus completed.
[0300] CoRWallet can also be used by doctors to send requisitions for medical services, such as to pathology labs, physiotherapy providers, specialist doctors, hospitals, chiropractors, and other medical service providers.
[0301] Specific details are given in the above description to provide a thorough understanding of the embodiments. However, it is understood that the embodiments may be practiced without these specific details. For example, circuits may be shown in block diagrams in order not to obscure the embodiments in unnecessary detail. In other instances, well-known circuits, processes, algorithms, structures, and techniques may be shown without unnecessary detail in order to concentrate on the inventive features.
[0302] Implementation of the techniques, blocks, steps and means described above may be done in various ways. For example, these techniques, blocks, steps, and means may be implemented in hardware, software, or a combination thereof. For a hardware implementation, the processing units may be implemented within one or more application-Page 55 of 59 Date Regue/Date Received 2022-09-21 specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, other electronic units designed to perform the functions described above, and/or a combination thereof.
[0303] Also, it is noted that the embodiments may be described as a process that is depicted as a flowchart, a flow diagram, a data flow diagram, a structure diagram, or a block diagram. Although a flowchart may describe the operations as a sequential process, many of the operations can be performed in parallel or concurrently. In addition, the order of the operations may be rearranged. A process is terminated when its operations are completed but could have additional steps not included in the figure. A
process may correspond to a method, a function, a procedure, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination corresponds to a return of the function to the calling function or the main function.
[0304] Furthermore, embodiments may be implemented by hardware, software, scripting languages, firmware, middleware, microcode, hardware description languages, and any combination thereof. When implemented in software, firmware, middleware, scripting language, and/or microcode, the program code or code segments to perform the necessary tasks may be stored in a machine-readable medium, such as a storage medium. A code segment or machine-executable instruction may represent a procedure, a function, a subprogram, a program, a routine, a subroutine, a module, a software package, a script, a class, or any combination of instructions, data structures, and/or program statements. A code segment may be coupled to another code segment or a hardware circuit by passing and/or receiving information, data, arguments, parameters, and/or memory content. Information, arguments, parameters, data, etc., may be passed, forwarded, or transmitted via any suitable means, including memory sharing, message passing, token passing, network transmission, etc.
[0305] For a firmware and/or software implementation, the methodologies may be implemented with modules (e.g., procedures, functions, and so on) that perform the functions described herein. Any machine-readable medium tangibly embodying instructions may implement the methodologies described herein. For example, software Page 56 of 59 Date Regue/Date Received 2022-09-21 codes may be stored in a memory. The memory may be implemented within the processor or external to the processor and may vary in an implementation where the memory is employed in storing software codes for subsequent execution and where the memory is employed in executing the software codes. As used herein, the term "memory"
refers to any long-term, short-term, volatile, nonvolatile, or other storage medium and is not limited to any particular type of memory or number of memories or type of media upon which memory is stored.
[0306] Moreover, as disclosed herein, the term "storage medium" may represent one or more devices for storing data, including read-only memory (ROM), random access memory (RAM), magnetic RAM, core memory, magnetic disk storage mediums, optical storage mediums, flash memory devices and/or other machine-readable mediums for storing information. The term "machine-readable medium" includes, but is not limited to, portable or fixed storage devices, optical storage devices, wireless channels, and/or various other mediums capable of storing, containing, or carrying instruction(s) and/or data.
[0307] In one or more embodiments, the methodologies described herein are performable by a machine that includes one or more processors that accept code segments containing instructions. For any of the methods described herein, the machine performs the method when the instructions are executed by the machine. Any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine are included. Thus, a machine may be exemplified by a typical processing system that includes one or more processors. Each processor may include one or more of a CPU, a graphics processing unit, and a programmable DSP unit. The processing system further may include a memory subsystem including main RAM and/or static RAM
and/or ROM. A bus subsystem may be included for communicating between the components. If the processing system requires a display, such a display may include, e.g., a liquid crystal display (LCD). If manual data entry is required, the processing system also includes an input device such as one or more of an alphanumeric input unit including a keyboard, a pointing control device such as a mouse, and so forth.
[0308] The memory includes machine-readable code segments (e.g., software or software code), including instructions for performing, when executed by the processing Page 57 of 59 Date Regue/Date Received 2022-09-21 system, one or more of the methods described herein. The software may reside entirely in the memory or may also reside, completely or at least partially, within the RAM and/or within the processor during execution thereof by the computer system. Thus, the memory and the processor also constitute a system comprising machine-readable code.
[0309] In alternative embodiments, the machine operates as a standalone device; or may be connected, e.g., networked, to other machines in a networked deployment.
The machine may operate in the capacity of a server or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer or distributed network environment. The machine may be, for example, a computer, a server, a cluster of servers, a cluster of computers, a web appliance, a distributed computing environment, a cloud computing environment, or any machine capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine.
The term "machine" may also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.
[0310] Further, in describing representative embodiments of the present invention, the specification may have presented the method and/or process of the present invention as a particular sequence of steps. However, to the extent that the method or process does not rely on the particular order of steps set forth herein, the method or process should not be limited to the particular sequence of steps described. As one of ordinary skill in the art would appreciate, other sequences of steps may be possible. Therefore, the particular order of the steps set forth in the specification should not be construed as limitations on the claims. In addition, the claims directed to the method and/or process of the present invention should not be limited to the performance of their steps in the order written, and one skilled in the art can readily appreciate that the sequences may be varied and remain within the spirit and scope of the present invention.
[0311] Finally, the foregoing disclosure of the exemplary embodiments of the present invention has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the present invention to the precise forms disclosed. Many variations and modifications of the embodiments described herein will be apparent to one Page 58 of 59 Date Regue/Date Received 2022-09-21 of ordinary skill in the art in light of the above disclosure. The scope of the present invention is to be defined only by the claims appended hereto and by their equivalents.
Page 59 of 59 Date Regue/Date Received 2022-09-21

Claims (23)

Claims

1. A method of creating and storing a digital token containing verifiable proof of the identity of a creator of the token, the method comprising:
a human token creator using a computing device to select one or more elements of personal identifying information from a secure data store on the computing device;
the token creator using the computing device to select a unique digital identifier designating the identity of an identity verifier which has previously authenticated the selected personal identifying information as being valid and appropriate for the token creator;
the token creator using the computing device to create a digital token by applying a one-way hashing algorithm to a combination of the personal identifying information and the identity verifier's digital signature;
the token creator using the computing device to calculate a unique set of digital locking keys, the possession of which indicates ownership of the digital token being created;
the token creator using the computing device to send first data to a server operated by an administrator of a token management system, the first data comprising the digital token, the calculated locking keys, and the personal identifying information and identity verifier's digital signature that were used to construct the digital token;
the server using portions of the first data that represent token components of the digital token to verify that the digital token is properly formulated;
the server assigning a unique token identifier (ID) to the digital token and adding the digital token to an immutable data store;
the server sending second data to the computing device, the second data comprising the token ID; and the first computing device storing a copy of the digital token along with the token ID in the secure data store of the computing device.

2. A method according to claim 1, wherein the token creator represents one of a commercial business entity, a government service agency, a nonprofit organization, a not-for-profit organization, and an individual person.

3. A method according to claim 1, wherein the first computing device is one of a mobile smart device, a portable tablet, a laptop computer, a desktop computer, and one or more application servers operating in a commercial environment; and the mobile smart device comprises one of a phone, a watch, eyeglasses, and a headset.

4. A method according to claim 1, wherein the first data and second data are cryptographically encrypted before transmission to enhance security of the information being passed.

5. A method according to claim 1, wherein the immutable data store is used to record digital tokens and makes use of at least one the following items to ensure data integrity and immutability: an immutable blockchain protocol, an immutable asset chain protocol, and a physical air gap device to selectively isolate the immutable data store from the internet.

6. A method of creating and storing a collection of contributory digital tokens as a bundled digital token, each of the contributory digital tokens representing a respective document signer's electronic signature placed upon a digital document such that the resulting collection represents a single same version of the digital document that has been electronically signed by all of the document signers, the method comprising:
electronically delivering a same digital document to a plurality of computing devices, each computing device controlled by a respective one of the document signers;
each document signer using their computing device to create a contributory digital token comprising:
one or more elements of personal identifying information that reside in a secure data store of their computing device;
a unique digital identifier designating the identity of an identity verifier which has previously authenticated the personal identifying information as being valid and appropriate for the document signer;
the contents of the digital document; and a graphical representation of an electronic signature of the document signer to be affixed to the bundled digital token to be created;
each document signer using their respective computing device to calculate a unique set of digital locking keys, the possession of which indicates ownership of the contributory digital token;
each document signer using their respective computing device to send first data to a server operated by a predetermined signing coordinator, the first data comprising the contributory digital token and the calculated locking keys;
the signing coordinator collecting the first data from all the document signers and using the server to create a bundled digital token containing copies of all the contributory digital tokens received from the document signers;
the signing coordinator sending second data to each of the document signers, the second data comprising the bundled digital token;
each document signer sending third data to the signing coordinator, the third data indicating the document signer's satisfaction with the signatures of the bundled digital token;
the signing coordinator, upon receiving the third data from all the document signers, assigning a unique token identifier (ID) to the bundled digital token, and adding the bundled digital token to an immutable data store;

the signing coordinator sending fourth data to each of the document signers, the fourth data comprising the token ID; and the computing device of each document signer storing a copy of the bundled digital token in the secure data store of their computing device.

7. A method according to claim 6, wherein each document signer represents one of a commercial business entity, a government service agency, a nonprofit organization, a not-for-profit organization, and an individual person.

8. A method according to claim 6, wherein the computing device of each document signer is one of a mobile smart device, a portable tablet, a laptop computer, a desktop computer, and one or more application servers operating in a commercial environment; and the mobile smart device comprises one of a phone, a watch, eyeglasses, and a headset.

9. A method according to claim 6, wherein any selected one or more of the first data, second data, third data and fourth data are cryptographically encrypted before transmission to enhance security of the information being passed.

10. A method according to claim 6, wherein the immutable data store is used to record digital tokens and makes use of at least one the following items to ensure data integrity and immutability: an immutable blockchain protocol, an immutable asset chain protocol, and a physical air gap device to selectively isolate the immutable data store from the internet.

11. A method of creating, storing, and transferring a digital token, the method comprising:
a first user using a first computing device to create a digital token which contains:
selected personal identifying information of the first user, including credentials designating the first user as authorized to create a digital token of a designated kind;
a unique digital identifier designating the identity of an identity verifier which has previously authenticated the selected personal identifying information and the credentials as being valid and appropriate for the first user; and an authorization for a specific predetermined second user to receive a specified good or service from a third user authorized to dispense the specified good or service;
the first user using the first computing device to apply a one-way hashing algorithm to the digital token and creating a first set of unique digital locking keys, the possession of which indicates current ownership of the digital token;
the first user using the first computing device to send first data to a server operated by an administrator of a token management system, the first data comprising the digital token, the first locking keys, and the personal identifying information and identity verifier's digital signature that were used to construct the digital token;
the server using portions of the first data that represent components of the digital token to verify that the digital token is properly formulated;

the server assigning a unique token identifier (ID) to the digital token and adding the digital token to an immutable data store;
the server sending second data to the first computing device, the second data comprising the token ID;
the first computing device storing a copy of the digital token along with the token ID in a secure data store of the first computing device;
the first user using the first computing device to send third data to a second computing device operated by the second user, the third data comprising the digital token, the token ID, and the first locking keys;
the second user using the second computing device to create a second set of unique digital locking keys;
the second user using the second computing device to send fourth data to the server, the fourth data comprising the digital token, the first locking keys, and the second locking keys;
the server using portions of the fourth data that represent components of the digital token to verify that the digital token is properly formulated and in agreement with the contents of the digital token specified by the token ID, and verify that the first locking keys are still valid for use;
the server storing an updated copy of the digital token using the token ID and the second locking keys in a manner which invalidates the first locking keys;
the server sending fifth data to both the first computing device and the second computing device, the fifth data comprising the token ID;
the second user using the second computing device to send sixth data to a third computing device controlled by the third user, the sixth data comprising the digital token, the token ID, and the second locking keys;
the third user using the third computing device to create a third set of unique digital locking keys;
the third user sending seventh data to the server, the seventh data comprising the digital token, the token ID, the second locking keys, and the third locking keys;
the server using portions of the seventh data that represent components of the digital token to verify that the digital token is properly formulated and in agreement with the contents of the digital token specified by the token ID, and verify that the second locking keys are still valid for use;
the server sending eighth data to the third computing device indicating that the digital token and the second and third locking keys provided are valid;
upon the third user's successful dispensing of the specified good or service to the second user, the third computing device sending ninth data to the server, the ninth data comprising the contents of the digital token, the second set of locking keys, the third set of locking keys, and information related to the successful dispensation of the specified good or service;
the server storing an updated copy of the digital token using the dispensation infomiation, the token ID and the third locking keys in a manner which invalidates the second locking keys; and the server sending tenth data to the third computing device and the second computing device, the tenth data comprising the token ID and the information related to the successful dispensation of the specified good or service.

12. A method according to claim 11, further comprising the server sending the tenth data to the first computing device.

13. A method according to claim 11, wherein the first user is a medical professional authorized to prescribe any one or more of medicines, treatments, and other medical procedures, goods, and services; the second user is a patient of the medical professional;
and the third user is an entity authorized to dispense any of medicines, treatments, and other medical goods, services and procedures.

14. A method according to claim 11, further comprising the second user designating a fourth user to collect the specified good or service from the third user on behalf of the second user.

15. A method according to claim 11, wherein each of the first, second and third computing devices is one of a mobile smart device, a portable tablet, ef a laptop computer, a desktop computer, and one or more application servers operating in a commercial environment; and the mobile smart device comprises one of a phone, a watch, eyeglasses, and a headset.

16. A method according to claim 11, wherein any selected one or more of the first data, second data, third data, fourth data, fifth data, sixth data, seventh data, eighth data, ninth data and tenth data are cryptographically encrypted before transmission to enhance security of the information being passed.

17. A method according to claim 11, wherein the immutable data store is used to record digital tokens and makes use of at least one the following items to ensure data integrity and immutability: an immutable blockchain protocol, an immutable asset chain protocol, and a physical air gap device to selectively isolate the data store from the intemet.

18. A method of creating, storing, and transferring a digital token, the method comprising:
a first user using a first computing device to create a digital token which contains:
selected personal identifying information of the first user, including credentials designating the first user as authorized to create a digital token of a designated kind; and a unique digital identifier designating the identity of an identity verifier which has previously authenticated the selected personal identifying information and the credentials as being valid and appropriate for the first user;
details of a good or service that is to be provided by a second user to a third user;

personal identifying information associated with the third user who is intended to be the recipient of a good or service from the second user; and an authorization for the second user to deliver a specified good or service to the third user;
the first user using the first computing device to apply a one-way hashing algorithm to the created digital token and creating a first set of unique digital locking keys, the possession of which indicates current ownership of the digital token;
the first user using the first computing device to send first data to a server controlled by an administrator of a token management system, the first data comprising the digital token, the first locking keys, and the personal identifying information and identity verifier's digital signature that were used to construct the digital token;
the server using portions of the first data that represent components of the digital token to verify that the digital_token is properly formulated;
the server assigning a unique token identifier (ID) to the digital token and adding the digital token to an immutable data store;
the server sending second data to the first computing device, the second data comprising the token ID;
the first computing device storing a copy of the digital token along with the token ID in a secure data store of the first computing device;
the first user using the first computing device to send third data to a second computing device operated by the second user, the third data comprising the digital token, the token ID, and the first locking keys;
the first user sending fourth data to the third user, the third data comprising the token ID and a copy of the digital token;
the second user using the second computing device to create a second set of unique digital locking keys;
the second user using the second computing device to send fifth data to the server, the fifth data comprising the digital token, the first locking keys and the second locking keys;
the server using portions of the fifth data that represent components of the digital token to verify that the digital_token is properly formulated and in agreement with the contents of the digital token specified by the unique identifier, and verify that the first locking keys are still valid for use;
the server storing an updated copy of the digital token using the token ID and the second locking keys in a manner which invalidates the first locking;
the third user using a third computing device to deliver sixth data to the second computing device; the sixth data comprising the token ID, the copy of the digital token, selected personal identifying information of the third user, and a unique digital identifier designating the identity of an identity verifier which has previously authenticated the selected personal identifying information of the third user;
the second user sending the sixth data to the server;
the server using portions of the sixth data to verify that the token ID in the sixth data is an accurate representation of the digital token originally created by the first user;
the server using portions of the sixth data to verify that the personal identifying information related to the third user are valid and have been properly authenticated by the identity verifier designated in the sixth data;
the server sending seventh data to the second computing device, the seventh data comprising the results of the server's verifications of the digital token and the third user's identity;
the second user delivering the specified good or service to the third user;
the second user using the second computing device to add appropriate detailed information related to the delivery of the specified good or service to the digital token;
the second user using the second computing device to apply a one-way hashing algorithm to the updated digital token;
the second user using the second computing device to create a third set of unique digital locking keys;
the second user using the second computing device to send eighth data to the server, the eighth data comprising the updated token, the second set of digital locking keys, and the third set of digital locking keys;
the server using portions of the eighth data to verify that the digital token is properly formulated and that the second locking keys are the valid locking keys that permit the digital token to be updated;
the server adding the updated version of the token to an immutable data store in a manner which invalidates the second locking keys; and the server sending ninth data to the second computing device indicating that the digital token has been accepted and stored.

19. A method according to claim 18, wherein the first user is a medical professional authorized to prescribe any one or more of medicines, treatments, and other medical procedures, goods, and services; the second user is an entity authorized to dispense any of medicines, treatments, and other medical goods, services, and procedures; and the third user is a patient of the medical professional.

20. A method according to claim 18, further comprising the third user designating a fourth user to collect the specified good or service from the second user on behalf of the third user.

21. A method according to claim 18, wherein each of the first, second and third computing devices is one of a mobile smart device, a portable tablet, a laptop computer, a desktop computer, and one or more application servers operating in a commercial environment; and the mobile smart device comprises one of a phone, a watch, eyeglasses, and a headset.

22. A method according to claim 18, wherein any selected one or more of the first data, second data, third data, fourth data, fifth data, sixth data, seventh data, eighth data, and ninth data are cryptographically encrypted before transmission to enhance security of the information being passed.

23. A method according to claim 18, wherein the immutable data store is used to record digital tokens and makes use of at least one the following items to ensure data integrity and immutability: an immutable blockchain protocol, an immutable asset chain protocol, and a physical air gap device to selectively isolate the data store from the internet.
Notes In the specifications that explain the independent claims, the "a unique digital identifier designating the identity of an identity verifier..." exists on the token creator's smart device because they had previously performed an identity verification process such as the one covered in our Mobile ID:
US Patent #11129976.
The "digital identifier" might be a digital signature, or simply a company name, or a logo, or some other watermark-like thing. The digital identifier was used at the time of identity verification to create a hash with the identity information that can be looked up on a blockchain to assure that the identity information is valid.