WO2019209291A1 - Systems and methods for providing a universal decentralized solution for verification of users with cross-verification features - Google Patents

Systems and methods for providing a universal decentralized solution for verification of users with cross-verification features Download PDF

Info

Publication number
WO2019209291A1
WO2019209291A1 PCT/US2018/029371 US2018029371W WO2019209291A1 WO 2019209291 A1 WO2019209291 A1 WO 2019209291A1 US 2018029371 W US2018029371 W US 2018029371W WO 2019209291 A1 WO2019209291 A1 WO 2019209291A1
Authority
WO
WIPO (PCT)
Prior art keywords
user
documents
information
verified
verification
Prior art date
Application number
PCT/US2018/029371
Other languages
French (fr)
Inventor
Marcus Andrade
Original Assignee
Black Gold Coin, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority to US15/961,647 priority Critical
Priority to US15/961,647 priority patent/US20180343120A1/en
Application filed by Black Gold Coin, Inc. filed Critical Black Gold Coin, Inc.
Publication of WO2019209291A1 publication Critical patent/WO2019209291A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31User authentication
    • GPHYSICS
    • G06COMPUTING; CALCULATING; COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/57Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network
    • H04L63/0861Network architectures or network communication protocols for network security for supporting authentication of entities communicating through a packet data network using biometrical features, e.g. fingerprint, retina-scan
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communication including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials

Abstract

System and methods for providing a universal decentralized solution for verification of users with cross-verification features, may be configured to receive from a first entity, at a trust utility such as a distributed database or blockchain, information related to one or more verified first documents, the one or more verified first documents associated with a first user. The system may receive from a second entity, at the trust utility, a request for the information related to the one or more verified documents associated with the first user. The system may, upon receiving from the first user at the trust utility, an approval of the request for the information related to the one or more verified documents associated with the first user, give access to the second entity to obtain access to Information related to the one or more verified documents associated with the first user.

Description

SYSTEMS AND METHODS FOR PROVIDING A UNIVERSAL DECENTRALIZED SOLUTION FOR VERIFICATION OF USERS WITH CROSS-VERIFICATION FEATURES

Technical Reid This disclosure relates to systems and methods for providing verification of user identity information among business entities, and more particularly to providing a universal decentralized solution for verification of users with cross-verification features.

Description of the Prior Art Currently, systems and methods for securing information related to an individual is or associated with documents of an individual are Sacking in various ways. There is thus a need in the art for enhanced methods of securing such Information related to individuals and their associated documents. For example, them is a need in the art for improvements to biometric security methods for securing information related to individuals and documents.

Disclosure of the invention

Some implementations according to the present technology are directed to software methods that improve computer functionality by incorporating more robust security mechanisms into the system. For example, it is desirable to store information associated with an individual (user) in a secure fashion, including but not limited to such customary and accepted forms of persona! identification associated with one or more users sueh as an identification card, passport, or other documents; other user data belonging to the user; or other information associated with the user, in some implementations, it may be desirable for the user to have the capability to allow or deny an entity (e g., a business, institution, etc.) the right to access that information. In some implementations, a user's biometric data and privacy will be well protected while sharing biometric data with the public and/or others through the medium of a trust utility such as a biockehain (e,g,: distributed ledger technology), a centralized ledger, or other trust utility organization. The present disclosure,, in addition to customary and accepted forms of personal Identification, provides a system operative in real time and without human intervention, to verify user identification Information among two or mere entities that Is related to the verified documents of a user. The invention Includes enhanced methods of biometric security of via face, retina, iris, fingerprint, and applied encrypted images for generating a biometric authentication code. The authentication code thus generated may then be applied or tagged directly to any data format that is utilized within a distributed ledger, such as in a blockchaio-basad system. Moreover, identification data associated with individual users may be further enhanced by the use of geo-Soeation and connection datasets.

For example, in one current problem that exists in the prior art, Firm A has products and clients Firm B wants to use and vice versa. However, to engage in a cross-sell transaction an exchange of some of their clients' data to the other in order to conduct that business, in this disclosure, such transaction may be facilitated by utilizing (1) a distributed ledger (e.g., each firm is abie to perform a keyword ioofeup to identify the number of clients Firm A has under that criteria)' and (2) biometric identification verification tied directly to clients (e.g., from AML, KYC, and/or other documentation), wherein each firm knows for certainty that those clients' documents and digital identity qualified via biometric authentication are verifiable* The terras AML (Antl- Money Laundering) and KYC (Know Your Customer) refer to accepted forms of identity information useful in such authentication of the digital identity of a user or client.

In some implementations, a method and associated dashboard are contemplated. There may be a corresponding approval process running In a mobile application that facilitates each firm exchanging basic and premium profiles of a count of clients in order to cross-sell, with the clients’ approval. If there is more than one firm, this may be accomplished in a one-to-one fashion or a many-to-many cross-matching fashion.

One aspect of the disclosure may re!ata to a system configured for a universal decentralized solution for verification of users with cross-verification features. The system may include one or more physical (i.e., hardware) processors and/or other components. The one or more physical processors may be configured by machine- readabie instructions to receive from a first entity, at a biockchain or trust utility, information related to one or more verified first documents, the verified first documents associated with a first user, The physical processors may be configured to receive from a second entity, at the feioekcbain or trust utility, a request for the information related to the verified documents associated with the first user. The physical processors may be configured to, upon receiving from the first user, at the biockchain or trust utility, an approval of the request for the information related to the verified documents associated with the first user, give access, by the biockchain or trust utility, to the second entity to obtain access to information related to the verified documents associated with the first user, The physical processors may be configured to, upon receiving from the first user, at the biockchain or trust utility, a denial of the request for the information related to the verified: documents associated with the first user, deny access, by the biockchain or trust utility, to the second entity to obtain access to information related to the verified documents associated with the first user.

Another aspect of the disclosure may relate to a method for providing a universal decentralised soiution for verification of users with cross-verification features, the method being performed by one or more physical processors configured by machine-readable instructions. The method may include receiving from a first entity, at a biockchain or trust utility. Information related to verified first documents, the verified first documents associated with a first user. The method may include receiving from a second entity, at the biockchain or trust utility, a request for the information related to the verified documents associated with the first user, The method may include, upon receiving from the first user, at the biockchain or trust utility, an approval of the request for the information related to the verified documents associated with the first user, giving access, by the biockchain or trust utility, to the second entity to obtain access to information related to the verified documents associated with the first user. The method may include, upon receiving from the first user, at the biockchain or trust utility, a denial of the request for the information related to the verified documents associated with the first user, denying access, by the biockchain or trust utility, to the second entity to obtain access to information related to the verified documents associated with the first user. These and other features, and characteristics of the present technology, as well as the methods of operation and functions of the rs!afed eiements of structure and the combination of parts and economies of manufacture, wiil become more apparent upon consideration of the following description and the appended claims with reference to the accompanying drawings, a!S of which form a part of this specification, wherein like reference numera!s designate corresponding parts in the various figures, it is to be expressly understood, however, that the drawings are for the purpose of illustration and description only and are not intended as a definition of the limits of the invention. As used in the specification and in the claims, the singular form of "a”,”arf, and“the" include plural referents unless the context clearly dictates otherwise, in addition, as used in the specification and: the claims, the term means’’and/or* unless the context clearly dictates otherwise. Brief Description of the Drawings

FIG, 1 illustrates a system for providing a universal decentralized solution for verification of users with cross-verification features, in accordance with one or more implementations.

FIG, 2 is a schematic showing how entities may communicate with a bioekchairs or trust utility, in accordance with one or more implementations

FIG, 3 Illustrates an overview of a biockchaln or trust utility with geo-location, in accordance with one or more implementations.

FIG, 4 illustrates an applied biockchaln overview, in accordance with one or more implementations.

FIG. 5 illustrates a method for providing a universal decentralized solution for verification of users with cross-verification features, in accordance with one or more implementations.

