Systems and methods for preventing bot access to computer resources

Abstract

Aspects of this disclosure relate to the steps of receiving a request from a remote device for access to a computer-based online service and sending a request for a verifiable token to the remote device. The verifiable token encodes verifiable credentials that include the issuer's digital signature and an identifier indicating that the holder of the verifiable credentials is human. If a verifiable token is not received, access to the computer-based online service is blocked. If a verifiable token is received, its validity is verified using the associated public key. If validity is verified, it is determined that the request from the remote device for access to the online service is from a human, and the remote device is allowed to access the computer-based online service.

Description

Technical Field

[0001] Incorporation by Reference of Priority Applications All applications for which foreign or domestic priority claims are identified in the application data sheet filed together with this application are incorporated herein by reference pursuant to 37 CFR 1.57 (Title 37, Code of Federal Regulations, Rule 1.57).

[0002] Copyright Notice Portions of the disclosure of this patent document contain material that is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by the United States Patent and Trademark Office of the patent document and / or patent disclosure, as it appears in the patent file and / or records, but reserves all other copyrights.

[0003] The present disclosure generally relates to systems and methods for securely determining whether an entity accessing networked resources is a human (rather than an automated program).

Background Art

[0004] As networked computer resources become increasingly important, proportionally, the use of automated programs (e.g., bots) for unauthorized access to such networked computer resources has been increasing.

[0005] Conventional attempts to solve the technical and other problems posed by automated programs for unauthorized access to such networked computer resources have not provided satisfactory solutions.

[0006] For example, websites have traditionally used CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart), a type of security measure known as challenge-response authentication, to prevent bots from accessing their website services. However, CAPTCHA can be time-consuming and difficult for humans. Furthermore, more sophisticated automated programs are equipped with artificial intelligence capabilities that enable them to successfully respond to CAPTCHA questions.

[0007] Embodiments are described here with reference to the drawings summarized below. These drawings and related descriptions are provided to illustrate exemplary aspects of the present disclosure and do not limit the scope of the invention. [Brief explanation of the drawing]

[0008] [Figure 1A] Figure 1A shows an example of a networked environment architecture. [Figure 1B] Figure 1B shows an example of a system architecture. [Figure 2] Figure 2 shows an example of the process. [Modes for carrying out the invention]

[0009] This document describes a system and method for accurately and efficiently determining whether a user attempting to access computer resources is a human or a bot (an autonomous program configured to interact with systems and users via a network such as the internet).

[0010] As services and products increasingly become available through networks such as the internet, the use of bots attempting to misuse and illegally obtain these services and products is increasing proportionally.

[0011] For example, event tickets (which grant users the right to attend a ticketed event and, in some cases, to use specific assigned seats) are inherently limited in quantity and are often purchased in bulk using numerous high-speed ticket bots operated by scalpers. In fact, the majority of tickets are purchased online by automated software with the intention of reselling them later at a price far higher than their face value. The use of such automated software deprives consumers of the opportunity to purchase tickets at face value. Furthermore, such automated software can overload ticket servers that sell these tickets, delaying responses to legitimate consumers and requiring ticket sites to utilize increasingly greater computing resources to manage the heavy load of ticket requests.

[0012] Traditional attempts to address the technical and other challenges posed by ticket bots (including legal and technical approaches) have not provided satisfactory solutions.

[0013] For example, as mentioned above, ticket websites have traditionally used CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart), a type of security measure sometimes called challenge-response authentication. However, responding to CAPTCHA questions can be time-consuming and difficult for humans, often requiring multiple attempts to satisfactorily answer them. Furthermore, more sophisticated bots are equipped with artificial intelligence capabilities that enable them to successfully respond to CAPTCHA questions.

[0014] Therefore, a technical solution is needed that can accurately determine whether an entity accessing network resources is actually a human being and not a bot.

