Time-varying representations of user credentials

Obtaining and/or validating time-varying representations for user credentials at client devices is described.

TECHNICAL FIELD

This specification generally relates to user credentials.

BACKGROUND

In certain instances, a person may be associated with a credential that, for example, permits the person to access events and/or locations.

SUMMARY

In general, one aspect of the subject matter described in this specification may include the actions of receiving a validation request from a processing system associated with a validation entity, the validation request comprising a set of alphanumeric characters, wherein the set of alphanumeric characters were derived from a time-varying representation for a credential, the set of alphanumeric characters comprising data corresponding to a key associated with a user, a credential identifier identifying the credential, and a first time at a client device. The actions also include determining that the key is associated with the credential identifier and obtaining, at the server, a second time from a timing device. Then, the actions include determining that the second time from the timing device is within a predetermined amount of time of the first time at the client device. Responsive to determining that the key is associated with the credential identifier and that the second time is within a predetermined amount of time of the first time, the actions include communicating to the processing system a validation response indicating that the credential is validated.

Some implementations involve receiving the validation request via SMS from the processing system associated with the validation entity. In some implementations, the server is co-located with the processing system associated with the validation entity.

In some implementations, responsive to determining that the key is associated with the credential identifier and that the second time from the timing device is within the predetermined amount of time of the first time at the client device, the actions include obtaining an image of the user and transmitting, to a processing system, the image of the user.

Some implementations involve querying a database using the credential identifier to obtain a record corresponding to the credential identifier and determining that the record includes the key.

In some implementations, the time-varying representation for the credential is a time-varying optical machine-readable representation. In some implementations, the time-varying representation for the credential is a time-varying code rendered as a sound signal, the sound signal having a frequency greater than 20 kHz.

Some implementations involve determining that the first time at the client device does not match the second time from the timing device. The actions further include adjusting the second time from the timing device by an offset and determining that the adjusted second time matches the first time at the client device.

In general, another aspect of the subject matter described in this specification may include the actions of obtaining a time-varying representation for a credential from a client device of a user and decoding the time-varying representation for the credential to generate a set of alphanumeric characters, the set of alphanumeric characters comprising data corresponding to: (i) a key, (ii) a credential identifier, and (iii) a time at the client device, wherein the key is associated with the user, and wherein the credential identifier identifies the credential. The actions also include transmitting a validation request to a server, wherein the validation request includes data corresponding to the key, the credential identifier, and the time. Then, the actions include receiving a validation response from the server, the validation response indicating that the credential is validated.

In some implementations, the time-varying representation for the credential is a time-varying optical machine-readable representation. In some implementations, the time-varying representation for the credential is a time-varying code rendered as a sound signal, the sound signal having a frequency greater than 20 kHz.

In some implementations, responsive to receiving the validation response from the server, the actions include obtaining an image of the user and outputting the image of the user.

In general, yet another aspect of the subject matter described in this specification may include the actions of obtaining a key associated with a user of the client device and obtaining a credential identifier associated with a credential. The actions further include, in response to receiving a user command to output the representation for the credential, performing several actions. In particular, the actions include obtaining a time, generating a set of alphanumeric characters based on the credential identifier, the key, and the time, encoding the set of alphanumeric characters to generate a representation for the credential. Finally, the actions include outputting the representation for the credential in a manner that enables a validation entity to validate the credential.

Some implementations involve encoding the set of alphanumeric characters to generate an optical-machine readable representation for the credential, receiving a user command to display the optical-machine-readable representation for the credential, and outputting the optical machine-readable representation for the credential in a manner that enables a validation entity to validate the credential.

Some implementations involve encoding the set of alphanumeric characters into a sound signal representing the set of alphanumeric characters, receiving a user command to render the sound signal representing the credential from a speaker operatively coupled to the client device, and rendering, at a speaker operatively coupled to the client device, the sound signal representing the credential.

Some implementations involve hashing the credential identifier, the key, and the time. Some implementations involve obtaining a time derived from a timing device of the client device.

In general, yet another aspect of the subject matter described in this specification may include the actions of receiving a validation request from a processing system associated with a validation entity, the validation request comprising a first set of alphanumeric characters, wherein the first set of alphanumeric characters were derived from a time-varying representation for the credential, the first set of alphanumeric characters comprising data corresponding to a key identifying a first user, a credential identifier identifying a credential, and a first time at a client device. The actions further include determining that the key is associated with the credential identifier and obtaining a second time from a timing device. The actions then include generating a second set of alphanumeric characters comprising data corresponding to the key, the credential identifier, and the second time from the timing device and determining that the second set of alphanumeric characters matches the first set of alphanumeric characters. Finally, responsive to determining that the key is associated with the credential identifier, and that the second set of alphanumeric characters matches the first set of alphanumeric characters, the actions include communicating to the processing system a validation response indicating that the credential is validated.

In some implementations, the actions further include generating a candidate set of alphanumeric characters comprising data corresponding to the key, the credential identifier, and the second time from the timing device, determining that the candidate set of alphanumeric characters does not match the first set of alphanumeric characters, and adjusting the second time from the timing device by an offset. In such implementations, generating a second set of alphanumeric characters comprising data corresponding to the key, the credential identifier, and the second time from the timing device comprises generating, at the server, a second set of alphanumeric characters comprising data corresponding to the key, the credential identifier, and the adjusted second time from the timing device.

Other features may include corresponding systems, apparatus, and computer programs, configured to perform the actions of the methods, encoded on computer storage devices.

The details of one or more implementations are set forth in the accompanying drawings and the description, below. Other potential features and advantages of the disclosure will be apparent from the description and drawings, and from the claims.

DETAILED DESCRIPTION