FIG, 8 Illustrates a process operational in each node of a cross verification trust utility for ensuring a secure verification address for one of a digital user identifier or biometric identification data of a user; and FIG. 7 Illustrates a system for securing verified documents of a user held by a first entity and configured for responding to requests for access from a second entity upon authorization by the user,

Figure imgf000007_0001
embodiment The invention described herein is directed to systems and methods for the facilitation of transactions between entities by verification of user's identity information [according to FINRA rules, for example} in association with user documents among such entities as individuals, businesses, institutions, etc, and In particular such transactions that are performed through encrypted communications on line without needing a trusted third; party, in addition to cross verifying user identification information, foe system and the methods disclosed herein can also facilitate the transfer of a wide variety of digital assets.

The transactions are executed by agreements (such as so-called smart contracts) that are seif-executing because certain specified conditions required for execution are pre-sufhorized and agreed-to in advance, in foe manner of an If - Then premise.

The pre-authorization requires the provision of foe party's identities based on identity documents such as government-issued documents (driver's license, social security number, passport, etc,), biometric scan data (images, fingerprints, voice prints, etc,), user location data, accredited Investor profiles, or other trusted references. The identity documentation is evaluated in comparison with stored identify information through an algorithmic process to match the identity of a party to a transaction with stored identity data for that party held by an entity involved in the transaction to be executed.

The identity information heid by an entity is that identity information submitted or obtained previously by the entity.

The identity information and the transaction ledger Information are stored and immutable in a secure database such as a distributed or centralized ledger that provides a secure method for recording data, The distributed ledger functions as a trusted utility for facilitating and memorializing the details of the transaction,

AML and KYC documents are useful user identification resources because they contain or are associated with high quality, trust-worthy Identification data. For example, AML documents associate user information such as passports, driver's licenses, perhaps social security numbers with transaction data known to be factually true, KYC documents include user information about financial transactions or assets useful in determining a user’s status as an accredited investor. Examples include bank statements, insurance policies, mortgage loan documents, investment account information, etc. in one example AML and KYC documents may also be effectively used for user identification of assets digitally such as stocks and bonds.

One type of distributed ledger is a linear bioekchain wherein: data related to transaction documents and the digital signatures of the parties to the transaction are stored in blocks of data. The blocks of data are related through a process of sequentially hashing the blocks to form a chain. The chain of blocks is replicated on all nodes in a peer-to-peer network of participating entities. Mon-i!near distributed ledgers that employ directed acyclic graphs (DAG) Include IOTA Tangle and Hedra Bashgraph, Such DAG-based systems have a topological ordering, such that a sequence has no directed cycles. Additionally, an Interplanetary File System (1PFS) can be implemented as part of thejnstant invention, such that peer-to-peer storage of data can be implemented.

The bioekchain may be a pubic, decentralized or permissibniess system or a private, centralized or permissioned system. Communication and access to both types may be secured by pubiic/privaie keys, Other types of distributed ledgers include Ethereum, Hypertedgsr Fabric, and B3 Cords, which differ primarily in the processes used to obtain consensus among the nodes as to the accuracy of the ledger.

Cross Veriileation refers to the secure exchange of requests and information between two or more entities as a precondition to a transaction - such as cross- seifing - by verifying at one entity information sent to It from another entity, The information may be identity information or documents, or it may be of data about the documents associated with the identity information. An example of cross verify could be the comparison of identification information from various "trust* parties to determine which one is reliable.

FiG. 1 illustrates a system 100 for providing a universal decentralized solution for verification of users with cross-verification features, in accordance with one or more implementations, in some implementations, system 100 may include one or more servers 102. The server» 102 may be configured to communicate with one or more computing platforms 154 according to a eisent/servet architecture, a peer-to-peer architecture, and/or other architectures. The users may access system 100 via computing platform» 104 such as desktop, laptop or tablet computers, and game consoles, wireless communication devices (e,g„ smartphones}, and other computing platforms capable of storing and executing program instructions,

The servers» 102 may be configured to execute machine-readable instructions 106. The machine-readable instructions 106 may include one or more of a machine readable instruction components such as a receiving verified documents component 108, a receiving information request component 110. a receiving user decision component 112, an approvai/deniai component 114, and/or other machine-readable Instruction components.

The machine-readable instructions 106 may be executable to establish verification addresses on a distributed: ledger or other trust utility. Generally speaking, a trust utility may be a transaction database shared by some or all nodes participating in system 100. in a trust utility the trust is built into the structure of the transaction database due to the security mechanisms incorporated within it. For example, once a transaction is deposited with the trust utility, that information becomes Immutable ~ i.e.. it cannot be altered. The participation of the nodes hiay be based on the Bitcosn protocol, Ethereum protocol, and/or other protocols related to digital currencies, and/or distributed ledgers (or other trust utilities). With respect to a blockehain, a fell copy of the biockchain contains every transaction ever executed in an associated digital currency. In addition to transactions, other Information may be contained by the biockehain or trust utility, such as described further herein.

The bioekchatn example of a trust utility may be based on several blocks. A block may include a record that contains and confirms one or more waiting transactions, Periodically (e,g„ roughly every one minute’s, a new block Including transactions and/or other information may be appended to the biockehain in some implementations, a given block in the biockehain contains a hash of the previous block. This may have the effect of creating a chain of blocks from a genesis block {i,e.t the first block in the biockehain) to a current block. The given block may be guaranteed to come chronologically after a previous block because the previous block's hash would otherwise not be known. The given block may be computationally impractical to modify once it is included in the biockehain because every block after It would also have to be regenerated.

A given verification address may include a specific location on the biockehain, distributed ledger or trust utility where certain information is stored, in soma implementations, an individual verification address within the biockehain or trust utility may be referred to as an "DU1D Address," A DU1D may be a "digital unique identifier8 or a“digital unique identity" in the context of verified first documents as defined below. The receiving verified documents component 108 may be configured to receive from a first entity, at a biockehain or trust utility, information related to one or more verified first documents. The verified first documents may be those documents associated with a first user (individual). The first entity may include of an institution, business, company, and/or other entities. In some implementations, the biockehain or trust utility of the present technology may differ from a standard biockehain, it may differ in that although the present technology may utilise an Ethereum biockehain (or any other type of biockehain or trust utility not tied to any cryptocurrency), the Ethereum biockehain and/or Ethereum private biockehain may be created to be suited for various things. When Ethereum Is used as a public biockehain a fee to execute the transaction Is required before the transaetson can proceed. This fee is called“gas/’ When Etbereum is used as a private biocKchain the gas fee mast be paid but can be generated by mining, which is a burdensome process* Some examples may include integrating components related to biometric tagging and/or biometric encryption of documentation held within the bloekchain. The use of datasets, while ensuring client/lndMdual data privacy and adhering to rules for the global data processing directive is envisioned.

The trust utility may be a closed loop trust utility private btodkchain in some implementations. In some implementations, the closed loop trust utility private blookchain may be made country-specific. In some implementations, due to data protection and information communication office rules in different countries, the trust utility or distributed ledger may not be operated as a decentralized model, instead, the trust utility may be operated as a closed-loop or centralized mode! One reason some implementations may be country-specific is the scenario where a first country and/or business do not want confidential and/or secure information to be shared or accessed by a second country and/or business. The trust utility may be enabled to have separate implementations for country-specific practices, it should be noted that the distributed ledger or trust utility may be operated as either a centralized model or a decentralized model, in various Implementations.

In some implementations, the information related to the verified documents associated with the first user may be encrypted with a first key and a second key. The first key may be a server key (e.g., a private key) that is stored on a backend server. The second key may be a client key that is a hash of biometric data associated with the first user (e.g,, a hash generated by providing the biometric data as input to a one-way hashing algorithm), in some implementations, the first and second keys may be applied to the bloekchain immutable ID for hyper-encryption of sensitive data formats and/or associated documentation.

Receiving information request component 110 may be configured to receive from a second entity, at the blookchain or trust utility, a request for the information related to the verified documents associated with the first user. The second entity may include one or more of an institution, business, company, and/or other entities. Receiving user decision component 112 may he configured to receive a decision (to give access or deny access) from the first user regarding the request for the information related to the verified documents associated with the first user at the biockehasn or trust utility, in some implementations, approvai/denial component 114 may be configured to give or deny access to the first entity if the request for the information is approved by the first user, access may be given by the trust utility for the second entity to obtain access to the information. Likewise, If the request for the Information is not approved by the first user, access may be denied by the trust utility for the second entity to obtain access to the information, in some implementations, the trust utility holds and apples biometric authentication code validation against information related to the verified documents associated with the first user in some Implementations, the first user may be notified if information related to the verified documents associated with the first user is accessed by authorities or others.

System 100 may be configured to associate identifiers with individuals having previously verified personal identities. For example, a first identifier may be associated with a first individual The first individual may have a previously verified personal Identity. Generally speaking, an identifier may Include one or more of a number, an alphanumeric code, a username, and/or other information that can be linked to an individual. In some implementations, an Individual identifier may be referred to as QUID or digital unique iD.

In accordance with some implementations, art individuai having a previously verified personal identity may have obtained the previously verified personal identity through a variety of approaches and the Individual may be required to provide evidence of the individual's identity. Such evidence (the information referred to above) may include one or more of providing a copy of a government issued identification (e,g„ passport and/or driver's license), providing a copy of mail received by the individual {e g., a utility bill), evidence provided by a third party, and/or other evidence on an individual’s identity. The evidence may be provided to an entity associated with serverfs) 102. System 100 may be configured to assign verification addresses on a trust utility to the Individuate. A given verification address may generated based on a public key and/or a private key. By way of example, a first verification address may be assigned to the first individual The first verification address may be generated based on a first public key and/or a first private key.