[0015] One aspect of this disclosure relates to the use of decentralized identifiers to determine whether an entity accessing computer resources, such as an event ticket sales website or other online service, is a human or a bot. Optionally, such entity does not need to log in to an account on the ticket sales website (although the entity may log in to a user's account) or solve a CAPTCHA to access the computer resources; rather, it is verified as human using a verifiable certificate that includes a decentralized identifier.

[0016] One aspect of this disclosure relates to a decentralized identifier, including a verifiable decentralized digital identity associated with a human being. Advantageously, the decentralized identifier is optionally decoupled from a certificate authority, a centralized registry, and / or an identity provider (and therefore cannot be revoked by such a certificate authority). Optionally, the decentralized identifier architecture allows a controller of the decentralized identifier to prove that it controls the decentralized identifier without requiring authorization from a third-party authentication entity (but optionally, other entities may be used to assist in accessing data associated with the decentralized identifier). The decentralized identifier may optionally include a namespace component that identifies a decentralized identifier method. A decentralized identifier method specification specifies the format of the method-specific identifier. Optionally, the decentralized identifier identifies that its holder is a human being (not an automated program) but does not provide the human's identity (e.g., name or other personal identifier).

[0017] Optionally, the distributed identifier may include a uniform resource identifier (e.g., a uniform resource locator (URL)) that associates an object (e.g., a person) with the distributed identifier document, enabling trusted interactions associated with the person. For example, the distributed identifier document (optionally, may be fully self-describing) may include a set of data describing the person, the set of data optionally including a cryptographic public key, which the person (or agent) can use to authenticate themselves and prove their association with the distributed identifier (however, the distributed identifier may indicate that the holder is a person without providing the holder's identity). The distributed document may include proof purposes, verification methods, and service endpoints. For example, the document may specify a particular verification method, such as a cryptographic public key or pseudonym biometric protocol, which may be used to verify a proof created for the purpose of authentication. The service endpoint may be used to enable trusted interactions with a distributed document controller.

[0018] In particular, the distributed identifier document may include the distributed identifier itself, a set of cryptographic materials (such as a public key) that can be used to authenticate or interact with the distributed identifier subject, a set of cryptographic protocols for interacting with the distributed identifier subject (e.g., authentication or delegation of authority), a set of service endpoints describing how to interact with the distributed identifier subject, a timestamp, and / or a signature (which may be optionally used to verify the integrity of the distributed identifier document (such as a JSON-LD identifier)). Thus, a distributed identifier (DID) can be a globally unique reference linking to a distributed identifier document, such as "did:<DID method> :<method-specific identifier> The DID method (a specific description of how DIDs are resolved and how DID documents are written and updated in a particular blockchain (e.g., a distributed ledger) or peer-to-peer network) includes a reference to a particular distributed ledger or network (e.g., a blockchain), and the method-specific identifier enables the resolution of the DID within that reference. Thus, given a distributed identifier, the referenced distributed identifier document can be retrieved.

[0019] The DID may be part of a verifiable certificate. Verifiable credentials may include cryptographically secure and privacy-respecting machine-readable credentials. Verifiable credentials may be linked to an identity. The verifiable credentials may optionally be stored off-chain in the user's digital wallet and signed with the issuer's decentralized identifier stored on the blockchain. The user's security and privacy are further enhanced because the verifiable credentials are not stored on the blockchain. The verifiable credentials may be encoded as a token (e.g., a JSON Web token) containing the issuer's digital signature (signed with the issuer's private key), thereby providing a DID token that enables easy verification. The issuer's public DID and associated public key may also be stored on the blockchain.

[0020] The decentralized identifier may optionally be a pairwise pseudonym, thereby functioning as a private identifier issued for each relationship. Therefore, rather than using a single decentralized identifier across multiple services (e.g., websites), the decentralized identifier may optionally be used only in a single service (e.g., a ticket sales website). Optionally, the decentralized identifier token may be a one-time use DID token and / or a time-limited DID token (e.g., the decentralized identifier token is valid only for a predetermined period, such as 5, 10, 15 minutes, or a range of 3 to 60 minutes), thereby deterring the holder from sharing the DID token with others who wish to behave as the holder (or generally, a person).

[0021] Optionally, a person / user may possess a certificate signed by the DID token, and such certificate may optionally be stored in the user's digital wallet under the user's control. The issuer of the certificate may guarantee the authenticity of the certificate. Optionally, instead of identifying the identity of the person / user to the recipient / verifier of the certificate, the certificate identifies the holder of the certificate as a human being without providing the holder's identity (e.g., without providing a name, email address, and / or other personally identifiable information). Optionally, instead of (or in addition to) storing the certificate in a wallet, the user may provide the certificate to the verifier via an application downloaded to the user's device almost immediately after the certificate is generated (within 5, 10, 15, 30, or 60 minutes after the certificate is generated). For example, the application (which may be called, e.g., a ticket sales application) may be associated with an event ticket entity and used to search for and retrieve event tickets. Optionally, a user does not need to have an account with the event ticket entity to use the application to generate or receive a certificate.

[0022] For example, an issuing authority (e.g., a trusted issuing authority) may issue a certificate to a holder (e.g., a consumer, citizen, or other entity) containing a decentralized identifier digitally signed and authenticated by the issuer. For example, the issuing authority may be a government agency, a credit bureau, a third-party authentication service (e.g., a biometric authentication service), and / or similar entities. Optionally, the issuing authority may also function as a verification authority. Optionally, the issuing authority may verify the identity and / or humanity of an entity and issue an identifier of one (or more) attributes of the holder, signed by the issuer. For example, the issuer may present a set of challenge questions (difficult or impossible for an automated program to answer correctly) to an entity requesting the issuing authority to issue a certificate. The entity must correctly answer a predetermined number / percentage of questions in order to be verified as human. The issuer has the answers to the questions. For example, the questions may ask the entity for personal data about the human being the entity is impersonating. For example, the questions may relate to a mortgage held by the person (e.g., the lender of the mortgage, the amount of the mortgage, the start date of the mortgage, etc.). As a further example, the questions may relate to a ticketed event attended by the person. As a further example, the questions may relate to the person's employment (e.g., current employer, job title, start date, etc.). As a further example, the issuer may ask the entity to perform a task that is difficult for an automated program to perform.

[0023] When it is verified that the entity is a human (in response to the entity correctly answering the predetermined number of challenge questions), the issuing authority may issue to the user a verifiable "humanness" certificate including a decentralized identifier. The issuer of the qualification information confirms that the proof provided by the user is accurate and creates verifiable qualification information signed with the issuer's DID for the user's DID. The DID may be configured to personally identify the user, or the DID may be configured to indicate that the user is a human without personally identifying the user.

[0024] The decentralized identifier may be stored in a digital wallet associated with the holder. The digital wallet may be in the form of a wallet application downloaded to a user device (such as a mobile device such as a smartphone). The digital wallet may be part of a ticket sales application. The digital wallet application may provide encryption of personal data and / or transactions regarding items (such as identifiers, private keys, and / or other items) stored in the digital wallet.

[0025] Optionally, the digital wallet may be stored on a server and accessed via a browser hosted on a user device. Optionally, in addition to the decentralized identifier, the digital wallet may store digital currency (such as cryptocurrency / cryptocurrency private key), and / or other financial products that can be used for financial transactions.

[0026] The digital wallet may optionally store user information (e.g., provided by the user and / or input from other data sources) (e.g., may be stored on the client side and / or the server side). User information may include, for example, a mailing address, a billing address, a mobile phone number, payment means data (e.g., credit card or debit card number, expiration date, security code, and / or the like), and other information.

[0027] The holder may use the decentralized identifier to obtain goods and / or services from a verifier (e.g., a ticket sales website, an online e-commerce store, a government agency, etc.). As an example, the holder / user may use the decentralized identifier stored in the digital wallet to verify that the holder is a human in order to purchase a ticket (e.g., an event ticket that may grant the user the right to enter a venue and participate in an event such as a concert, a sports event, a play, a movie, and / or other events, and may grant the right to use a specific seat in the venue) from a ticket source such as a ticket sales website.

[0028] For example, if a user / holder of a decentralized identifier wishes to purchase a ticket from a ticket sales website, the digital wallet may send a secure, digital, one-time-use, verifiable token signed with the user / holder's decentralized identifier. Optionally, the token may be used solely to verify the authenticity of the holder (therefore determining that the holder is a human) and that the identifier is valid and in good condition. The verifiable token may, in addition to or instead of this, have a time-limited expiration date (e.g., if the decentralized identifier is only valid for a predetermined period, such as 5 minutes, 10 minutes, 15 minutes, or a range of 3 to 60 minutes). Thus, by limiting the token to one-time use and / or within a predetermined time, the holder is deterred from successfully sharing the token with others who wish to behave as that holder (or generally, a human).

[0029] For example, when a user accesses an event ticket sales webpage and begins the ticket selection and / or purchase process, the ticket sales website may present an optical code (e.g., a QR code or other barcode type) containing a link to the user's first device. Optionally, the optical code includes a timestamp. Optionally, the optical code is periodically updated (e.g., every minute, every three minutes, every five minutes, or at other intervals) with a new optical code (optionally including a new timestamp). The optical code with a given timestamp becomes invalid when a new optical code is generated, thereby preventing screenshots from being used in subsequent processes. The user may scan the optical code using the camera of their second device (e.g., a mobile phone camera). The user device may also host the digital wallet that stores the certificate of authenticity (e.g., corresponding to the decentralized identifier). The certificate may be associated with a unique digital wallet identifier. In response to the user activating a notification presented in response to scanning the optical code, the user device may transmit the decentralized identifier and / or verifiable credentials to the ticket sales system (e.g., encoded in a verifiable token). Optionally, a copy operation may be performed on the user device presenting the optical code rather than capturing an image of the optical code using a camera (e.g., depending on whether the user enables copy control). The user may copy / paste the code into an application receiving field (e.g., the wallet, which may be part of the ticket sales application) and then transmit the decentralized identifier and / or verifiable credentials (e.g., encoded in a verifiable token) to the ticket sales system. Optionally, instead of using an optical code in the aforementioned process, an alphanumeric code may be presented and used.

[0030] The unique digital wallet identifier may be signed using a private key and optionally protected by biometric authentication (e.g., facial recognition or fingerprint authentication) and / or a PIN code known only to the holder (or the holder's agent). The uniquely associated public key may be published (recorded) in a synchronized decentralized database or a decentralized ledger consisting of one or more peer-to-peer networks. Therefore, if an entity attempts to use the certificate with a different digital wallet (having a different wallet identifier than the wallet identifier to which the certificate is associated), the verification of the certificate will fail. For example, if a user lends their certificate containing a decentralized identifier to a friend, and the friend attempts to store the certificate in their wallet, the friend's use of the certificate will fail verification. Similarly, if a user loses their mobile device on which their digital wallet is stored, the user will need to redownload the digital wallet application to a new mobile device (having a new unique digital wallet identifier) ​​and obtain a new verifiable certificate of human identity (e.g., verifiable credentials) from the issuer. Therefore, multiple technologies may be used individually or in combination to deter the use of the token by persons other than the holder (for example, by associating the token with the holder's wallet, making the token a one-time use token, or setting a time-limited expiration date for the token).

[0031] Advantageously, the blockchain functions as a public, distributed, and verifiable data registry. Therefore, the use of a public blockchain eliminates the need to store identifiers in a centralized registry. If someone (for example, a ticket sales service) wants to verify the validity of a distributed identifier, they can look up the associated public key on the blockchain rather than requesting authentication from a third party.

[0032] In particular, the optical code (or alphanumeric code) may optionally include a specific request for a human-verifiable certificate (human-verifiable credentials). Optionally, the request for certificate verification may be presented via the user's mobile device (e.g., in connection with authorization or other permission controls). Depending on whether the user enables the corresponding control, the public key may be transmitted from the user's device to the ticket sales system server. The ticket sales system may then verify the credentials by comparing the public key with one recorded in the distributed ledger. The public key identifies the controller of the account, and the private key can sign and decrypt messages. Thus, a public key infrastructure (PKI) can be used to authenticate entities, provide proof to prevent impersonation and the use of false identities, and verify claims using cryptographic signatures.

[0033] Optionally, if the verification fails (for example, if a user attempts to use a friend's personal identifier), the issuer may immediately revoke the certificate of authenticity, thereby preventing misuse of such certificates.

[0034] Automated programs, lacking such proof of human identity, cannot fraudulently book and / or purchase tickets.

[0035] Optionally, the ticket purchase process may include a virtual waiting room. For example, if a user accesses a specific ticket sales webpage for an event for which tickets have not yet gone on sale, that user may be placed in a virtual waiting room. For example, the virtual waiting room may be open for a predetermined period (e.g., 30 or 60 minutes) before the start of ticket sales. Optionally, CAPTCHA may be used as an initial filter for ticket bots. Even if this technique is not entirely effective, it reduces the size of the queue of ticket requests after sales begin (certain bots that cannot solve the CAPTCHA may be filtered out), reduces the number of requests for proof of human identity, and thus reduces the load on the ticket sales system and the network. Then, once sales begin, those remaining in the virtual waiting room may be required to provide proof of human identity as described above.

[0036] Optionally, even if a user does not possess a human identity certificate, they may still be allowed to purchase a ticket, but they may be given a lower queue position (for example, their ticket purchase request may be placed lower in the ticket purchase queue than ticket purchase requests associated with a human identity certificate that was submitted at a later time but has been verified).

[0037] Next, we will explain specific aspects with reference to the diagram.

[0038] Figure 1A shows an example of a networked architecture and the associated processes. The illustrated networked architecture includes an issuing system 102, a holder device 104, a validator system 106, and a distributed synchronous database 108 (e.g., a distributed ledger such as a blockchain utilizing a large number of distributed servers) and / or a peer-to-peer network. Optionally, the issuing system 102 and the validator system 106 are the same system.

[0039] For example, the issuing authority system 102 and / or the verifier system 106 may each include one or more servers. The issuing authority system 102 and / or the verifier system 106 may optionally include a cloud-based system that includes a hosted computing environment, which includes a collection of physical computing resources that are remotely accessible and can be rapidly provisioned as needed. Furthermore, the issuing authority system 102 and / or the verifier system 106 may include or utilize a hosted storage environment (sometimes referred to as “cloud” storage), which includes a collection of physical data storage devices that are remotely accessible and can be rapidly provisioned as needed. Such cloud storage may be used to store some or all of the data, programs, and / or content described herein. Some or all of the data stored therein may be encrypted. The various systems / devices may communicate with each other over one or more networks, such as the Internet, other wide area networks, local area networks, or other networks.

[0040] The holder device 104 may include mobile devices such as a mobile phone, tablet computer, network-enabled wearable device (e.g., network-enabled smartwatch, glasses (e.g., virtual reality or augmented reality headset)), portable game console, or other mobile computer device. Further examples may include a desktop computer, network-enabled television, or other computer system. As described elsewhere in this specification, the holder device 104 may host a digital wallet application that may be associated with a unique digital wallet identifier. The holder device 104 may include a display (e.g., a touchscreen) configured to display a user interface or other content, a speaker, a microphone, one or more cameras, and one or more network interfaces (e.g., a cellular modem, a Wi-Fi® interface, a Bluetooth® interface, and / or similar).

[0041] In state 120, the holder device 104 (sometimes referred to as the user device) may issue a request to the issuing authority system 102 for a distributed identifier and / or a unique identifier for verifiable credentials. For example, the holder device 104 may receive a communication containing a link (e.g., an email or a message from a messaging service), and once the link is activated, the holder device 104 issues a request to the issuing authority system 102 for a distributed identifier and / or a unique identifier for verifiable credentials. For example, the issuing authority may consist of a trusted third-party authentication system (e.g., a government service, or a private service such as a credit bureau or a dedicated authentication service).

[0042] The issuing system 102 may authenticate that the entity operating the holder device 104 is a human being and not an automated program. For example, the issuing system 102 may present one or more challenge questions that would be difficult or impossible for an automated program to answer like a human. For example, the questions may be about very recent news events or require a great deal of creativity to answer. For example, the questions may be in the form of a linguistic riddle ("What is black and white and is all 'red' (a play on words with 'red' and 'read')?" "Answer: A newspaper"). As a further example, the questions may be in the form of absurd questions that would be difficult for an automated program to judge as absurd. As a further example, the challenge questions may be in the form of questions about well-known stories (without specifying the name of the story) that an automated program is unlikely to be able to answer (for example, "What color was the hood the girl was wearing when the wolf found her?"). As a further example, the challenge questions may ask about personal data of the human being the entity is impersonating. For example, a question could relate to a mortgage held by a person (e.g., the lender of the mortgage, the amount of the mortgage, the start date of the mortgage, etc.). As a further example, a challenge question could take the form of questions about a ticketed event attended by a person. As yet another example, a challenge question could take the form of questions about a person's employment (e.g., current employer, job title, start date, etc.). For the issuing authority to authenticate the entity as a person, the entity must correctly answer a predetermined number of challenge questions (e.g., all questions, or at least 4 out of 5, 7 out of 10, or any other predetermined number or percentage of questions).

[0043] If the entity is authenticated as a human, in state 120, and in state 122, a decentralized identifier may be sent to the holder device 104. The holder device 104 may automatically or, at the user's instruction, store the decentralized identifier in a digital wallet. Similarly, verifiable credentials associated with the user's decentralized identifier, signed using the decentralized identifier associated with the issuing authority, and containing a verifiable claim created by the issuer (e.g., a claim that the user is human), may also be issued by the issuing authority system 102 and stored in a digital wallet.

[0044] If a user wants to access an online service (e.g., a ticket sales service that sells event tickets), in state 126, the user may access the online service provided by the verifier system 106 (e.g., the ticket sales system). For example, the user may access the website of the online service via a browser or application hosted on device 104. The verifier system 106 may transmit an optical code (e.g., a QR code or other optical code) presented via device 104. The optical code may include a link requesting a distributed identifier and / or a verifiable certificate. The user may point the camera of device 104 at the optical code, and accordingly, a notification may be presented on the device's display. If the user enables the notification (e.g., by tapping, clicking, or selecting it with other actions), the link may be enabled.

[0045] In state 128, device 104 may transmit a decentralized identifier and / or a verifiable certificate to the verifier system. For example, device 104 may transmit a one-time, verifiable token signed with the user's / holder's decentralized identifier. This token may optionally be used solely to verify the authenticity of the holder (thus determining that the holder is human) and that the identifier is valid and in good condition. For example, verifiable credentials may be encoded as a token (e.g., a JSON Web token) that includes the issuer's decentralized identifier as a digital signature. The verifier system 106 may verify the validity of the decentralized identifier by searching for the associated public key on blockchain 108. If the verifier system 106 verifies the validity of the decentralized identifier, it may accordingly determine that the user is human and not an automated program. The verifier system 106 then allows the user to access the ticket sales service via device 104 and purchase a ticket.

[0046] If the verifier system 106 is unable to verify the validity of the distributed identifier, the verifier system 106 may, accordingly, determine that the user is not a human but is actually an automated program. The verifier system 106 may then refuse to allow device 104 to access certain ticket sales services, such as ticket reservation and / or purchase. Optionally, if the verifiable certificate and / or distributed identifier is revoked, the verifier system 106 may send a request to the issuing authority system 102 to revoke the verifiable certificate and / or distributed identifier.

[0047] Figure 1B is a block diagram showing an example of the components of the verifier system 102. The illustrated verifier system 102 includes an arrangement of computer hardware and software components used to implement aspects of this disclosure. Those skilled in the art will understand that the illustrated components may include more (or fewer) components than those shown in Figure 1B. The verifier system 102 may include a cloud-based computer system.

[0048] With respect to cloud-based computing systems, a cloud-based computing system may include a hosted computing environment (sometimes referred to as a “cloud” computing environment) which includes a collection of physical computing resources that are remotely accessible, can be located in different facilities, and can be rapidly provisioned as needed. Certain data described herein may optionally be stored using a datastore (sometimes referred to as “cloud” storage) which includes a hosted storage environment which includes a collection of physical data storage devices that are remotely accessible and can be rapidly provisioned as needed.

[0049] The verifier system 102 may include one or more processing units 120B (e.g., general-purpose processors and / or high-speed graphics processors), one or more network interfaces 122B, a non-temporary computer-readable media drive 124B, and an input / output device interface 126B, all of which may communicate with one or more communication buses. The network interface 122B may provide connectivity to one or more network or computing systems (e.g., venue systems, user devices, distributed ledgers, event promoters, seating chart visualization systems, etc.) for the services described herein. Thus, the processing unit 120B may receive communications (e.g., ticket service requests, verified tokenized credentials and / or distributed identifiers, verification / authentication data, verification / authentication requests, etc.) and instructions from other computing devices, systems or services via the network, provide response data, and / or execute instructions. The processing unit 120B may also communicate with memory 124B and further provide output information via the input / output device interface 126B. Furthermore, the input / output device interface 126B can accept input from one or more input devices such as a keyboard, mouse, digital pen, touchscreen, microphone, and camera.

[0050] Memory 128B may contain computer program instructions that processing unit 120B can execute to implement one or more aspects of this disclosure. Memory 128B generally includes RAM, ROM (and variations thereof such as EEPROM), and / or other persistent or non-temporary computer-readable storage media. Memory 128B may store an operating system 132B that provides computer program instructions for use by processing unit 120B in the general management and operation of the authentication and electronic asset management module 134B (including its components).

[0051] Memory 128B may store user accounts, which include username, user's email address, user's phone number / SMS / text message address, other electronic destinations, geographic information (e.g., physical address, postal code, city, etc.), unique user identifier (e.g., alphanumeric identifier, fingerprint data, facial data, iris data, and / or similar), unique user device identifier, event identifier corresponding to events the user has access to, hashes of user devices and / or user identifiers, user preferences (e.g., favorite performers, favorite venues, favorite music styles, other preferences described herein, and / or similar), payment method data, and / or other user data described herein.

[0052] Furthermore, memory 128B may store event, access token (e.g., ticket information), and venue information, as described elsewhere in this specification. Memory 128B may store user records of entry rights (e.g., event tickets) owned by the user (e.g., purchased by the user or transferred to the user).

[0053] Some or all of the data and content described herein may optionally be stored in relational databases, SQL databases, NoSQL databases, or other types of databases. Optionally, memory 128B may include one or more third-party cloud-based storage systems.

[0054] The Authentication and Electronic Asset Management Module 134B may include a GUI component that generates and / or inputs a graphical user interface and processes user input, and a search component (which may include a search engine used to search for ticketed events). The Authentication and Electronic Asset Management Module 134B may also include a component configured to perform authentication of a decentralized identifier to determine whether the user is a human or an automated program (e.g., a ticket sales bot). As described elsewhere in this Specification, the determination may be performed by using a token received from the user device and using the information in the token to retrieve data from a distributed ledger (e.g., a blockchain) or other location.

[0055] When a user wants to access a user account, authentication components may perform authentication via a user identifier and user password or passkey, biometric authentication, multi-factor authentication, and / or other means.

[0056] The access rights verification component may be configured to authenticate the user at the venue via data provided through the user's mobile device. For example, an application downloaded to and hosted on a mobile device may present a unique user identifier and a unique mobile device identifier (which may be encoded in a barcode (e.g., a one-dimensional barcode or a two-dimensional barcode such as a QR code)) on the user device display via wireless transmission or optical code. The access rights verification component may perform user authentication by comparing the hash of the unique user identifier and unique device identifier with one generated by the verifier system 102. As a further example, authentication may be performed by decrypting the data containing the unique user identifier and unique device identifier (e.g., using a private key or the key used for encryption) and comparing the decrypted data with one stored by the verifier system 102. Optionally, as described elsewhere in this specification, the Advanced Encryption Standard (AES), a symmetric encryption algorithm that encrypts data in fixed-length data blocks (128 bits), may be used. As a further example, optionally, RSA (Rivest-Shamir-Adleman) encryption / decryption technology may be used. As a further example, optionally, Triple DES (Data Encryption Standard) encryption / decryption technology may be used. As a further example, hash functions may be used. Optionally, in addition to or instead of these, authentication may be performed using the user's biometric authentication.

[0057] The access rights verification component may be configured to determine whether an authenticated user has access rights to the associated event at the venue (and / or part of the event venue) (for example, by accessing records associated with the user and determining whether the user obtained a ticket to the event).

[0058] The ticket sales module 136B may be configured to enable a user to view information about a ticketed event, access a seating chart of the event venue, view available and unavailable seats in the event venue, access images of the view from a given seat, view access token prices, create a user account (optionally including some or all of the user account information described herein), purchase or otherwise acquire one or more entry rights to an event (e.g., access tokens), store a display of entry rights acquired by the user (e.g., purchased by the user and transferred or lent to the user), store a display of entry rights transferred by the user to others, and / or store a display of events recommended to the user (e.g., using the user's preferences, access token acquisition history, geographical location, event sponsorship, and / or similar).

[0059] The image analysis and processing module 138B may be configured to perform image analysis (e.g., an optical display encoding encrypted authentication data), and to perform contrast enhancement, deblurring, and / or image rotation, thereby improving the decoding and decryption of images of optical displays (e.g., barcodes captured using a camera device).

[0060] Memory 128B may include interface module 130B. Interface module 130B may be configured to facilitate the construction of one or more interfaces that allow compatible computing devices to send and receive data and content to and from authentication / electronic asset management module 134B and ticket sales module 136B.

[0061] Figure 2 shows an example of the process. The process may be performed using one or more systems disclosed herein (e.g., user / holder devices, validator systems (e.g., ticket sales systems), issuer systems, distributed synchronous databases (e.g., blockchains), and / or peer-to-peer networks).

[0062] In block 202, access requests are received. For example, access requests may be received in a ticket sales system from a browser or a dedicated ticket sales application. Access requests may be to view available tickets for a ticketed event, select tickets for a ticketed event, and / or initiate the purchase process for a ticketed event.

[0063] In block 204, a request is issued for a decentralized identifier and / or verifiable credentials that indicate the user associated with the user device is human. For example, the request may be issued to the user device from a ticket sales system (e.g., acting as a verifier system). The user device may have decentralized identifiers and / or verifiable credentials stored in a digital wallet (e.g., a wallet downloaded and hosted on the user device).

[0064] In block 206, a determination is made as to whether a token (e.g., a one-time verifiable token that is signed with the user / holder's decentralized identifier and tokenizes a verifiable certificate) has been received (e.g., received from a user device in a ticket sales system). If the token has been received, in block 212, data may be retrieved from a decentralized synchronous database (e.g., a blockchain). For example, a DID token may be stored on the blockchain (however, optionally, associated verified credentials may not be stored on the blockchain for further security and privacy). The issuer's public key may be accessed from the blockchain and used to perform decryption or to determine whether a user record on the blockchain (a record that should be signed using the issuer's private key) is authentic.

[0065] In block 214, it may be determined whether the received token is genuine and whether the user is human (not an automated program such as a ticket sales bot). If the user is determined to be human, in block 216 the user can proceed to execute the ticket acquisition process.

[0066] Optionally, if the token is not authenticated, block 218 may send a request to the issuer to revoke the decentralized identifier and / or verifiable credentials.

[0067] If block 206 determines that the token was not received, the user may be subjected to adverse treatment. For example, the user may be required to successfully complete a CAPTCHA and, if present, may be placed in a lower ticket queue position. Therefore, other users who request access after the first user who did not provide a token (who provided their own token and were successfully determined to be human) may be placed higher than the first user regardless.

[0068] Optionally, the determination of human identity may be performed using biometric authentication without transmitting identity information to a verifier system, and the verifier system (e.g., a ticket sales system) may be provided with an indication of human identity. For example, when using a ticket sales application hosted on a user device having a biometric reader (e.g., a facial recognition device, fingerprint reader, iris reader, and / or similar), the application may prompt the user to use the biometric reader on the user device for user authentication. If the user is authenticated by the user device via the biometric reader, an indication of successful authentication may be provided by the user device to the ticket sales application (without actually identifying the user). Such an indication of successful authentication may then be transmitted by the ticket sales application to the ticket sales system, which may use the indication of successful authentication as proof that the user is human. The ticket sales system may then allow the user to select and / or purchase a ticket. On the other hand, if an indication of successful authentication is not received, the user (which may actually be an automated program) may be prevented by the ticket sales system from selecting and / or purchasing a ticket.

[0069] Optionally, in addition to or instead of this, multi-factor authentication technology may be used to determine the human nature of the entity requesting event tickets. For example, when using a ticket sales application or website, a user may be prompted to provide a mobile phone number. If the ticket sales system receives the mobile phone number (e.g., via the ticket sales application or website), it may send an alphanumeric code to the mobile phone number via a messaging service. The user may be prompted to enter that code in the corresponding field presented by the ticket sales application or website, either through the ticket sales application, the website, or a message sent to their mobile phone number. The ticket sales system may use the receipt of the code as proof that the user is human. The ticket sales system may then allow the user to select and / or purchase a ticket. On the other hand, if the code is not received, the user (which may actually be an automated program) may be prevented by the ticket sales system from selecting and / or purchasing a ticket.

[0070] Therefore, aspects of this disclosure relate to reliable techniques for determining whether an entity requesting access to a resource over a network is a human or an automated program, and for preventing automated programs from accessing the resource.

[0071] Next, we will discuss specific aspects, each of which can be used alone or in combination with other aspects.

[0072] The first aspect relates to a system comprising a network interface and at least one processing unit. The processing unit is operable to receive requests from a remote device via the network interface for access to a computer-based online service and to send a request to the remote device for a cryptographically verifiable token that can be used only once. The cryptographically verifiable token encodes verifiable credentials including a decentralized identifier, the decentralized identifier indicating that the holder of the verifiable credentials is a human. The verifiable credentials include the issuer's digital signature, signed with the issuer's private key, and the verifiable token does not identify the holder. The processing device is capable of determining whether the requested one-time use cryptographically verifiable token has been received from the remote device, and if it is determined that the one-time use cryptographically verifiable token has not been received from the remote device, it may, at least in part, suppress access to the computer-based online service; if it is determined that the one-time use cryptographically verifiable token has been received from the remote device, it may, at least in part, verify the validity of the verifiable credentials using the associated public key, and at least in part, depending on the verification of the validity of the verifiable credentials using the associated public key, it may determine that the request from the remote device for access to the computer-based online service is from a human, and at least in part, depending on the determination that the request from the remote device for access to the computer-based online service is from a human, it may be capable of enabling the remote device to access the computer-based online service.

[0073] The second aspect relates to the computer-based services, including event ticket sales services.

[0074] The third aspect concerns the fact that the public key is accessed from the blockchain.

[0075] A fourth aspect relates to the system being configured to display a periodically updated optical code on the remote device, the optical code encoding a link, and the verifiable token being transmitted to the ticket sales system in response to the human action.

[0076] A fifth aspect relates to the system being configured to display an optical code on the remote device, the optical code encoding a link, and the verifiable token being transmitted to the ticket sales system in response to the human action.

[0077] The sixth aspect relates to the issuance of the verifiable credentials to the person in at least part in accordance with the person providing accurate answers to factual questions specific to that person.

[0078] The seventh aspect concerns the fact that the verifiable credentials are accessed from a digital wallet.

[0079] The eighth aspect relates to the issuance of the verifiable credentials to the person by an issuing authority system associated with a government agency, a credit verification service, or a biometric service.

[0080] The ninth aspect relates to the fact that the one-time use token is a time-limited token configured to expire after a predetermined period of time.

[0081] A tenth aspect relates to a system comprising a network interface and at least one processing unit. The processing unit is operable to receive requests from a remote device via the network interface for access to a computer-based online service and to send requests for a verifiable token to the remote device. The verifiable token encodes verifiable credentials including a decentralized identifier, the decentralized identifier indicating that the holder of the verifiable credentials is a human. The verifiable token does not identify the holder. The processing unit is capable of determining whether the verifiable token has been received from the remote device, and if it is determined that the verifiable token has not been received from the remote device, it will suppress access to the computer-based online service, at least in part in accordance with that determination; if it is determined that the verifiable token has been received from the remote device, it will verify the validity of the verifiable credentials, at least in part in accordance with that determination, it will determine that the request from the remote device for access to the computer-based online service is from a human, and at least in part in accordance with that the request from the remote device for access to the computer-based online service is from a human, it will be capable of enabling the remote device to access the computer-based online service.

[0082] The eleventh aspect relates to a method performed by a computer. The method comprises the steps of: a computer system receiving a request from a remote device for access to a computer-based online service; and using the computer system, sending a request for a cryptographically verifiable token to the remote device. The cryptographically verifiable token encodes verifiable credentials including a decentralized identifier, the decentralized identifier indicating that the holder of the verifiable credentials is human. The verifiable credentials include the issuer's digital signature, signed with the issuer's private key, and the verifiable token does not identify the holder. The method comprises the steps of: using the computer system to determine whether the requested cryptographically verifiable token has been received from the remote device; if it is determined that the cryptographically verifiable token has not been received from the remote device, using the computer system to suppress access to the computer-based online service, at least in accordance with that determination; if it is determined that the cryptographically verifiable token has been received from the remote device, using the computer system to verify the validity of the verifiable credentials using an associated public key, at least in accordance with that determination; using the associated public key by the computer system to determine, at least in accordance with that the validity of the verifiable credentials has been verified, that the request from the remote device for access to the computer-based online service is from a human; and at least in accordance with that the request from the remote device for access to the computer-based online service has been determined to be from a human, that the remote device is allowed to access the computer-based online service.

[0083] The twelfth aspect concerns the public key being accessed from the blockchain.

[0084] A twelfth aspect relates to the step of displaying a periodically updated optical code on the remote device, wherein the optical code encodes a link, and in response to the human action, the verifiable token is transmitted to the computer system.

[0085] A thirteenth aspect relates to the step of displaying an optical code on the remote device, wherein the optical code encodes a link, and in response to the human action, the verifiable token is transmitted to the ticket sales means.

[0086] The fourteenth aspect relates to the issuance of such verifiable credentials to a person in at least part in accordance with the person providing accurate answers to factual questions specific to that person.

[0087] The fifteenth aspect concerns the fact that the verifiable credentials are accessed from a digital wallet.

[0088] The sixteenth aspect relates to the issuance of the verifiable credentials to the person by an issuing authority associated with a government agency, a credit verification service, or a biometric service.

[0089] The seventeenth aspect relates to the fact that the token is a time-limited token configured to expire after a predetermined period of time.

[0090] The eighteenth aspect relates to the fact that the token is a one-time valid and one-time usable token in relation to the computer-based service.

[0091] The 19th aspect relates to non-temporary computer-readable memory for storing instructions and causing a computer system comprising one or more computing devices to perform a predetermined operation when executed by the computer system. The operation includes the steps of receiving a request from a remote device for access to a computer-based online service and sending a request for a verifiable token to the remote device. The verifiable token encodes verifiable credentials including an identifier, the identifier indicating that the holder of the verifiable credentials is a human. The verifiable credentials include the issuer's digital signature, signed with the issuer's private key, and the verifiable token does not identify the holder. The operation includes the steps of determining whether the requested verifiable token has been received from the remote device; if it is determined that the verifiable token has not been received from the remote device, at least in part in accordance with that determination, restricting access to the computer-based online service; if it is determined that the verifiable token has been received from the remote device, at least in part in accordance with that determination, verifying the validity of the verifiable credentials using an associated public key; at least in part in accordance with the verification of the validity of the verifiable credentials using the associated public key, determining that the request from the remote device for access to the computer-based online service is from a human; and at least in part in accordance with the determination that the request from the remote device for access to the computer-based online service is from a human, enabling the remote device to access the computer-based online service.

[0092] The 20th aspect concerns the public key being accessed from the blockchain.

[0093] A 20th aspect relates to the operation of displaying a periodically updated optical code on the remote device, wherein the optical code encodes a link, and in response to the human action, the verifiable token is transmitted to the ticket sales system.

[0094] The 21st aspect relates to the operation of displaying an optical code on the remote device, wherein the optical code encodes a link, and in response to the human action, the verifiable token is transmitted to the ticket sales system.

[0095] The 22nd aspect relates to the issuance of the verifiable credentials to the person in at least part in accordance with the person providing accurate answers to factual questions specific to that person.

[0096] The 23rd aspect concerns the fact that the verifiable credentials are accessed from a digital wallet.

[0097] The 24th aspect relates to the issuance of the verifiable credentials to the person by an issuing authority system associated with a government agency, a credit verification service, or a biometric service.

[0098] The 25th aspect relates to the fact that the token is a time-limited token configured to expire after a predetermined period of time.

[0099] The 26th aspect relates that the token is a one-time valid and one-time usable token in relation to the computer-based service.

[0100] The 27th aspect relates to a system comprising a network interface and at least one processing unit. The processing unit is operable to receive requests from a remote device via the network interface for access to a computer-based online service, to send requests to the remote device for identity verification utilizing a biometric verification process performed by the remote device, and, if it is determined that confirmation of successful identity verification has not been received for the user of the remote device, to at least in part in accordance with that determination, to deter the remote device from accessing the computer-based service; and if it is determined that confirmation of successful identity verification has been received for the user of the remote device, to at least in part in accordance with that determination, to allow the remote device from accessing the computer-based service. The confirmation does not provide the user's identity.

[0101] The 28th aspect relates to the steps of receiving a request from a remote device for access to a computer-based online service and sending a request for a verifiable token to the remote device, wherein the verifiable token encodes verifiable credentials including a digital signature of an issuer signed with a private key and an identifier indicating that the holder of the verifiable credentials is a human. If the verifiable token is not received, access to the computer-based online service is blocked. If the verifiable token is received, the validity of the verifiable token is verified using the associated public key. If the validity is verified, it is determined that the request from the remote device for access to the computer-based online service is from a human, and the remote device is able to access the computer-based online service.

[0102] The methods and processes described herein may have fewer or more steps or states, and such steps or states may be performed in different orders. It is not necessary to reach all steps or states. The methods and processes described herein may be incorporated into a software code module executed by one or more general-purpose computers, through which they may be fully or partially automated. The code module may be stored in any kind of computer-readable medium or other computer storage device. Some or all of the above methods may optionally be incorporated in whole or in part into dedicated computer hardware. The systems described herein may optionally include a display, a user input device (e.g., a touchscreen, keyboard, mouse, speech recognition, etc.), a network interface, and the like.

[0103] The results of the disclosed method may be stored in any type of computer data repository, such as a relational database or a flat file system, using volatile and / or non-volatile memory (e.g., magnetic disk storage, optical storage, EEPROM, and / or solid-state RAM).

[0104] The various logic blocks, modules, routines, and algorithmic steps illustrated in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or a combination thereof. To clearly demonstrate the hardware and software compatibility, the various components, blocks, modules, and steps illustrated are generally described in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and design constraints imposed on the overall system. The described functionality may be implemented in various ways for each specific application, but such implementation decisions should not be construed as departing from the scope of this disclosure.

[0105] Furthermore, the various logic blocks and modules exemplified in relation to the embodiments disclosed herein may be implemented or executed by machines designed to perform the functions described herein, such as general-purpose processor devices, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs) or other programmable logic devices, discrete gate or transistor logic, discrete hardware components, or combinations thereof. The general-purpose processor device may be a microprocessor, but selectively, the processor device may be a controller, microcontroller, or state machine, a combination thereof, or similar. The processor device may include electronic circuits configured to process computer-executable instructions. In another embodiment, the processor device may include an FPGA or other programmable device that performs logical operations without processing computer-executable instructions. The processor device may also be implemented as a combination of computing devices, for example, a combination of a DSP and a microprocessor, multiple microprocessors, one or more microprocessors combined with a DSP core, or other such configurations. Although this specification primarily describes digital technologies, the processor device may primarily include analog components. The computing environment may include, but is not limited to, any type of computer system, such as a microprocessor-based computer system, a mainframe computer, a digital signal processor, a portable computing device, a device controller, or an in-device computing engine.

[0106] Elements of methods, processes, routines, or algorithms described in connection with embodiments disclosed herein may be incorporated directly into hardware, into software modules executed by a processor device, or in combination thereof. The software modules may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, hard disks, removable disks, CD-ROMs, or other forms of non-temporary computer-readable storage media. The exemplary storage media may be connected to the processor device so that the processor device can read information from and write information to the storage media. Optionally, the storage media may be integrated with the processor device. The processor device and storage media may reside within an ASIC. The ASIC may reside within a user terminal. Optionally, the processor device and storage media may reside as discrete components within a user terminal.

[0107] As used herein, conditional phrases such as “can,” “good,” “may,” “get,” “for example,” and similar phrases are generally intended to express that a particular embodiment includes certain features, elements, and / or steps, while other embodiments do not, unless otherwise understood in the context in which they are used. Therefore, such conditional phrases are generally not intended to suggest that features, elements, and / or steps are essential in one or more embodiments, nor are they intended to suggest that one or more embodiments include logic determining whether these features, elements, and / or steps are included in or performed in a particular embodiment, whether or not they include other inputs or prompts. The terms “equip,” “include,” “have,” and similar terms are synonymous, used in a comprehensive and open-ended manner, and do not exclude additional elements, features, actions, operations, etc. The term “or” is also used in a comprehensive sense (not in an exclusive sense). Therefore, when used, for example, to connect a list of elements, the term “or” means one, some, or all of the elements in that list.

[0108] Disjunctive phrases, such as "at least one of X, Y, and Z," generally indicate that an item, term, etc., may be X, Y, Z, or any combination thereof (e.g., X, Y, and / or Z), unless otherwise specified or understood in the context in which they are used. Therefore, such disjunctive phrases generally do not suggest, and should not be interpreted, that there is at least one X, at least one Y, or at least one Z in any particular embodiment.

[0109] The term “click” may be used in reference to a user selecting a control, menu selection, or similar, but other user inputs such as voice commands, text input, and gestures may also be used. User input may be provided, for example, through an interface such as a text field in which the user enters text, and / or through menu selections (e.g., drop-down menus, lists, or other arrangements that the user can select via checkboxes or other means, or a set of individually selectable icons). When a user provides input or enables a control, the corresponding computing system may perform the corresponding action. Some or all of the data, inputs, and instructions provided by the user may optionally be stored in a system data store (e.g., a database) from which the system can access and retrieve such data, inputs, and instructions. The notifications / alerts and user interfaces described herein may be provided via web pages, dedicated or non-dedicated telephone applications, computer applications, short message service messages (e.g., SMS, MMS, etc.), instant messages, email, push notifications, voice, pop-up interfaces, and / or similar.

[0110] The user terminals described herein may take the form of mobile communication devices (e.g., mobile phones), laptops, tablet computers, interactive televisions, game consoles, media streaming devices, head-mounted displays, network-enabled watches, and other wearable computing devices. Optionally, user terminals may include displays, user input devices (e.g., touchscreens, keyboards, mice, voice recognition, etc.), network interfaces, and the like.

[0111] While the above detailed description highlights, explains, and draws attention to novel features applicable to various embodiments, it should be understood that various omissions, substitutions, and modifications to the form and details of the devices or algorithms shown will not deviate from the spirit of this disclosure. Certain embodiments described herein may be embodied in forms that do not possess all the features and advantages described herein, and features may be used or practiced independently of other features. The scope of any particular embodiment disclosed herein is indicated by the appended claims rather than by the above description. All modifications that fall within the meaning and scope of the claims and their equivalents shall be incorporated within that scope.

Claims

1. Network interface and A system comprising at least one processing unit, The aforementioned processing apparatus is A request for access to a computer-based online service is received from a remote device via the network interface. It is capable of sending a request for a cryptographically verifiable token that can be used only once to the remote device, The cryptographically verifiable token encodes verifiable credentials including a decentralized identifier, the decentralized identifier indicating that the holder of the verifiable credentials is human, the verifiable credentials include the issuer's digital signature, signed with the issuer's private key, and the verifiable token does not identify the holder. The aforementioned processing apparatus is Determine whether the requested one-time use cryptographically verifiable token has been received from the remote device. If it is determined that the one-time use cryptographically verifiable token has not been received from the remote device, access to the computer-based online service may be blocked, at least in part, depending on that determination. If it is determined that the cryptographically verifiable token, which can be used only once, has been received from the remote device, then, at least in part, the validity of the verifiable credentials is verified using the associated public key, In at least part of the case, depending on the validity of the verifiable credentials being confirmed using the associated public key, it is determined that the request for access to the computer-based online service from the remote device is from a human. A system that can operate to enable the remote device to access the computer-based online service, at least in part, in response to the determination that the request from the remote device for access to the computer-based online service is from a human.

2. The system according to claim 1, The aforementioned public key is accessed from the blockchain, which is part of the system.

3. The system according to claim 1, The system is configured to display periodically updated optical codes on the remote device. The optical code encodes a link, and in response to the human action, the verifiable token is transmitted to the ticket sales system.

4. The system according to claim 1, The system is configured to display an optical code on the remote device, The optical code encodes a link, and in response to the human action, the verifiable token is transmitted to the ticket sales system.

5. The system according to claim 1, The verifiable credentials are issued to the person at least in part in response to the person providing accurate answers to factual questions specific to that person, according to the system.

6. The system according to claim 1, The aforementioned verifiable credentials are accessed from the digital wallet within the system.

7. The system according to claim 1, The verifiable credentials are issued to the person by an issuing authority system associated with a government agency, a credit verification service, or a biometric authentication service.

8. The system according to claim 1, The aforementioned one-time-use token is a time-limited token configured to expire after a predetermined period, in this system.

9. A method performed by a computer, A computer system receives a request from a remote device for access to a computer-based online service, The computer system is used to send a request for a cryptographically verifiable token to the remote device. The cryptographically verifiable token encodes verifiable credentials including a decentralized identifier, the decentralized identifier indicating that the holder of the verifiable credentials is human, the verifiable credentials include the issuer's digital signature, signed with the issuer's private key, and the verifiable token does not identify the holder. This method is The steps include: determining whether the requested cryptographically verifiable token has been received from the remote device using the computer system; If it is determined that the cryptographically verifiable token was not received from the remote device, the computer system is used, at least in part, to restrict access to the computer-based online service. If the computer system determines that the cryptographically verifiable token has been received from the remote device, then, at least in part, depending on that determination, the computer system determines the validity of the verifiable credentials using the associated public key. The steps include: using the associated public key by the computer system to determine, at least in part, that the validity of the verifiable credentials has been confirmed, that the request for access to the computer-based online service from the remote device is from a human; A method comprising the step of enabling the remote device to access the computer-based online service, at least in part in response to the determination that the request from the remote device for access to the computer-based online service is from a human.

10. The method according to claim 9, The aforementioned public key is accessed from the blockchain by a certain method.

11. The method according to claim 9, The method further comprises the step of displaying a periodically updated optical code on the remote device, The optical code encodes a link, and in response to the human action, the verifiable token is transmitted to the computer system.

12. The method according to claim 9, The method further comprises the step of displaying an optical code on the remote device, The optical code encodes a link, and in response to the human action, the verifiable token is transmitted to the computer system.

13. The method according to claim 9, The verifiable credentials are issued to the person in a manner at least in part in accordance with the person providing accurate answers to factual questions specific to that person.

14. The method according to claim 9, The aforementioned verifiable credentials are accessed from the digital wallet by a specific method.

15. The method according to claim 9, The verifiable credentials are issued to the person by an issuing authority associated with a government agency, a credit verification service, or a biometric service, in a manner that allows for such credentials to be issued to the person.

16. The method according to claim 9, A method wherein the token is a time-limited token configured to expire after a predetermined period of time.

17. The method according to claim 9, The method wherein the token is a one-time-use token that is valid only once with respect to the computer-based service.

18. A non-temporary computer-readable memory that stores instructions and, when executed by a computer system comprising one or more computing devices, causes the computer system to perform a predetermined operation, This operation is, The steps include receiving a request from a remote device for access to a computer-based online service, The steps include sending a request for a verifiable token to the remote device, The verifiable token encodes verifiable credentials including an identifier, the identifier indicating that the holder of the verifiable credentials is a human, the verifiable credentials include the issuer's digital signature, signed with the issuer's private key, and the verifiable token does not identify the holder. This operation is, The steps include determining whether the requested verifiable token has been received from the remote device, If it is determined that the verifiable token was not received from the remote device, the steps include, at least in part, restricting access to the computer-based online service; If it is determined that the verifiable token has been received from the remote device, the steps include, at least in part, verifying the validity of the verifiable credentials using the associated public key, The steps include determining, at least in part, that the validity of the verifiable credentials has been verified using the associated public key, that the request for access to the computer-based online service from the remote device is from a human, Non-temporary computer-readable memory that enables the remote device to access the computer-based online service, at least in part, in response to the determination that the request from the remote device for access to the computer-based online service is from a human.

19. A non-temporary computer-readable memory according to claim 18, The aforementioned public key is a non-temporary, computer-readable memory accessed from the blockchain.

20. A non-temporary computer-readable memory according to claim 18, The operation further includes the step of displaying a periodically updated optical code on the remote device, The optical code is a non-temporary, computer-readable memory that encodes a link, and in response to the human action, the verifiable token is transmitted to the ticket sales system.

21. A non-temporary computer-readable memory according to claim 18, The operation further includes the step of displaying an optical code on the remote device, The optical code is a non-temporary, computer-readable memory that encodes a link, and in response to the human action, the verifiable token is transmitted to the ticket sales system.

22. A non-temporary computer-readable memory according to claim 18, The verifiable credentials are non-temporary, computer-readable memory issued to the person, at least in part, in response to the person providing accurate answers to factual questions specific to that person.

23. A non-temporary computer-readable memory according to claim 18, The aforementioned verifiable credentials are accessed from a digital wallet in non-temporary, computer-readable memory.

24. A non-temporary computer-readable memory according to claim 18, The verifiable credentials are non-temporary, computer-readable memory issued to the person by an issuing authority system associated with a government agency, a credit verification service, or a biometric authentication service.

25. A non-temporary computer-readable memory according to claim 18, The aforementioned token is a non-temporary, computer-readable memory, which is a time-limited token configured to expire after a predetermined period.

26. A non-temporary computer-readable memory according to claim 18, The token is a non-temporary, computer-readable memory, which is a token that is valid only once and usable only once in relation to the computer-based service.

27. Network interface and A system comprising at least one processing unit, The aforementioned processing apparatus is A request for access to a computer-based online service is received from a remote device via the network interface. A request for identity verification using a biometric authentication verification process performed by the remote device is sent to the remote device. If it is determined that confirmation of the successful execution of the aforementioned identity verification was not received for the user of the remote device, access to the computer-based service by the remote device shall be suppressed, at least in part in accordance with that determination. If it is determined that confirmation of the successful execution of the aforementioned identity verification has been received for the user on the remote device, the system may operate, at least in part, to enable the remote device to access the computer-based service. The aforementioned verification is performed by a system that does not provide the user's identity.

Images