In some instances, it can be beneficial to generate representations of credentials for groups of users or for individuals. For additional security, it may be advantageous for such representations to vary over time (e.g., to mitigate replay attacks where a valid representation for a credential is maliciously or fraudulently repeated or delayed). As discussed herein, a time-varying representation for a credential may be a representation having a value, attribute, component, appearance and/or characteristic that changes as a function of time.

Credentials can be, for example, forms of personal identification (e.g., drivers' licenses, identity cards, passports, etc.), badges to gain entrance to a location, credentials to identify membership in a group (e.g., a graduate of a school or a professional certification, an employee of a business), tickets for entry to an event, redeemable vouchers, access badges that unlock locks and/or disable security systems such as alarms (e.g., for entry to a location), credentials for gaining access to information technology (IT) resources (e.g., credentials for logging into a computing device, network, or other computing resource, credentials for accessing an electronic file, directory, or other storage component, etc.), credentials for accessing an electronic account (e.g., credentials for accessing a bank account from a personal computing device and/or an automated teller machine (ATM)), etc. Credentials can be represented in various forms as described in detail below. For example, credentials can be represented by optical machine-readable representations and/or sound signals encoding alphanumeric codes that represent the credential. In certain aspects, credentials also may be hierarchical. For example, a first credential may generally identify an individual as an employee of Company X, while a second credential identifies the individual more specifically as an executive of Company X, and a third credential identifies the individual as the Chief Executive Officer of Company X.

Credentials can be managed by a server or collection of servers, and distributed to appropriate users' client devices. Time-varying representations for these credentials can then be outputted for evaluation by a validation entity, who confirms that the credential possessed by a given user is valid at a given time. A validation entity may be a person and/or a device that validates a credential.

Systems that generate, distribute, and validate time-varying representations for credentials are described below. First, a general description of example implementations will be described. Then, more detailed implementations are described.

FIGS. 1 to 5show sample screenshots of a scenario in which a user presents a time-varying representation for a credential to a validation entity, and the validation entity validates the representation.FIG. 1shows a screenshot100of an example mobile application on a client device for certain implementations that involve an optical machine-readable representation for a credential. In particular, the screenshot100shows a representation for a credential that could be presented by the client device of an employee to obtain access to a location associated with an employer (e.g., an office building). The screenshot100includes a caption102indicating that the representation is an “Employee ID” for “MicroStrategy Inc.” Also, the screenshot100also includes an image of the employee104, and the name and title of the employee (“John Smith, Chief Operating Officer”) in a caption106.

The mobile application on the client device may be configured to enable a user to select between, for example, different representations for the credential by inputting a gesture, e.g., swiping slider108shown inFIGS. 1 and 2. The first position of the slider108may cause the application to display an optical machine-readable representation110of the credential as shown inFIG. 1(e.g., a quick response (QR) code or bar code). As described below, the optical machine-readable representation generated at the client device varies over time. The second position of the slider108may cause the mobile application to output a sound signal from a speaker of the client device, where the sound signal encodes a code (e.g., an alphanumeric code) representing the credential. As described below, the code representing the credential generated at the client device also varies over time. In some implementations, the mobile application may provide a graphical indication210as shown inFIG. 2that the sound signal is being outputted.

Based on the position of the slider108inFIG. 1, the screenshot100includes an optical machine-readable representation for a credential110. As described below, a validation entity may operate a processing system to capture and decode the optical machine-readable representation108, for example by scanning the display of the client device (e.g., taking a photograph of the display of the client device) and decoding the optical machine-readable representation for the credential110. The validation entity can then validate the representation for the credential by communicating with a server.

FIG. 2shows a screenshot200of an example mobile application on a client device for certain implementations that involve a sound signal encoding a representation for a credential. As described below, the sound signal encoding the representation for the credential varies over time. The screenshot200includes the captions102,106, image of the user104, and slider108described above. Based on the position of the slider108inFIG. 2, the screenshot200includes a graphical indication210that a sound signal representing a credential is being outputted by the client device. As described below, a validation entity may operate a processing system to receive and decode the sound signal, for example by receiving the sound signal at a microphone of the processing system. The validation entity can then validate the representation for the credential by communicating with a server.

FIG. 3shows a screenshot300of an example of an application on a processing system operated by a validation entity for certain implementations that involve an optical machine-readable representation for a credential. In particular, the screenshot300shows a user interface that enables a validation entity to validate a representation for a credential presented by an employee to obtain access to a location associated with an employer. The validation entity could be, for example, a security guard or receptionist at the entrance to a building.

The user interface for the validation entity may enable a validation entity to select between, for example, different modes to validate different representations for credentials by inputting a gesture, e.g., selecting command buttons302,304shown inFIGS. 3 and 4. The command button304may cause the processing system to display a reticle308for scanning an optical machine-readable representation as shown inFIG. 3. The command button302may cause the processing system to receive a sound signal from a microphone of the processing system, where the sound signal encodes an alphanumeric code representing the credential. The processing system may provide a graphical indication408as shown inFIG. 4that the sound signal is being received.

Based on the selection of command button304, the screenshot300ofFIG. 3includes components that allow a validation entity to validate an optical machine-readable representation for a credential. In particular, the screenshot300includes a caption306instructing the validation entity to “Scan the QR code on the client device. Keep the QR code steady on-screen, and allow the camera to focus.” In an example operation, the validation entity orients a camera coupled to the processing system such that an optical machine-readable representation for a credential (e.g., a QR code) displayed on a client device is within a reticle308displayed on the processing system. The processing system scans and decodes the QR code to obtain a set of alphanumeric characters. The processing system then requests validation of the credential by communicating the set of alphanumeric characters to a server.

FIG. 4shows a screenshot400of an example of an application on a processing system operated by a validation entity for certain implementations that involve a sound signal encoding a representation for a credential. The screenshot400includes the command buttons302,304described above. Based on the selection of command button302, the screenshot400includes components that allow a validation entity to validate a sound signal outputted by a client device, where the sound signal encodes a representation for a credential. In particular, the screenshot400includes a caption406instructing the validation entity as follows: “To validate a credential, place phones in close proximity. The information will be transferred automatically.” In an example operation, the validation entity places a microphone coupled to the processing system such that a sound signal being output by a speaker of a client device can be received. The processing system displays a graphical indication408that the processing system is ready to receive the sound signal. The processing system receives and decodes the code encoded within the sound signal to obtain a set of alphanumeric characters. The processing system then requests validation of the credential by communicating the set of alphanumeric characters to a server.

FIG. 5shows a screenshot500of an example of an application on a processing system operated by a validation entity upon successful validation of a credential presented by a client device. After the processing system submits a validation request to the server, the server may send a validation response indicating that the credential has been validated. The processing system may then show information identifying the user associated with the validated credential as shown in screenshot500. As an example, the screenshot500includes a caption502indicating that the credential was validated as an “Employee ID” for “MicroStrategy Inc.” Also, the screenshot500also includes an image of the validated employee504, and the name and title of the validated employee (“John Smith, Chief Operating Officer”) in a caption506. In some implementations, the validation entity may perform additional validation by visually comparing the user presenting the representation for the credential on the client device with the image504displayed at the processing system. The screenshot500also includes a message508to the user (“Badge Validated!”) indicating that the credential was successfully validated.

FIG. 6shows an example system600that manages time-varying representations for credentials associated with users and groups of users, and permits a validation entity to validate the credentials for each user. As an overview, a server630communicates via a network620with client devices602,604operated by users606,608. The server630also communicates via network620with a processing system612operated by a validation entity610. The validation entity610operates the processing system612to validate time-varying representations of credentials presented by the users606,608on their client devices602,604by communicating with the server630as described below.

In operation, the server630manages and/or stores one or more credentials, associates users and groups of users with appropriate credentials, and provides the credentials to users' client devices and/or processing systems (e.g., operated by credential authorities) for validation. The server630can be any suitable computer or collection of computers executing software capable of managing, distributing, and/or validating representations of credentials for users and groups of users via a network620as described herein.

Credentials, user accounts, group accounts, and administrative accounts can be stored in a database (e.g., MySQL, PostgreSQL, MS SQL Server, MongoDB), or other suitable data structure that can be accessed by the server630. In some implementations, the server630may access the stored credentials and/or user accounts via web services such as representational state transfer (REST) style services.

As an initial step, the server630creates a credential based on input provided by a credential grantor (e.g., an employer). The credential may include a variety of information such as a credential identifier (e.g., a number or alphanumeric character string that uniquely identifies a credential), a description of an event or location, and/or one or more designated validation entities. The server630may present a suitable interface to the credential grantor for creation of credentials. For example, the server630may present a web interface through which grantors can interact via a Web browser. In other aspects, the server630may be directly accessible via a graphical-user interface or an application running on a mobile device. Any suitable interface can be used that enables the creation and storage of credentials, and user accounts. In addition (or as an alternative) to creation of credentials by credential grantors, credentials could be created at the request of registered users through a web-based or other interface, or through any other suitable mechanism such as sending email or short message service (SMS) transmissions to grantors. In some implementations, registered users may be able to create credentials by use of an application running on a client device.

The server630also may present an interface so that users and/or credential grantors can create user accounts for individual users and groups of users. For example, the server630may present a web interface through which credential grantors can interact via a Web browser. Additionally or alternatively, the server630may be directly accessible via a graphical-user interface or an application on a mobile device. User accounts may be stored in a table or collection of tables in a database, or in any other suitable data structure accessible by the server630. The user accounts may include a variety of information such as user name, user identifier (e.g., a number or character string that uniquely identifies a user), one or more unique keys for the user (e.g., alphanumeric codes that can be used for encryption and/or decryption), the address(es) of one or more client devices owned by or otherwise associated with the user. Likewise, group accounts may be stored in a table, collection of tables, or other suitable data structure. Certain individual users may be identified as belonging to a group by linking an entry for the user to an entry for the group, for example by use of a linking table. The group accounts may include a variety of information such as a group name, group identifier (e.g., a number or character string that uniquely identifies a group), and a description of the group. In addition (or as an alternative) to creation of user accounts and groups by grantors, user accounts and groups could be created at the request of potential users through a web-based or other interface, or through any other suitable means such as sending email or SMS to grantors. In some implementations, the potential users may be able to create user accounts by use of an application running on a client device.

As an example, Mr. John Smith may request a new user account from the server630using an application executing on his client device. The server630can then create database entries representing a user account for Mr. Smith. A credential grantor could then create a row in another table for a group identified as employees of Company X. The grantor and/or server630could then link the database entry for Mr. Smith to the group account for Company X through use of a linking table.

Once credentials and users, or groups of users, have been created, credential grantors and/or users can associate the credentials with users, or groups of users. For example, the server630may present a web interface through which grantors can interact via a Web browser to link a given credential to a given user or group of users. In other aspects, the server630may be directly accessible via a graphical-user interface or an application on a mobile device. Credentials may be associated with users, or groups of users, for example, by generating a credential identifier for a given user or group of users, and associating the credential identifier with the user or group of users by storing an entry for the credential identifier as a database entry related to a credential. In addition to association of credentials to users and groups of users by grantors, registered users also may request that certain users, or groups of users, be associated with certain credentials through a web-based or other interface, or through any other suitable means such as sending email or SMS transmissions to grantors. In some implementations, users may be able to associate their user accounts with one or more credentials by use of an application running on a client device. Furthermore, the server630also may notify the users that they have been associated with the credential(s), for example by pushing notifications to the respective users' client devices. Such notifications may include the credential identifier and/or a key for the user.

In addition or as an alternative to receiving push notifications from the server630, the client devices may obtain the credential identifier and/or the key in various other ways. For example, the client devices may request the credential identifier and/or the key from the server630. As described herein, a key may be any suitable alphanumeric code that is unique to a given user. For example, a key may be a symmetric key or shared secret between the client device and the server that can be used to maintain a private information link. In other implementations, the key may be a private key and/or public key that can be used with a public-key cryptographic system. The key may be of any suitable length such as, for example, 80 bits, 128 bits, or 256 bits. In some implementations, an application executing on the client device may have the key pre-installed, or may receive a key when a user first runs the application and creates a user account associated with the application, or may receive a key when a user logs into the application from the client device. In some implementations, the client device may receive the key from the server in a key exchange (e.g., a Diffie-Hellman key exchange).

Once credentials have been associated with appropriate user and/or group accounts, the credential identifiers and/or keys can then be distributed to client devices for the appropriate users via the network620. For example, the network620may be a local area network (“LAN”) and a wide area network (“WAN”), e.g., the Internet. In some versions, the server630may communicate with the client devices via SMS or multimedia messaging service (MMS). The server630may access user accounts in a database to locate the appropriate users' client devices.

Client devices602,604can receive the credential identifiers and/or the keys associated with their respective users and store them in any suitable memory for later retrieval. Software applications executing on the client devices602,604can then retrieve the credential identifiers and keys so they can be used for generating and presenting a representation of the credential to a validation entity for validation. The client devices602,604may be any type of computing device, including but not limited to a mobile phone, smart phone, PDA, music player, e-book reader, tablet computer, laptop or desktop computer, or other stationary or portable device, that includes one or more processors and non-transitory computer readable storage media. The software application can be written in any suitable programming language such as, for example, Objective-C, C++, Java, etc.

FIG. 6illustrates an example in which the credential corresponds to an employee badge for gaining entry into a place of business. Users606(“Eric Smith”),608(“John Smith”) are employees and, consequently, have received credential identifiers associated with the credential. The validation entity610is a security guard responsible for permitting only authorized individuals to enter the place of business. As described in greater detail below, the credential for accessing the place of business may be represented in a variety of different formats, and the validation entity610may be able to validate representations of the credential in any of these different formats.

The client device602of user606is executing an application that displays a user interface642(similar to the screenshot200shown inFIG. 2) indicating that the client device602is outputting a sound signal representing the credential. The client device604of user608is executing an application that displays a user interface644including an optical machine readable representation for the credential (e.g., a quick response (QR) code) similar to the screenshot100shown inFIG. 1. User608, at the front of the entry line, has presented the QR code for validation to the validation entity610.

Moreover, the client device602,604may obtain the user's image from, for example, a memory of the client device602,604, or a server such as a server associated with the credential grantor. The client device602,604may display this image before, after, and/or during presentation of the optical machine-readable representation for authentication of the user606,608.

When a user606,608decides to present a time-varying representation of a credential to the validation entity610for validation, the user606,608may input a command into the user's client device602,604via a man-machine interface (e.g., a user interface on a presence-sensitive display). An application executing on the client device602,604then generates and outputs the selected time-varying representation. In particular, when the users606,608enter a command to cause the client devices602,604to output an optical machine-readable representation for a credential, the client devices602,604generate a set of alphanumeric characters that then are encoded as an optical machine-readable representation. Similarly, when the users606,608enter a command to cause the client devices602,604to output a sound signal representing a credential, the client devices602,604generate a set of alphanumeric characters that then are encoded as the sound signal. The set of alphanumeric characters may include, for example, letters, numbers, a combination of letters and numbers, and/or any other symbols (e.g., “!” or “@”). In some implementations, the set of alphanumeric characters generated for encoding as an optical machine-readable representation for a credential may be the same as the set of alphanumeric characters generated for encoding as a sound signal. In other implementations, the set of alphanumeric characters generated for encoding as an optical machine-readable representation for a credential may be different than the set of alphanumeric characters generated for encoding as a sound signal.

The client devices602,604can generate the set of alphanumeric characters using a time, a key associated with the user, and a credential identifier. The client devices602,604may obtain a time derived from a timing device of the client device. The time can be, for example, a current timestamp (e.g., seconds or milliseconds from epoch) obtained from a timing device such as a hardware or software clock located at the client device. In some implementations, the timing device can be synchronized with the server630, and/or with one or more additional servers that provide a master clock reference as described below. The credential identifier and the key can be provisioned onto the client device as described elsewhere herein.

The mapping of the key, time, and credential identifier to the set of alphanumeric characters can use any suitable technique. For example, the credential identifier, key, and time could be concatenated, manipulated using mathematical functions, encrypted using a cryptographic algorithm such as AES, hashed using a hash function such as MD5, SHA-1 or SHA-2, subsampled to select a predetermined subset or subsets, or any combination of these techniques to generate a suitable set of characters. In some implementations, the set of alphanumeric characters may include a random number or a nonce (e.g., a one-time use code) to provide additional security. The client devices602,604and/or server630may check that this random number has not been used for a validation request within a predetermined number of prior requests (e.g., the last 10, 20, or 30 requests). For example, the client devices602,604and/or server630could store the previously used random numbers in a database and confirm that a new validation request does not include one of the previously used random numbers. Any other suitable data could also be included in the set of alphanumeric characters, such as, for example, a checksum, a user identifier, a code identifying a type of credential (e.g., whether the credential is for access to a physical resource (e.g., a location) or a logical resource (e.g., a network and/or computing resource), and/or an index identifying a particular device of a user on which the representation of the credential is rendered.

As an example, the client devices602,604may generate a set of alphanumeric characters (e.g., a “Code”) by concatenating several strings as follows:

where “Credential_ID” is the credential identifier for the credential being represented, “Truncate( . . . , Last_10)” is a truncation function that returns the last 10 characters of the input string, “MD5( . . . )” is a function that performs an MD5 hash function on the input “Checksum” string, “Random(0-9999)” is a function that returns a random number between 0 and 9,999, and “Checksum” is a checksum derived from the credential identifier, the key, and the time; and

where “Credential_ID” is the credential identifier, “Key” is a key associated with the user606,608, and “Floor(time/300)” is a function that returns the current time in seconds at the client device602,604divided by 300 and rounded down.

As another example, the client devices602,604may generate a set of alphanumeric characters (e.g., a “Code”) by concatenating several strings as follows:

where “Credential_Type” identifies the type of credential, “Credential_ID” is the credential identifier for the credential being represented, “Device_Index” identifies a device of a particular user606,608on which the representation of the credential is to be rendered (e.g., the device index may be useful for tracking which device was used to display the representation of the credential that was validated if a user has multiple devices that can be used to present the representation for the credential), “Random(0-9999)” is a function that returns a random number between 0 and 9999, and “Checksum” is a checksum derived from the Payload, the key, and the time; and

where “Truncate( . . . , Last_8)” is a truncation function that returns the last 8 characters of the input string, “MD5( . . . )” is a function that performs an MD5 hash function on the input string, “Key” is a key associated with the user606,608, and “Floor(time/300)” is a function that returns the current time in seconds at the client device602,604divided by 300 and rounded down.

As yet another example, the client devices602,604may generate a set of alphanumeric characters (e.g., a “Code”) by concatenating several strings as follows:

where “Credential_Type” identifies the type of credential, “Credential_ID” is the credential identifier for the credential being represented, “User_ID” is a unique identifier of a particular user606,608, “Random(0-9999)” is a function that returns a random number between 0 and 9999, and “Checksum” is a checksum derived from the Payload, the key, and the time; and

where “Truncate( . . . , Last_8)” is a truncation function that returns the last 8 characters of the input string, “MD5( . . . )” is a function that performs an MD5 hash function on the input string, “Key” is a key associated with the user606,608, and “Floor(time/300)” is a function that returns the current time in seconds at the client device602,604divided by 300 and rounded down.

Once the set of alphanumeric characters has been generated, the client devices602,604may encode the set of alphanumeric characters to generate an optical-machine readable representation for the credential. As described herein, an optical machine-readable representation may be an arrangement of graphical elements that encode alphanumeric data, where the elements are arranged so that the data can be read by an optical scanner. For example, an optical machine-readable representation may be a bar code, a QR code, or an Aztec code, among other optical machine-readable representations. The optical machine-readable representations may encode data including or representing credential identifiers, keys, times, and any other suitable data. In other implementations, the optical machine-readable representations may encode other identifiers that are linked to or otherwise associated with credential identifiers and/or keys. As an example, credential identifiers, keys, and times for the users606,608may be encoded using QR codes.

The client device602,604may use any suitable technique for encoding the optical machine-readable representation. For example, the client device may call a function or library routine that encodes QR codes in accordance with the QR code International Organization for Standardization (ISO) standard, ISO/IEC 18004:2006 RSS, Information technology—Automatic identification and data capture techniques—QR Code 2005 bar code symbology specification.

Alternatively or in addition, once the set of alphanumeric characters has been generated, the client devices602,604may encode the set of alphanumeric characters to generate a sound signal encoding the set of alphanumeric characters. As described herein, a sound signal is an oscillation of pressure waves transmitted through the air that are modulated to encode information. Any suitable modulation scheme could be used, such as, for example, frequency shift keying (FSK) or phase-shift keying (PSK). In some implementations, the sound signal may be in the ultrasonic frequency range, e.g., greater than about 20 kHz. In some implementations, the sound signal may be in the audible frequency range, e.g., about 20 Hz to about 20 kHz. Additionally or alternatively, the sound signal may be in the ultrasonic frequency range, e.g., about 20 kHz or more.

The sound signal may encode data including or representing credential identifiers, keys, times, and any other suitable data. In other implementations, the sound signal may encode other identifiers that are linked to or otherwise associated with credential identifiers and/or keys. As an example, credential identifiers, keys, and times for the users606,608may be encoded using sound signals. The client device may use any suitable technique for encoding the sound signal. For example, the client device may call a function or library routine that encodes data into sound signals such as the Zoosh SDK by Naratte, Inc. The client device602,604can then output the sound signal from a speaker coupled to the client device for reception by the processing system612.

When the client device602,604displays an optical machine-readable representation, the validation entity610can operate the processing system612to scan the portion of the client device's display1812showing the representation and decode the representation to generate a set of alphanumeric characters that were encoded in the representation. In particular, the processing system612outputs a reticle648defining a field of view from a camera operatively coupled to the processing system612. This reticle648can be used by the validation entity610to scan the optical machine-readable representation from the relevant portion of the client device's display644.

The processing system612may use any suitable mechanism to scan and decode the optical machine-readable representation. For example, the processing system612may access a function or library routine that captures and decodes QR codes and/or barcodes using a camera operatively coupled to the processing system612. Suitable libraries may include, for example, RedLaser or Zxing.

When the client device602,604outputs a sound signal, the validation entity610can operate the processing system612to receive the sound signal at a speaker of the processing system and decode the optical machine-readable representation to generate a set of alphanumeric characters that were encoded in the sound signal. The processing system612may use any suitable mechanism to receive and decode the sound signal. For example, the client device may call a function or library routine that encodes data into sound signals such as the Zoosh SDK by Naratte, Inc.

Alternatively or in addition to scanning an optical machine-readable representation from the client device or receiving a sound signal from the client device602,604, the processing system612may obtain the set of alphanumeric characters from the client device602,604via any other suitable transmission method. For example, the client device602,604may transmit the set of alphanumeric characters to the processing system612using Bluetooth, Near Field Communications (NFC), and/or Wi-Fi.

Once the processing system612has obtained a set of alphanumeric characters from the time-varying representation for a credential from the client device602,604(e.g., from an optical machine-readable representation or a sound signal), the processing system can validate the representation in several ways. As described above, the set of alphanumeric characters may include (or encode or be derived from) a key, a credential identifier, and a time among other data. In some implementations, the processing system612may obtain the set of alphanumeric characters and transmit the set of characters to the server630in a validation request message to the server630.

The server630receives the validation request message from the processing system612, and then attempts to confirm that the set of alphanumeric characters derived for the time-varying representation of the credential is valid. In particular, the server630may decode the set of alphanumeric characters to obtain the credential identifier. The server630can then independently obtain the key of the user associated with the credential identifier (e.g., from a database by querying using the credential identifier) and the time from a timing device accessible to the server630. The server630can then generate a set of alphanumeric characters using the credential identifier and the independently obtained key and time using the techniques used by the client device602,604as described above. Finally, the server630can compare the generated set of alphanumeric characters with the set of alphanumeric characters included in the validation request. In some implementations, the server630may independently calculate the checksum described above and only determine that the checksums match without determining that both the payloads and the checksums match. Alternatively, the server630may independently calculate the checksum described above and determine that both the payloads and the checksums match. If the generated set of alphanumeric characters matches the set of alphanumeric characters from the validation request message, then the server630can generate a validation response message indicating that the time-varying representation of the credential was validated. When the timing device of the server630is synchronized with the timing devices at client devices602,604, the set of alphanumeric characters generated at the server630should be identical (or nearly identical) to those of the client devices602,604when the credential identifiers and keys are the same. If the generated set of alphanumeric characters does not match the set of alphanumeric characters from the validation request message, the server's response indicates that the user608is not validated.

Although the time between the client devices602,604and the server630may be synchronized as described below, in some instances, the time at the server630may not exactly match the time from the client device602,604. Alternatively, in some implementations, the time at the client devices602,604and the server630may not be synchronized. Accordingly, in some implementations, if the first set of alphanumeric characters generated at the server630does not match the set of alphanumeric characters received in the validation request message, the server630may recalculate the set of alphanumeric characters using an offset (e.g., adding or subtracting a set amount of time such as, for example, 5 minutes) from the time obtained at the server. The recalculated set of alphanumeric characters can then be compared with the set of alphanumeric characters from the validation request. Any suitable number of recalculated sets of alphanumeric characters using any suitable offset may be used to account for time differences between the client devices602,604and the server630.

In some implementations, if the credential representation is validated, the validation response may include an image, a name, and/or other data relating to the validated user. The server630may obtain information relating to the user (e.g., an image of the user) from the credential grantor as described above. For example, the processing system612may display the user's name and the user's image as shown inFIG. 6. In some implementations, responsive to receiving a validation response from the server630, the processing system612may obtain the user's image from, for example, a memory of the processing system612, the server630, a server made accessible by the credential grantor, or another server. The processing system612may then output the user's image to a display operatively coupled to the processing system612.

In some implementations, the processing system612may perform some or all of the validation of the time-varying representation for the credential. For example, the processing system612may decode the set of alphanumeric characters to obtain the credential identifier. The processing system612can then independently obtain a key and time (e.g., from the server630or a database), and generate a set of alphanumeric characters. The processing system612can then compare the generated set of alphanumeric characters with the set of alphanumeric characters decoded from the time-varying representation presented by the client device602,604.

In other implementations, the processing system612may capture and store a copy of the time-varying representation for a credential. For example, the processing system612may store a copy of an optical machine-readable representation or a sound signal presented by a client device602,604. The processing system612may then transmit the copy to the server630, rather than decoding the representation on the processing system612. In such implementations, the server630can decode the reproduction of the time-varying representation to produce a set of alphanumeric characters, and then validate the set of alphanumeric characters as described above.

Upon successful validation, the server630sends the processing system612a validation response indicating that the time-varying representation for the credential was valid (e.g., the set of alphanumeric characters decoded from the representation matches a set of alphanumeric characters generated at the server630). The processing system may then provide a user interface (e.g., screenshot500as shown inFIG. 5) to the validation entity610indicating that the time-varying representation presented by the user608was valid. The validation entity610may then permit the user608to enter the place of business.

While shown inFIG. 6as a person, the validation entity610can be any agent capable of validating representations of credentials presented by users. As an example, the validation entity610could be a software application executing on the processing system612that processes a time-varying representation for a credential received from a client device602,604(e.g., an optical machine-readable representation for a credential or a sound signal), decodes the representation to generate an alphanumeric set of characters, transmits the alphanumeric set of characters to the server630, and receives a response from the server630indicating that the representation is valid. The software application could then control an automated gate to permit user608to enter. The processing system612can also be any suitable computer or set of computers capable of communicating with the server630via network620, such as a mobile phone, smart phone, PDA, tablet computer, laptop or desktop computer, or other stationary or portable device, that includes one or more processors and non-transitory computer readable media.

Time-varying representations for multiple credentials may be displayed and/or presented concurrently. This may be implemented, for example, when credentials represent a hierarchy of access. As an example, if Mr. John Smith is an employee of Company X and also is authorized to access the 12th floor of Company X's headquarters, he may have two credentials, i.e., a first credential identifying Mr. Smith as an employee who is authorized to enter the headquarters, and a second authorizing Mr. Smith to access the 12th floor. In such implementations, optical machine-readable representations for the first credential and the second credential may both be presented at the same time so that a validation entity can permit Mr. Smith access to the 12th floor.

FIG. 7illustrates sample messages between a client device, server, and processing system in a system that manages time-varying representations for credentials. The messages described below may be transmitted via any suitable protocol such as, for example, HTTP or SMS. Additionally, these example messages should not be considered limiting, as any suitable mechanism for performing the functions described could be used, and the messages could be sent or received in any suitable sequence.

InFIG. 7initially, a client device602transmits a request message702for a credential identifier to a server630. This request may be, for example, a request for credential identifiers associated with a user logged into the client device602. The request also may be, for example, initiated in response to the operator of the client device602accepting an offer of (or requesting) a credential from a credential grantor (e.g., accepting or requesting an employee badge). In response, the server630transmits a response message704to the client device602that includes a credential identifier. In some implementations, the server630may push the message704including the credential identifier to the client device602without first receiving a request message702. The client device602may similarly obtain the key, or may already have the key stored in a memory of the client device602.

Next, the client device602and in some implementations the processing system612associated with the validation entity610synchronize timing devices (e.g., local clocks) with a master clock of the server630by transmitting synchronization messages706and708(e.g. network time protocol (NTP) messages). While synchronization is shown as occurring only once, and simultaneously among the client device602, server630, and processing system612, synchronization may occur at regular time intervals and need not be performed simultaneously for the client device602and the processing system612. Also, while only one server630is illustrated, multiple time servers could be used synchronize the timing devices of client device602and processing system612. Synchronization among the client device602, the server630, and the processing system612, can be performed using any suitable technique. For example, NTP, global positioning system (GPS), or IEEE 1588 precision time protocol (PTP) may be used.

When the user of the client device602inputs a command to output a time-varying representation for a credential, in step710, the client device602generates an optical machine-readable representation for the credential or a sound signal representing the credential using the credential identifier, key, and time as described above. The client device602may then present the time-varying representation for the credential to the validation entity610for validation. For example, the processing system612may scan an optical machine-readable representation or receive a sound signal in step712, and decode the representation to obtain the set of alphanumeric characters as described above. The processing system612then sends a validation request message714to validate the set of alphanumeric characters to the server630. The server630then transmits a validation response message716back to the processing system612that indicates whether the time-varying representation was valid. If so, then the processing system612validates the user in step718.

FIG. 8shows an example process800for validating a validation request received at a server630. In step802, a server630receives a validation request from a processing system612associated with a validation entity610. The validation request may be received, for example, via HTTP, SMS, or any other suitable communication technique. The validation entity610may be, for example, a security guard operating the processing system612or a software component that manages validation of credentials. The validation request includes a set of alphanumeric characters that were derived from a time-varying representation for a credential. In particular, the set of alphanumeric characters includes data corresponding to a key associated with a user, a credential identifier identifying the credential, and a time at a client device602,604. For example, the set of alphanumeric characters may include the credential identifier and a checksum derived from, among other data, the key and the time as described above.

In step804, the server630determines that the key is associated with the credential identifier. For example, the server630may query a database using the credential identifier to obtain a key associated with a user to whom the credential corresponds. In step806, the server obtains a time from a timing device accessible to the server630. The timing device may be, for example, a hardware or software clock.

Next, in step808, the server630determines that the time from the timing device obtained by the server is within a predetermined amount of time of the time at the client device602,604(e.g., the time used to derive a portion of the set of alphanumeric characters). The server630may make this determination, for example, by independently encoding a set of alphanumeric characters using the credential identifier, the key, and the time obtained from the timing device in accordance with the same technique used at the client device602,604. If the set of alphanumeric characters encoded by the server630matches the set of alphanumeric characters received from the processing system612, then the server630infers that the time at the timing device matched the time at the client device602,604. In some instances, determining, at the server, that the first time at the client device does not match the second time from the timing device involves adjusting the second time from the timing device by an offset, then determining that the adjusted second time matches the first time at the client device.

In step810, responsive to determining that the key is associated with the credential identifier, and that the time from the timing device is within a predetermined amount of time of the time from the set of alphanumeric characters received from the processing system612, the server630communicates a validation response to the processing system612indicating that the credential is validated (e.g., that the set of alphanumeric characters received from the processing system corresponds to a combination of a credential identifier, key, and time for an authorized user).

In some implementations, in response to determining that the key is associated with the credential identifier and that the time from the timing device is within the predetermined amount of time of the time at the client device, the server630obtains an image of the authorized user. The server630then transmits the image of the user to the processing system612.

While the server630is described as being separate from the processing system612, in some implementations, the server630may be co-located with the processing system612. For example, the server630and the processing system612could share the same processor or set of processors. Alternatively or in addition, some or all of the functions of the server630could be performed by the processing system612.

In some implementations, the time-varying representation for the credential comprises a time-varying optical machine-readable representation (e.g., a QR code, barcode, or Aztec code) for the credential. In some implementations, the time-varying representation for the credential comprises a time-varying code rendered as a sound signal. The sound signal may have a frequency greater than 20 kHz (e.g., ultrasonic frequencies), or the sound signal may have a frequency between about 20 Hz and 20 kHz (e.g., audible sound).

FIG. 9shows an example process900for validating a credential at a processing system operated by a validation entity. In step902, a processing system612associated with a validation entity610obtains a time-varying representation for a credential from a client device of a user. In some implementations, this may involve scanning a time-varying optical machine-readable representation for a credential (e.g., a QR code, barcode, or Aztec code) from a client device602,604of a user606,608. In some implementations, this may involve receiving a sound signal at a microphone coupled to the processing system612. The sound signal may be outputted from a speaker on a client device602,604of a user606,608. The sound signal encodes a set of alphanumeric characters corresponding to the time-varying representation for the credential.

Next, in step904, the processing system612decodes the time-varying representation for the credential to generate a set of alphanumeric characters. The set of alphanumeric characters includes data corresponding to: (i) a key, (ii) a credential identifier, and (iii) a time at the client device602,604. For example, the set of alphanumeric characters may include the credential identifier and a checksum derived from, among other data, the key and the time as described above. The key may be an alphanumeric code that can be used for encryption and/or decryption that is associated with the user, and the credential identifier identifies a credential (e.g. an employee badge). In implementations where the time-varying representation is an optical-machine readable representation, the processing system decodes the optical machine-readable representation for the credential to generate a set of alphanumeric character, for example using a routine or library. In implementations where the time-varying representation is a sound signal, the processing system decodes the sound signal to generate a set of alphanumeric characters, for example using a routine or library.

Then, in step906, the processing system612transmits a validation request to a server630. Among other data, the validation request includes data corresponding to the key, the credential identifier, and the time. For example, the request may include the credential identifier and a checksum derived from, among other data, the key and the time as described above. Finally, upon successful validation by the server630, the processing system612receives a validation response from the server630, where the validation response indicates that the credential is validated.

In some implementations, in response to receiving a validation response from the server, the processing system612obtains an image of the user and outputs the image of the user to a display operatively coupled to the processing system612. The processing system612may obtain the image, for example, from the server630, from a database accessible by the processing system, from a third-party server, and/or from a server associated with the credential grantor.

FIG. 10shows an example process1000for outputting a representation for a credential to a validation entity. In step1002, a client device602,604obtains a key associated with a user of the client device. As discussed above, in some implementations, an application executing on the client device602,604may have the key pre-installed, or may receive a key when a user first runs the application and creates a user account associated with the application, or may receive a key when a user logs into the application from the client device602,604. In some implementations, the client device may receive the key from the server in a key exchange (e.g., a Diffie-Hellman key exchange).

In step1004, the client device602,604obtains a credential identifier associated with a credential. As discussed above, the client device602,604may receive the credential identifier from the server630in response to a request from the client device602,604or in a push notification or SMS from the server630.

Then, in step1006, the client device602,604receives a user command to output a representation for the credential. The user command may select, for example, an option to cause the client device to output an optical machine-readable representation for the credential (e.g., a QR code, barcode, or Aztec code). Alternatively or in addition, the user command may select, for example, an option to cause the client device to output a sound signal encoding a set of alphanumeric characters. The sound signal, for example, may have frequencies greater than 20 kHz (e.g., such that it may not be audible to the human ear), or frequencies between about 20 Hz and 20 kHz (e.g., such that it may be audible to the human ear).

The client device602,604then generates and outputs a representation of the credential for validation. In particular, in step1008, the client device602,604obtains a current time derived from a timing device of the client device. The timing device may be, for example, a local hardware or software clock on the client device.

Then, in step1010, the client device602,604generates a set of alphanumeric characters based on the credential identifier, the key, and the time derived from the timing device. As described above, the client device602,604may generate the set of alphanumeric characters from the credential identifier, key, and time by concatenation, manipulation using mathematical functions, encryption using a cryptographic algorithm such as AES, hashing using a hash function such as MD5, SHA-1 or SHA-2, subsampling to select a predetermined subset or subsets, or any combination of these techniques to generate a suitable set of characters.

Next, in step1012, the client device602,604encodes the set of alphanumeric characters to generate a representation for the credential. In some implementations, the client device encodes the set of alphanumeric characters to generate an optical-machine readable representation for the credential (e.g., a QR code, a barcode, or an Aztec code). In some implementations, the client device encodes the set of alphanumeric characters into a sound signal representing the set of alphanumeric characters.

Finally, in step1014, the client device outputs the representation for the credential in a manner that enables a validation entity610to validate the credential. In instances where the user command specifies an optical machine-readable representation for the credential, the client device outputs the optical machine-readable representation for the credential to a display of the client device in a manner that enables a validation entity to validate the credential. In instances where the user command specifies a sound signal, the client device outputs the sound signal from a speaker operatively coupled to the client device in a manner that enables a validation entity to validate the credential.

In some implementations, the client device602,604may periodically update the representation for the credential at a predetermined frequency (e.g., every 5 minutes). In such implementations, the client device may generate two or more representations for the credential in response to a user command. For example, the user606,608could enter a command to output a representation for the credential. Then, the client device602,604could obtain a first time derived from a timing device of the client device, generate a first set of alphanumeric characters based on the credential identifier, the key, and the first time derived from the timing device, encode the first set of alphanumeric characters to generate a first representation for the credential, and output the first representation for the credential. After the predetermined time period, the client device602,604could obtain a second time, generate a second set of alphanumeric characters based on the credential identifier, the key, and the second time, encode the second set of alphanumeric characters to generate a second representation for the credential, and output the second representation for the credential.

A wide variety of applications are possible based on the subject matter described above. For example, credentials could be used to permit access to facilities. Representations for a credential could be provided to employees of a company, or other individuals authorized to access company property. In some cases, the validation of the representations could be automated. For example the validation entity could be a software agent that operates the processing system and controls an electro-mechanical lock or gate to permit validated users to enter a physical space. Additionally or alternatively, the validation entity could be a software agent that operates the processing system and controls an alarm system such that the validation entity can disable the alarm system responsive to presentation of a valid credential. Similarly, representations could be distributed to employees or other individuals authorized to permit them access to a company's logical resources (e.g., the company's electronic data or website) and access to such logical resources could be granted responsive to successful validation. Additionally, employees of a utility or other service company (e.g., a cable company representative) could present representations for a credential to identify themselves to customers.

In another specific example in which a credential provides access to a physical space (e.g., by unlocking a physical lock or gate and/or disabling an alarm system), the credential may be represented as a sound signal as described above, and the sound signal may be directed into a microphone in order to gain access to the physical space; or the credential may be represented by an optical machine readable code (e.g., a QR code), and the optical machine readable code may be scanned by an appropriate sensor in order to gain access to the physical space.

The computer system can include clients and servers. A client and server are generally remote from each other and typically interact through a network, such as a network described above, though they need not be. The relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.

A number of implementations have been described. Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of this disclosure. Accordingly, other implementations are within the scope of the following claims.