Generally speaking, a public and private key-pair may be used for encryption and decryption according to one or more public key algorithms. By way of non-limiting example, a key pair may be used for digital signatures. Such a key pair may include a private key for signing and a public key for verification. The public key may be widely distributed, while the private key is kept secret (e,g„ known only to its proprietor). The keys may he related mathematically, but calculating the private key from the public key Is unfeasible.

In some implementations, system 100 may be configured such that private keys may be stored within computing platform(s) 104. For example, the first private key may be stored within a computing platform 104 and/or other locations associated with the first Individual in accordance with some implementations, a private key may he stored in one or more of a user's "verify. daf file, a SIM cafe, and/or other locations.

In some implementations, system 100 may be configured such that multiple verification addresses may be assigned to separate individuals. For example, in addition to the first verification address, a second verification address may be assigned to the first individual. One or more additional verification addresses may be assigned to the first Individual, in accordance with one or more implementations.

System 100 may be configured to record identifiers and biometric data associated with the individuals at corresponding verification addresses. For example, the first identifier and first biometric data associated with the first individual may be recorded at the first verification address. Recording Information at a given verification address may include recording a hash or other encrypted representation of the Information, in some implementations, different biometric data may be recorded at multiple verification addresses assigned to a single given individual For example, in addition to the first identifier and the first biometric, data associated with the first individual (first user) being recorded at the first verification address, the first identifier and second biometric data associated with the first individual may he recorded at a second: verification address.

Generally speaking, biometric data may include metrics related to human characteristics. Biometric identifiers are distinctive, measurable characteristics that can he used to label and describe individuals. Biometric identifiers typically include physiological characteristics, hut may also include behavioral characteristics and/or other characteristics. Physiological characteristics may be related to the shape of an individual's body. Examples of physiological characteristics used as biometric data may include one or more of fingerprint, palm veins, face recognition, DNA, palm print, hand geometry, iris recognition, retina, odor or scent, and/or other physiological characteristics. Behavioral characteristics may be related to a pattern of behavior of an individual. Examples of behavioral characteristics used as biometric data may Include one or more of typing rhythm, gait, voice, and/or other behavioral characteristics. Online user behavioral characteristics may include a cyber behavior profile to identify a person’s identity.

The biometric data may include one or more of an image or other visual representation of a physiological characteristic, a recording of a behavioral characteristic, a template of a physiological characteristic and/or behavioral characteristic, and/or other biometric data, A template may include a synthesis of relevant features extracted from the source, A template may include one or more of a vector describing features of a physiological characteristic and/or behavioral characteristic, a numerical representation of a physiological characteristic and/or behavioral characteristic, an image with particular properties, and/or other information.

Biometric data may be received via computing platforms 104 associated with the individuate. For exam pie, biometric data associated with a first individual may be received via a first computing platform 104 associated with the first individual. The first computing platform 104 may Include an input device (not depicted) configured to capture and/or record a physiological characteristic and/or behavioral characteristic of the first individual. Examples of such an input device may Include one or more of a camera and/or other imaging device, a fingerprint scanner, a microphone, an accelerometer, and/or other input devices.

System 100 may be configured to provide an Interface for presentation to individuals via associated computing platforms 104. The interface may include a graphical user interface presented via individual computing platforms 104. According to some implementations, the interface may be configured to allow a given individual to add or delete verification addresses assigned to the given individual so long as at least one verification address is assigned to the given individual.

In some implementations, system 100 may be configured to access and/or manage one or more user profiles and/or user information associated with users of system 100. The user profiles and/or user information may include information stored by servers) 102, one or more of the computing piatform(s) 104, and/or other storage locations, The user profiles may include, for exam pie, information identifying users (e.g,, a username or handle, a number, an identifier, and/or other identifying information}, security login information (e g., a iogln code or password), system account information, subscription information, digital currency account information (e.g., related to currency held in credit for a user), relationship information (e.g,, information related to relationships between users in system 100), system usage information, demographic information associated with users, interaction history among users in system 100, information stated by users, purchase information of users, browsing history of users, a computing platform identification associated: with a user, a phone number associated with a user, and/or other information related to users,

The machine-readable instructions 108 may be executable to perform biookchain- based muitifaotor personal identity verification using the verification addresses.

System 100 may be configured to receive one or mere identifiers in connection with one or more requests to verify an identity of one or more individuals. For example, the first identifier may be received in connection with a request to verify an identity of the first individual Bequests for identity verification may be provided in connection with and/or related to financial transactions, information exchanges, and/or other interactions. Requests may be received from older individuals and/or other third

System 100 may be configured to extract the biometric date associated with the one or more individuals from the corresponding verification addresses. For example, the first biometric data associated with the first individual may be extracted from the first verification address. Extracting information (a.g„ biometric data) from a verification address may include decrypting information.

According to some implementations, system 100 may be configured such that, responsive to receiving the request to verify the identity of the first individual, a prompt may be provided to the first individual for biometric data matching the first biometric data and a private key matching the first private key. The prompt may be conveyed via a computing platform 104 associated with the first individual. The prompt may be conveyed via a graphical user interlace and/or other user interface provided by the computing platform 104 associated with the first individual. The prompt may include an Indication that is one or more of visual, audible, haptic, and/or other indications.

In some implementations, system 100 may be configured such that, responsive to receiving the request to verify the identity of the first individual, a prompt may be provided to a computing platform 104 associated with the first individual. The prompt may cause the computing platform 104 to automatically provide, to server(s) 102, biometric data matching the first biometric data and/or a private key matching the

Figure imgf000016_0001

System 100 may be configured to verify the identity of the individuate upon, or in response to, receiving matching biometric data and private keys. For example, the personal identity of the first individual may be verified upon receipt of (1 } biometric data matching the first biometric data and {2} a private key matching the first private key. Verifying the personal identity of the first individual may include comparing stored information with newly received information. According to some implementations, Identity system 100 may be configured such that the personal identity of the first individual may be verified upon receipt of (1) biometric data matching the first biometric data or the second biometric data and (2) a private key matching the first private key. Such implementations may provide so- called 'M-of-N” signatures for identity verification where some subset of a larger set of identifying information is required, in some implementations, system 100 may be configured such that the biometric data matching the first biometric data and the private key matching the first private key may be used to sign the verification of the personal identity of the first individual In some implementations, at least one; dedicated node performs the signing of tee verification of the personal identity of the first individual or user. A given dedicated node may include one or more of server(s) 102 The given dedicated node may be a public node or a private node configured for creating new blocks and/or for signing verification FIG. 2 is a schematic 200 showing how entities may communicate with a blockchain or trust utility 202, in accordance with one or more Implementations, Blockchain or trust utility 202 may receive from a first entity 204, information related to one or more verified first documents 208, tee verified first documents 206 associated with a first user. to some implementations, blockchain or trust utility 202 may receive from a second entity 208 a request for tbe Information related to the verified documents 206 associated with the first user. One or more documents 206 may be encrypted using, for example, an entity key to provide unique access, in some implementations,: blockchain or trust utility 202 may receive a decision (approval or denial) from the first user, regarding tee request for the information related to tee verified documents associated with tee first user.

In some implementations, system 100 may give (grant) or deny access to the first user. If the request for the information is approved by the first user, access may be given by blockchain or trust utility 202 for second entity 208 to obtain access to the information, Likewise, if the request for the information is not approved by the first user, access may foe denied by blockchain or trust utility 202 for second entity 208 to obtain access to the information.

FIG, 3 illustrates an overview 300 of b!ockehain or trust utility 202 with geo-location, in accordance with one or more implementations. Location data may be any information about an indivibyai’s current location, or about their movements in the past, which ean be linked to them, in some implementations, the types of data collected and applicable may include: bass station data Received Signal Strength Indicator (RSGI), Time Difference of Arrival (TDOA), and Angle Of Arrival (AGA), GPS data, WiFi Access points (Including Medium Access Control (MAC) addresses via mobile or passive scanning); static geo-location, dynamic/ongoing geoiocatlon, location-based services and/or service set IDs (SS!Ps), The use of keyhole markup language (KML) files to create datasets is contemplated; however, the use of any location-based dataset that utilizes markup languages Is contemplated, In some embodiments, certain rules for geo-location may be followed, A legal framework may be the data protection directive (0S/48/EC), If may apply In cases where personal data is being processed as a result of the processing of location data. The e-privaoy directive {2QQ2/S8/EG, as revised by 2009/136/EC) applies to the processing of base station data by pubic electronic communication services and networks (telecom operators), In some Implementations, biookchain or trust utility 202 genetically holds and applies biometric code validation against one or more of anti-money laundering (AML) documents, know your customer (KYC) documents, know your business (KYS) documents (such as formation documents, bank statements, annual reports, transaction information, etc,), know your person/process (KYP) documents, extraneous documents linked to businesses and individuals, various authentication credentiais, and/or other Items,

FIG, 4 illustrates an an example of a private, permlssioned blockchain overview 400, in accordance with one or more implementations. As shown and described in the figure, a privacy permlssioning administration layer for the biookchain is envisioned. It may be built on, for example, an Ethereum (public, permissioniess) biookchain. As shown, there may foe a mechanism for the storage of files (e.g„ biometric data, etc,). These items may be coupled with an application programming interface (API) and, inter alia, a BigChain DB, This may be coupled with, for example, a biometric app and a website, among other things, in alternative embodiments, the trust utility may be be built on any type of distributed ledger architecture. In some implementations, server^} 102, computing p!atformfs) 104, and/or external resources 122 may be operatively linked via one or more electronic communication links, For example, such electronic communication links may be established, at least in part, via a network such as the Internet and/or other networks, it will be appreciated that this is not intended to be limiting, and that the scope of this disclosure includes implementations in which serverfs) 102, computing p!atformfs) 104. and/or external resources 122 may be operatively linked via some other communication media.

A given computing platform 104 may include one or more processors configured to execute machine-readahie instructions. The machine-readable instructions may be configured to enable an expert or user associated with the given computing piatform 104 to interface with system 100 and/or externa! resources 122, and/or provide other functionality attributed herein to computing platform^} 104. By way of non-limiting example, the given computing piatform 104 may include one or more of a desktop computer, a laptop computer, a handheld computer, a tablet computing piatform, a NetBock, a Smartphone, a gaming console, and/or other computing platforms,

External resources 122 may Include sources of information, hosts, and/or providers of virtual environments outside of system 100, externa! entities participating with system 100, and/or other resources, in some implementations, some or all of the functionality attributed herein to external resources 100 may be provided by resources included in system 100,

Servers) 102 may include electronic storage 124, one or more processors 126, and/or other components, Server(s) 102 may include communication lines, or ports to enable the exchange of information with a network and/or other computing platforms. Illustration of server(s) T02 in FIG 1 Is not intended to be limiting.Servers) 102 may include a plurality of hardware, software, and/or firmware components operating together to provide the functionality attributed herein to server/ $) 102. For example, server(s) 102 may he Implemented by a cloud of computing platforms operating together as servers} 102,

Electronic storage 124 may comprise non-transitory storage media that electronically stores information. The electronic storage media of electronic storage 124 may include one or both of system storage that is provided integrally {; e.. substantially non-removable) with server(s) 102 and/or removable storage that is removably connectable to server(s) 102 via, for example, a port (e.g,, a USB port, a firewire port, etc.) or a drive (e,g„ a disk drive, etc,). Electronic storage 124 may include one or more of optically readable storage media (e.g., optica! disks, etc.), magnetically readable storage media (e.g. , magnetic tape, magnetic hard drive, floppy drive, etc,), electrical charge-based storage media (e.g,, EEPROM, R&M, etc.), solid-state storage media (e.g., flash drive, etc,), and/or other electronically readable storage media. Electronic storage 124 may include one or more virtual storage resources (e.g. , cloud storage, a virtual private network, and/or other virtual storage resources). Electronic storage 124 may store software algorithms, information determined byprocessors) 128, information received from server(s) 102, information received from computing platform(s) 184, and/or other information that enables serve r(s) 102 to function as described herein.

Processors) 126 may he configured to provide information processing capabilities in server(s) 102, As such, processor(s) 126 may Include one or more of a digital processor, an analog processor, a digital circuit designed to process information, an analog circuit designed to process information, a state machine, and/or other mechanisms for electronically processing Information, Although processors) 126 is shown In FiCS, 1 as a single entity, this is for illustrative purposes only, in some implementations, processor(s) 126 may include a plurality of processing units. These processing units may be physically located within the same device, or processor(s) 126 may represent processing functionality of a plurality' of devices operating in coordination. Processor/s) 126 may be configured to execute machine- readable instruction components 108, 110, 112, 114, and/or other machine-readable instruction components, Processor(s) 128 may be configured to execute machine- readable instruction components 108, 110, 112, 114, and/or other machine-readable instruction components by software; hardware; firmware; some combination of software, hardware, and/or firmwares; and/or other mechanisms for configuring processing capabilities on processor/s) 128, As used herein, the term“machine- readable instruction component" may refer to any component or set of components that perform the functionality attributed to the machine-readable instruction component. This may include one or more physical processors during execution of processor readable instructions, the processor readable instructions, circuitry, hardware, storage media, or any other components, if should he appreciated that although machine-readable Instruction components 108, 110, 112, 114 are illustrated in FIG, 1 as being implemented within a single processing unit, in implementations In which processors) 12.6 includes multiple processing units, one or more of machine-readabie instruction components 108, 110, 112, and/or 114 may be implemented remotely from the other machine-readable instruction components. The description of the functionality provided by the different machine-readable Instruction components 108, 110, 112, and/or 14 described below is for illustrative purposes, and is not Intended to be limiting, as any of machine- readable instruction components 108, 110, 112, and/or 114 may provide more or less functionality than is described. For example, one or more of machine-readabie instruction components 108, 110, 112, and/or 114 may be eliminated, and some or all of its functionality may be provided by other ones of machine-readabie instruction components 108, 110, 112, and/or 114. As another example, processors) 126 may¬ be configured to execute one or more additional machine-readabie instruction components that may perform some or all of the functionality attributed below to one of machine-readable instruction components 108, 110, 112, and/or 114.

FIG. 5 illustrates a method 500 for providing a universal decentralized solution for verification of users with cross-verification features, in accordance with one or more implementations. The operations of method 500 presented below are intended to be illustrative. In some implementations, method 500 may be accomplished with one or more additional operations not described, and/or without one or more of the operations discussed. Additionally, the order in which the operations of method 500 are illustrated In FIG. 5 and described below is not intended to be limiting, in some implementations, one or more operations of method 500 may be implemented in one or more processing devices (e.g., a digital processor, an analog processor, a digital circuit designed to process Information, an analog circuit designed to process information, a state machine, and/or other mechanisms for electronically processing information}, The one or more processing devices may include one or more devices executing some or all of the operations of method 500 in response to instructions stored electronically on an electronic storage medium, The one or more processing devices may include one or more devices configured through hardware, firmware, and/or software to be specifically designed for execution of one or more of the operations of method 500,

At an operation 602, method 500 may include receiving information related to one or more verified first documents 206, As an example, the verified first documents may be received at a b!ockehain or trust utility from a first entity (e.g,, first entity 204). The verified first documents 206 may be associated with a first user. Operation 502 may be performed by one or more physical processors configured to execute a machine-readable instruction component that is the same as or similar to receiving verified documents component 108 (as described in connection with FIG, 1), in accordance with one or more impiementations.

At an operation 604, method 500 may include receiving a request for the information related to the verified documents (e.g,, associated with the first user). As an example, the request may be received at the felockchain or trust utility from a second entity (e.g., second entity 206). Operation 504 may be performed by one or more physical processors configured to execute a machine-readable instruction component that is the same as or similar to receiving information request component 110 (as described in connection with FIG, 1), in accordance with one or more Impiementations,

At an operation 508, method 500 may include receiving a user decision (e.g , approval, denial, etc ). As an example, the user decision may be received at the biockchain or trust utility from foe first user. The user decision may foe with regard to the request for access to the verified documents associated with the first user or the Information related to the associated verified documents. Operation SOS may foe performed by one or more physical processors configured to execute a machine-readable instruction component that is the same as or similar to receiving user decision component 112 (as described In connection with FIG. 1), in accordance with one or more implementations. At an operation 508, method 500 may include giving or denying access to second entity 208, If the request for the information Is approved by the first user, access may foe given by folockohain or trust utility 202 for second entity 208 to obtain access to the information. Likewise, if foe request for the Information is not approved by the first user, access may be denied by the biockchain or trust utility for second entity 208 to obtain access to trie information. Operation 508 may foe performed by one or more physical processors configured to execute a machine-readable instruction component that is the same as or similar to approval/denial component 114 (as described in connection with FiG. 1}, in accordance with one or more

Figure imgf000023_0001

Exemplary implementations may facilitate storing personal data on the biockchain. The personal data may he stored on the biockchain in an encrypted way. A person may foe identified at the biockchain level with one or more of a private key, a finger print a finger print hash, an eye retina, an eye retina hash, and/or other unique information. The data stored may include or relate to one or more of a passport, an identification card, extracted passport information, a driver's license, extracted driver’s license Information, finger print, eye retina, and/or other information. According to some implementations, if some of the data is changed, a new record may be created for that person in foe biockchain. That is, all changes are added as new records. The old record wi!i always foe stored on the biockchain. Generally speaking, ail records on the biockchain are stored forever and cannot be removed. More than one copy of the biockchain will exist to ensure the records are not manipulated. Exemplary implementations may facilitate access to personal data. There may be multiple access levels for the personal data in the blockchain trust utility. Access controls may he granted on public/private key pairs levels. Examples of access levels may include one or more of Super Admin (full access to the distributed ledger, database or blockchain), Authorities-ccuntry level (full read-only access), Aufborlties- sfate/ioca! level (limited read-only access), Police and other services including Emergency (access to certain personal data by Finger Print/Eye retina of that person only), Participating Merchants (limited access), and/or other access levels.

Exemplary implementations may facilitate verification check. There may be muifipie levels for how it is possible to check verification, For example, some implementations may ensure a person has a record at“Company” hut no personal data is provided. Some implementations may ensure a person has a record at Company and get very basic personal information such as Full Name, DOB, Gender, and/or other basic information. Some implementations may ensure a person has a record at Company and get ali personal data.

In some Implementations, the technology may relate to using the PAS 1192-5 standard to manage construction Information and keep information related to architecture and building construction and Infrastructure security, PAS (Publicly Available Specification) 1192-5 Is a standard published by the British Standards Organization for security-minded building information modeling (BIM) and smart asset management. These aspects may be related to relation to smart Cities, connected cities, connected houses, smart grids (e.g. energy, etc,), and/or the like. These aspects may relate to the underlying security for internet of Things (!oT) for smart devices interconnecting but at a construction, architectural, and/or grid based level.

AS 1192-5:2015 is the specification for security-minded building information modelling, digital bulk environments and smart asset management,

PAS 1192-5 specifies the processes that may assist organizations In Identifying and implementing appropriate and proportionate measures to reduce the risk of ioss or disclosure of Information that could impact on the safety and security of: personnel and; other occupants or users of the built asset and its services; the built asset itself; asset information; and/or the benefits the built asset exists to deliver.

Such processes can also be applied to protect against the loss, that, and/or disclosure of valuable commercial information and intellectual property, The PAS has been developed to integrate a security-minded approach into the construction lifecycle processes as specified in PAS 1192-2 and the asset management processes described in PAS 1192-3,

PAS may be specifically applied to the built asset, which may be a single building, a site or campus, and/or a portfolio or network of assets, These aspects may be related to the mobile data that can be processed, collated, and/or held within the distributed ledger (whether in regards to the biometric identity of an individual and/or client}, in use, the system of the present invention, for example as depicted in Figure 4, fulfills two primary functions; {1 ) the addition of data to the platform regarding entities to enable the cross-sharing of information among them, the information to include information about trusted entities, user !D information from various sources, and files of biometric ID data about users: and (2) the response to an inquiry or request from one entity to another to initiate cross-verification of data, in one use case, for example, an administrative company adds Company A and to Company 8 to the platform (e.g.. system 100) so that both companies can perform ID verifications and participate In the cross sharing of user data between companies, With regard to this use case, a company may include a bank, insurance company, financial industry, mobile industry, government industry, public Industry, or any type of other entities that are considered trusted companies. In some oases, the trusted companies may inciude ATM (automated teller machine) companies and terminals, in some cases, a trust company may include a company or individual that Is regulated by any form of a government entity. In the foregoing use ease, a company may add data of a user to its database. The user data may include the user's private data, for example the user’s identification card, driver's license, passport, utility bill, and or other documents that states proof of identification and address (e.g>, AML-based (Anti-Money Laundering} or KYC-based (Know Your Customer) documents}, The user data may additionally or alternatively include insurance documents, financial documents, medical records, or other document or persona! data that belongs to the user, Such user data may further include the user's biometric data (e,g., recognition data for the user’s face, retina/iris^ fingerprint, heartbeat, vein, voice, etc,}. The user or the trusted company can then create a user authorisation code.

With respect to the foregoing use case, a company may obtain the user’s biometric data or other private seif-identifying data in a number of ways (e g., in-person by a trusted company representative or government agency or in other manners). Biometric data may also be captured using a mobile application (e,g,, via the hosting user device’s camera or other sensor) or with an externa! biometric capturing device that can be attached to a user device or other computing device. In some cases, a biometrics ATM may be used. In some cases, the biometric data may be confirmed without the user being present in the presence of a trusted party. As an example, a QR Code (e.g., linking to the biometric data) may be transmited (e g., via email, text messaging, etc.) to the user to confirm that the biometric data belongs to the user. Other means of SO verification may additionally or alternatively be used.

For instance, person to person registration verification (P2PRV) may be utilized to provide ID verification. P2PRV may Include Person A verifying the documentation and registering Person B, where Person A has already been registered by a trusted company. Person A may verify Person 8’s documentation (e,g„ by comparing Person B to his/her photo in Person B’s documentation, asking Person B verification questions related to the documentation, etc.) and confirm that Person 8 is actually the one completing the biometric scan, Person A may enter the confirmation Into the verification system.

In one use case. Company B (e.g. , a secondary entity requesting user data of a user) may request from Company A (e.g,, a primary entity that already has the user data) the entire user data or partial user data of the user that Company A has . Company A has the option of using a GPS locator security feature to validate the user identification Information, As an example, the GPS locator security feature may be security feature that does not aiiow user data to be transferred to another Company unless an IP address or GPS locator matches the Company address listed on file (for that other Company), For example, Company A’s computer system receiving Company 8!s request may check the IP address of the computer system from which the request was received to ensure that the checked IP address is on a list of authorized IP addresses in Company A’s database (e.g,t by verifying that the checked IP address is the same as an authorized IP address associated with

B), As another example, Company A's computer system receiving

Company B's request may check the IP address of the computer system from which the request was received fo ensure that a location associated with the checked IP address is on a location at which Company A Is located ie.g , by verifying that the checked !P address is associated with the same city or region as an address at which Company B is located). GPS tagging may additionally or alternatively be tied to each of the user data when being transferred.

With respect to the foregoing use case, a Company may perform a trusted company

Figure imgf000027_0001
verification. As an example, Company A (which has the user data) may approve or decline the transfer of the user data, the user associated with the user data (e.g,, the person that owns the passport or driver's license, biometric data, etc.) may be given a message in the form of an email, application notification via mobile application, text messaging, telephone call, or other form of communication to allow the user to approve or decline the request. The user may provide his user authorization code to Company B so that Company B can give that to Company A, The user authorization code may serve as an acceptance by the user to transfer over the user data to Company B. if the Company is a government agency, and there is no law requiring the government agency to seek approve! from the user before the transfer from government agency to government agency, then the government agency will not have to seek user approval, if the user accepts the transfer of his private data from Company A to Company B, then an ID verification process must be engaged to confirm that the user indeed is the one that approved fhe transfer. For example the user can either do a biometric scan on his or her mobile application to confirm he is who he says he is or simply send a text message. Company or users tagging can ocour in order to ensure a higher level of security. After the user agrees to the transfer of the user data, then the transfer will be completed either partially or fuily depending on the user authorization code.

As noted in the Summary of the invention, an important objective is how, in real time and without human intervention, to verify user identification information among two or more entities that is related to the verified documents of a user, in one embodiment of the present system the nodes of a distributed database or ledger are linked together to create a trust utility for the cross-verification of user Identification data to facilitate cross-sharing transactions, The distributed ledger is modified with software analytics to include processing of secure user identification (ID) data associated with various kinds of user identification documents. Examples of such user ID documents include (a) private information ~ e.g,, .AML documents such as a user ID card, driver's license, passport, utility biil or other document stating proof of identity and address or contact information; (b) other private information - e.g,, KYC documentation such as mortgage loans, insurance policies, bank statements, investment account statements, medical records, or other personal data such as resumes or curriculum vitae documents; (c) biometric data including scans or images or hashes of finger prints, retina, iris or facial data, a voice print, photographs, behavioral characteristics, etc; and (d) person-to-person registration verificatioh, i.e,s P2PRV information. P2P registration verification occurs when one person verifies the documentation of another person. For example, person A is already a registered user and person A, upon request, verifies the identify of a person B, Thus, a distributed database or ledger is formed among entitles that have a need to exchange or share secure user ID information related to verified user documents, ail of which must be kept secure during such sharing transactions. The“user' may Include customers, clients, other entities, etc. Verified documents may Include information about products, services, customer data, contracts, etc. Broadly stated, the present invention comprises a cross verification fCV) trust utility that Includes a system of computer-implemented nodes connected in a network and eonfigured by programmed instructions stored in respective non-volatile or non- transitory memory to form a distributed database or ledger, which controls processes operational In each node for ensuring secure access, through mechanisms configured for establishing a secure verification address for a digital user identifier of a user related to verified documents of the user on the distributed ledger; validating the identity of a users identification record associated with verified user documents stored in the distributed ledger of the system; and regulating access by an authorized entity to a user’s verified documents on the distributed ledger. Alternatively, the present Invention can be implemented on platforms unrelated to distributed ledgers, such as databases or other suitable platforms. The CV trust utility (See Figure 7 to be described) may also be called an 'administrative company’’ that enables two or more trusted companies to perform identification verifications and participate in tbe cross-sharing of user data between the trusted companies, A trusted company {e,g„ company A or company 8) is a company or individual that is regulated by any form of government. Examples include without limitation banks, insurance companies, entities in the financial teiecom, and transportation Industries, etc. in one embodiment illustrated in Figure 6 (See steps 610 and 012 - 618) the process for establishing a secure verification address for a digital user Identifier or biometric identification data of a user related to verified documents of a user on the distributed ledger comprises steps of (a) activating an interface configured to add or delete data related to verified documents or biometric identification data associated with the user (step 812); (b) encrypting the digital user identifier or biometric identification data associated with the verified documents of the user entered into the interface (step 814)· (c) associating the user’s digital user identifier with files in the distributed ledger containing the user's verified documents (step 818); and (d) recording the digital user Identifier, the biometric identification data or the verified documents in the verification address (step 818). In one embodiment, the data associated with the verified documents of a user can be encrypted. The encryption of the data can be achieved by application of the AES algorithm, a PGP algorithm, the Bipwfish algorithm, or another suitable encryption algorithm, in another embodiment, the data associated with the verified documents of a user can be hashed. The hashing of data can be achieved by application of an MD5 algorithm, SNA algorithm (e.g,, SHA-0), SHA-2 algorithm (e.g,, SHA-256) or other suitable hashing algorithm. in another embodiment illustrated in Figure 6 (See steps 620 and 822 ~ 828) the process for validating the identity of a user’s identification record associated with verified user documents stored in the system, comprises steps of (a) receiving the user’s encrypted identification data such as biometric identification data, a digital user identifier, a user’s location data set, or the verified user documents containing AML, KYC or KYB information (step 622): (b) decrypting the received identification data (step 624); (c) comparing the decrypted identification data with user Identification data stored in the distributed ledger system (828); and (d) outputting a determination of validation or invalidity regarding the received user's identification

Figure imgf000030_0001

In another embodiment Illustrated in Figure 6 (see steps 830 and 632 ~ 640), the process for regulating access by an authorized entity to a user’s verified documents on a distributed ledger; comprises steps of (a) activating via the one or more processors in any node on the network an algorithm configured for determining an authorized access level of the entity requesting access (step 632); (b) assigning the entity requesting access to the determined authorized access level (step 634); (o) receiving an encrypted digital user identifier of the user associated with the verified document sought by the requesting entity (step 636); (d) decrypting the received digital user identlfierCstep 638); and (e) controlling the grant or denial of access depending on verification of a match of the received digital unique identifier with biometric Identification data of the user associated with the verified document sought by the requesting entity (step 840).

Figure ? illustrates one embodiment of a structure of the system TOG of present invention that provides a Cross Verification Trust Utility 710 for performing the processes described and illustrated in Figure 6. The Cross Verification Trust Utility 710— also called ”CV 710*' herein - may, for example, be embodied in an administrative trust utility providing the cross verification as a service. Briefly, in use an entity A, which has’Verified ID-proof documents of a first user or client in Its database, can respond to a request from an entity 8 for ID verification of the first user by making available the ID proof documents of the first user to entity B if the first user (contacted by the entity B to agree to a smart contract regarding the approval for access by entity B to the ID record(s) held by entity A) approves the request for access. The system also accommodates the user’s response to deny access as circumstances require it.

The cross verification tost utility CV 710 (which may also he called an “administrative company" 710 in some embodiments) may include one or more servers 712 through 720, each containing programmed instructions in non-transitory memory (not shown) for performing the depicted functions. The cross verification trust utility CV 710 preferably includes a distributed database network 730 formed by a distributed network of database elements 731 , 733, 733, 737, and 739 in tills example, each database element being connectable to each other database element in the distributed database network 730. A database is a collection of data organized to accommodate a variety of subject matter, arranged to enable convenient access and/or other processing functions. The distributed database network 730 (identically, a trust utility database 730} may be configured as a distributed ledger system as in a biockchaln or as In an alternative that is not a biockchaln perse but a distributed ledger or other data network that may function at least in part in the manner of a biockchaln, but which differs In significant ways. An example of the latter type of distributed ledger is the so called R3 Corda, Other examples may include Examples of a biockchaln include tie well-known Ethereum and Hypertedgef Fabric.

Figure 7 depicts the modifications to the trust utility CV 710 according to the present invention that provide the technological improvement, heretofore not previously available, to a computer-implemented system operated according to specific new programmed instructions that provides the novel advancement in the state of the art for cross verifying user or client identification Information, particularly among on-line entities or on-line and physically-embodied entities having a physical address at a real estate location. Figure 7 also depicts other entities that typically interact with the cress verification trust utility CV 710 through links or connections that are assigned numeric identities in Figure 7. These numeric Identities represent paths or operations taking place in one example ot a sequence for cross-verifying a user or client’s digital unique identifier, user ID, biometric Identification data, etc. These connections or linkages are labeled with the numerals 1 through 13 in Figure 7, in one example depicted In Figure 7, a user or client 750, using a laptop computer configured for operation in the system 700 may, at some previous time have entered ~ ie,, registered - via path #1 his or her identification information and personal, private, or business documents along with affirmation of their authenticity {verification} into the records of an entity represented as“company A* 760. Thus company A 760 may be said to have "captured* the user’s information, This information may be processed in a computer system 762 of company A and stored in a database 764 linked to computer system 762 in company A 760. At a subsequent time, the sequence to be described begins at the“Enter* symbol 708 via the path #2, for example when an entity“Company 8” 770. perhaps contacted by the user or client 750, or engaged in furthering a business activity or transaction of or associated with user or client 750, desires to verify the identity of user or client 760, or information provided by user or client 750, to company 8770 by communicating with company A, The processes employed in the system 700 to accomplish this objective are described and illustrated in Figure 8, The sequence for carrying out these processes may proceed as depicted in Figure 7 and described as follows.

Company B 770 in path #3 forwards a request to CV 710 for obtaining ID- proof documents of user 750 along with providing a“requester verification address5 from company B 770 to the CV 710 at server 712 to process the request. The request is then sent by server 712 along path #4 to the user 760, with the “requester verification: address’’ of company B, for approving company B's request for the user’s ID proof document. The user 750 can respond, in this example, in one of too ways, either by (a) submitting along path #5a the user’s approval and the requester verification address5 or by (b) submiting the biometric identification information along path #5b to a biometric authentication server 714 in the CV 710 for authenticating the users identity. in alternative (a) the submission reaches server 718 along path # 6 to create a smart contract that may be signed: with the user’s private key (stored in the user or client’s computer system 752} corresponding to an approver verification address of the user or client 750. The contract may include an“approver address'’, which Is the user's verification address; and a“requester address*, which is company B’s verification address. In alternative (b) the user submits his or her biometric Identification data along path #5b to the server 714 to perform a biometric authentication. Whether the user 750 submitted his or her biometric identification Information along path 5b to server 714, and the biometric authentication is affirmed (passes) along path #7, or a smart contract was created, signed with the user's private key, and sent along path # 8 to server 716, the smart contract Is then sent along path #8 to the server 718, to forward the created and signed smart contract via path #9 to the validation network in the CV 710.

The validation network in the CV 710 may preferably be a distributed database 73Q formed by a plurality of database nodes connected to each other in the network. Whether the distributed; database 730 is configured as a distributed ledger in a bSockchaln-based ledger or a non-biookohaln-based ledger, the distributed ledger operates to validate the smart contract and record the smart contract, to thereby release the verified documents of the user or client 750 to company B, followed by sending along path #10 the validated smart contract within CV 710 at server 720 to process tie delivering of the user’s Identification documents (denoted in Figure 7 by the numeric #1 1. The delivery of the user's or client's ID-proof documents proceeds along path # 12 to company A 780 for storage therein, e.g, database 764. Subsequently the ID-proof documents of the user or client 750 may be provided by company A 760 to fulfill the request of company 8 770 via path # 13. This completes the exemplary process performed by the CV 710,

(112) The distributed ledger can vary from a general distributed database as follows: (a) the control of the read/write access is truly decentralized and not logically centralised as for other distributed databases, and as a result (b) there is an ability to secure transactions in competing environments, without trusted third parties. Distributed ledgers structures can be linear, such as biookchain, or incorporate Directed Acyclic Graphs (DAG), such as iota Tangle, Biockcbain, iota Tangle, and Hedera Hashgraph, are specific instances of a distributed ledger, having respective predefined formats, algorithms, and access protocols.

(113) Biockcbain is a distributed ledger capable of chronologically storing cryptographic bitcoin electronic money (C8EM) transactions, in a biockcbain ledger, all C 8 E’ vljra n s a cti c n s are periodically verified and stored in a "block” that is linked to the preceding block via a cryptographic hash. The biookchain ledger is publicly viewable, allowing the genera! public to view and keep track of C8EM transactions. Each network node can receive and maintain a copy of the biookchain.

Cross verification requiring user or client approval frequently exists in private industry, where some type of identification verification must be used to confirm client approval. For example, other methods of verifying user Identity than those described above may Include without limitation a text message (SMS) code, biometric authentication, voice recognition, security questions, going on-line to utilize bank verification (as when requested by a third party to verify one’s identification), or any other type of identity verification.

In an alternative embodiment or example of use, the present system may be used to facilitate the transfer of data without user or client approval when it is not required. This situation may arise when the request for ID verification originates from a government or a government agency to another government or agency, such as those cases when !aw or regulations do not permit toe government or agency to request authorization from toe user or client A modified security process may foe required for transferring documents when one of the entities is an On-Line company to limit the information that might come Into the hands of one who succeeds in hacking into the on-line company's system. One example to provide limited access may proceed in two stages as follows, when the on-line company needs to confirm a client’s identity. The on-line company may request a message“Verified” or“Not Verified’' from the trusted party that includes the client's name and a unique identification number. The unique identification number may, for example, be randomly generated at the time the client completes a registration process at the trusted party’s office. Even though the client may agree to transfer all of the information requested, the on-line company may obtain partial information in stages, in stage one, the requesting on-line party may receive only the client's name, unique Identification number, and a text message "Verified* or "Not Verified,” In stage two, the requesting on-line party will request the remaining client information such as AML-type identification Information and/or KYC information to confirm or authenticate the client’s identity.

Although the present technology has been described in detail for the purpose of illustration based on what is currently considered to be the most practical and preferred implementations, it is to be understood that such detail is solely for that purpose and that the technology is not limited to the disclosed implementations, but, on the contrary, is intended to cover modifications and equivalent arrangements that are within the spirit and scope of the appended claims. For example, it is to be understood that the pre sent technology contemplates that, to the extent possible, one or more features of any implementation can be combined with one or more features of any other impiementation.

Claims

Claims:
1. A system for securing verified user documents of a user held by a primary entity and associated with user identification information in a trust utility database, wherein a requesting or secondary entity can obtain access to the verified user documents upon authorization by the user, comprising in combination: a distributed ledger formed by a plurality of computer-implemented nodes connected in a network and configured by programmed instructions stored in respective non- transitory memory units, thereby establishing the trust utility database; wherein the distributed ledger at each node includes a permission layer, a bloekchain layer, an identification file storage layer, an API processing layer; and a suite of programmed instructions operative within each of the computer- implemented nodes enables access by a requesting entity only upon validation of the user’s identify' with the verified documents information of the user
2. The system of Claim 1 , wherein the permission layer comprises: one or more processes configured for receiving a request for access to the verified user documents by a requesting party.
3. The system of Claim 1, wherein the bloekchain layer comprises: one or more processes configured for creating and signing smart contracts with the user's private key information,
4 The system of Claim 1 , wherein the identification file storage layer comprises:
Hon-transitory memory locations and associated storage functions for storing the user Identification information including anti-money laundering (AML), know your customer (KYC), and biometric identification data.
5. The system of Claim 1 , wherein the API processing layer comprises: an application programming interface responsive to access requests by trusted companies via fixed and mobile computing devices.
6. The system of Claim 1, wherein the suite of programmed instructions comprises: one or more application program segments operable for processing ID-proof document requests, receiving and verifying user identification data, creating, signing and validating smarts contracts, processing requests to grant or deny access, and delivering user ID-proof documents to a requesting trusted company.
7. The system of Claim 1 , wherein further comprising: a scaling layer configurable in the distributed ledger for expanding the capacity of the system.
8. A cross verification (CV) trust utility configured for verifying, on behalf of a requesting first trusted company, the user !D information associated with verified documents of the user held by a second trusted company having previously received and verified the user ID information and verified user documents, comprising in combination: an assembly of one or more servers operable according to programmed instructions stored in non-transitory memory locations; a distributed database coupled to the assembly of one or more servers and configured as a distributed ledger formed by a plurality of computer operated databases located at respective nodes of a network, thereby forming a trust utility database; and communication links from the cross verification trust utility with the first and second taisted companies and the user whose user ID information forms the subject matter of process steps for verifying the user ID Information associated with the user’s verified documents. 9, The cross verification trust utility of Claim 8» wherein the programmed instructions comprise process steps operable to: process ID-proof document requests from the first trusted company; process authentication of biometric Identification information about the user; create and process execution and delivery of a smart contract to the distributed database; and deliver ID-proof documents held by the second trusted company to the first trusted company authorized by the smart contract.
10 The cross verification trust utility of Claim 8, wherein; the parties to the smart contract, the first trusted company and the user associated with the user's verified documents, are identified by their respective pequastefs verification address and approver’s verification address.
11, The cross verification trust utility of Claim 8» comprising the step of provision by the second trusted company of the user’s ID-proof documents to the requesting first trusted company.
PCT/US2018/029371 2016-10-26 2018-04-25 Systems and methods for providing a universal decentralized solution for verification of users with cross-verification features WO2019209291A1 (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
US15/961,647 2018-04-24
US15/961,647 US20180343120A1 (en) 2016-10-26 2018-04-24 Systems and methods for providing a universal decentralized solution for verification of users with cross-verification features

Publications (1)

Publication Number Publication Date
WO2019209291A1 true WO2019209291A1 (en) 2019-10-31

Family

ID=68294214

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2018/029371 WO2019209291A1 (en) 2016-10-26 2018-04-25 Systems and methods for providing a universal decentralized solution for verification of users with cross-verification features

Country Status (1)

Country Link
WO (1) WO2019209291A1 (en)

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20160330027A1 (en) * 2015-05-05 2016-11-10 ShoCard, Inc. Identity Management Service Using A Blockchain Providing Certifying Transactions Between Devices
US20170024579A1 (en) * 2013-10-01 2017-01-26 Trunomi Ltd Systems and Methods for Sharing Verified Identity Documents
US20170222814A1 (en) * 2015-10-14 2017-08-03 Cambridge Blockchain, LLC Systems and methods for managing digital identities
US20170279801A1 (en) * 2016-03-28 2017-09-28 Black Gold Coin, Inc. Systems and methods for providing block chain-based multifactor personal identity verification
US20170316390A1 (en) * 2016-04-30 2017-11-02 Civic Technologies, Inc. Methods and systems of revoking an attestation transaction using a centralized or distributed ledger
WO2018007828A2 (en) * 2016-07-08 2018-01-11 Kalypton International Limited Distributed transaction processing and authentication system
US20180075247A1 (en) * 2016-09-09 2018-03-15 Tyco Integrated Security, LLC Architecture For Access Management

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20170024579A1 (en) * 2013-10-01 2017-01-26 Trunomi Ltd Systems and Methods for Sharing Verified Identity Documents
US20160330027A1 (en) * 2015-05-05 2016-11-10 ShoCard, Inc. Identity Management Service Using A Blockchain Providing Certifying Transactions Between Devices
US20170222814A1 (en) * 2015-10-14 2017-08-03 Cambridge Blockchain, LLC Systems and methods for managing digital identities
US20170279801A1 (en) * 2016-03-28 2017-09-28 Black Gold Coin, Inc. Systems and methods for providing block chain-based multifactor personal identity verification
US20170316390A1 (en) * 2016-04-30 2017-11-02 Civic Technologies, Inc. Methods and systems of revoking an attestation transaction using a centralized or distributed ledger
WO2018007828A2 (en) * 2016-07-08 2018-01-11 Kalypton International Limited Distributed transaction processing and authentication system
US20180075247A1 (en) * 2016-09-09 2018-03-15 Tyco Integrated Security, LLC Architecture For Access Management

Similar Documents

Publication Publication Date Title
US7865937B1 (en) Methods and systems for authenticating users
US9665868B2 (en) One-time use password systems and methods
US10042993B2 (en) Access control through multifactor authentication with multimodal biometrics
AU2003212617B2 (en) A biometric authentication system and method
CA2734206C (en) Methods and systems for authenticating users
US20170046638A1 (en) Systems and Methods for Monitoring Referrals
US20170132615A1 (en) Block chain alias for person-to-person payments
ES2554686T3 (en) Device, system and method for registering and authenticating handwritten signatures and archiving handwritten information
US20110270761A1 (en) Methods and apparatus for a financial document clearinghouse and secure delivery network
US7690032B1 (en) Method and system for confirming the identity of a user
US8874909B2 (en) System and method of storing data
US10333706B2 (en) Methods and systems of providing verification of information using a centralized or distributed ledger
US20110035788A1 (en) Methods and systems for authenticating users
US9391986B2 (en) Method and apparatus for providing multi-sensor multi-factor identity verification
US10340038B2 (en) Healthcare transaction validation via blockchain, systems and methods
US9667427B2 (en) Systems and methods for managing digital identities
AU2016376097B2 (en) Methods and systems for identity creation, verification and management
US20170140408A1 (en) Transparent self-managing rewards program using blockchain and smart contracts
US9596089B2 (en) Method for generating a certificate
US20120110341A1 (en) Mobile Device Transaction Using Multi-Factor Authentication
AU2016206301A1 (en) Methods and systems for authenticating users
US20180152304A1 (en) User Identification Management System and Method
US20130318361A1 (en) Encrypting and storing biometric information on a storage device
ES2692871B2 (en) Systems and procedures to provide a multifactorial personal identity verification based on a block chain
US20060010487A1 (en) System and method of verifying personal identities

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 18916213

Country of ref document: EP

Kind code of ref document: A1