WO2016186678A1 - Contract token including sensor data - Google Patents

Contract token including sensor data Download PDF

Info

Publication number
WO2016186678A1
WO2016186678A1 PCT/US2015/032083 US2015032083W WO2016186678A1 WO 2016186678 A1 WO2016186678 A1 WO 2016186678A1 US 2015032083 W US2015032083 W US 2015032083W WO 2016186678 A1 WO2016186678 A1 WO 2016186678A1
Authority
WO
WIPO (PCT)
Prior art keywords
token
contract
offer
electronic device
circuitry
Prior art date
Application number
PCT/US2015/032083
Other languages
French (fr)
Inventor
Babak Makkinejad
Original Assignee
Hewlett Packard Enterprise Development Lp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett Packard Enterprise Development Lp filed Critical Hewlett Packard Enterprise Development Lp
Priority to PCT/US2015/032083 priority Critical patent/WO2016186678A1/en
Priority to EP15892779.8A priority patent/EP3298723A4/en
Priority to US15/575,794 priority patent/US11961154B2/en
Publication of WO2016186678A1 publication Critical patent/WO2016186678A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q50/00—Systems or methods specially adapted for specific business sectors, e.g. utilities or tourism
    • G06Q50/10—Services
    • G06Q50/18—Legal services; Handling legal documents
    • G06Q50/188—Electronic negotiation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/30—Authentication, i.e. establishing the identity or authorisation of security principals
    • G06F21/31—User authentication
    • G06F21/32—User authentication using biometric data, e.g. fingerprints, iris scans or voiceprints
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4014—Identity check for transactions
    • G06Q20/40145—Biometric identity checks
    • G—PHYSICS
    • G09—EDUCATION; CRYPTOGRAPHY; DISPLAY; ADVERTISING; SEALS
    • G09C—CIPHERING OR DECIPHERING APPARATUS FOR CRYPTOGRAPHIC OR OTHER PURPOSES INVOLVING THE NEED FOR SECRECY
    • G09C1/00—Apparatus or methods whereby a given sequence of signs, e.g. an intelligible text, is transformed into an unintelligible sequence of signs by transposing the signs or groups of signs or by replacing them by others according to a predetermined system
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/08—Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0861—Network architectures or network communication protocols for network security for authentication of entities using biometrical features, e.g. fingerprint, retina-scan
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/107—Network architectures or network communication protocols for network security for controlling access to devices or network resources wherein the security policies are location-dependent, e.g. entities privileges depend on current location or allowing specific operations only from locally connected terminals
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/30—Public key, i.e. encryption algorithm being computationally infeasible to invert or user's encryption keys not requiring secrecy
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
    • H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H04L9/3228—One-time or temporary data, i.e. information which is sent for every authentication or authorization, e.g. one-time-password, one-time-token or one-time-key
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
    • H04L9/3231—Biological data, e.g. fingerprint, voice or retina
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/06—Authentication

Definitions

  • Figure 1 shows an example of an electronic device that supports exchange of contract tokens including sensor data.
  • Figure 2 shows an example of a contract token exchange between electronic devices.
  • Figure 3 shows an example of an electronic device storing contract tokens at a token authority.
  • Figure 4 shows an example of a contract token exchange between electronic devices through a token authority.
  • Figure 5 shows another example of a contract token exchange between electronic devices through a token authority.
  • Figure 6 shows an example of logic that an electronic device may implement to support exchange of contract tokens including sensor data.
  • Figure 7 shows an example of an electronic device that supports exchange of contract tokens including sensor data.
  • the discussion above may provide devices, systems, logic, circuitry, and methods for the exchange of contract tokens including sensor data by electronic devices.
  • the features below may support efficient generation and exchange of data tokens effectuating or recording a transaction, contract, obligation, agreement, or common understanding between parties.
  • Sensor data included in such tokens may record an environment characteristic surrounding the electronic device at the time of exchange, and may provide user verification or authenticity validation for generated tokens.
  • the features described herein may increase the efficiency and authenticity of contract token exchanges between electronic devices.
  • Figure 1 shows an example of an electronic device 100 that supports exchange of contract tokens including sensor data.
  • the electronic device 100 may take any number of forms.
  • the electronic device 100 takes the form of a mobile communication device, e.g., a mobile phone.
  • Other example forms the electronic device 100 may take include a laptop or desktop computer, tablet device, personal digital assistant (PDA) device, portable music device, any wearable electronic device (such as a smartwatch device or an optical head-mounted display device), a token exchange device, and various other devices.
  • PDA personal digital assistant
  • the electronic device 100 may include token circuitry 110.
  • the token circuitry 110 may generate tokens, such as a contract token. Through a generated contract token, the electronic device 100 may log a transaction, contract, obligation, agreement, or understanding, e.g., as agreed upon by a user of the electronic device 100 and user of a different electronic device.
  • the token circuitry 110 may generate the contract token as any data file storing elements relevant to a particular contract, agreement, or other understanding. Such elements may include, as examples, contract terms, a contract type, party indication (e.g., an offeror or offeree indicator), relevant date information (e.g., date offered, date accepted, validity period), and more. Example elements of a contract token are discussed in greater detail below.
  • the electronic device 100 may include sensor circuitry 112 to capture sensor data.
  • the sensor circuitry 112 may capture sensor data, and thus include various types of circuitry to sense location data, image data, temperature, atmospheric pressure, user-specific traits, surrounding landmarks, or any other information pertaining to or obtained with respect to a surrounding physical environment.
  • the token circuitry 110 may generate a contract token that includes sensor data.
  • the token circuitry 110 may generate a contract token including sensor data specifically captured for inclusion in the contract token.
  • the contract token may include data to verify the authenticity of the contract token, the electronic device or party providing the contract token, the location at which the contract token was generated, or combinations thereof.
  • the token circuitry 110 may generate tokens of various types.
  • the token circuitry 110 may generate a contract token including offer terms for a contract, which may be referred to as a contract offer token.
  • the token circuitry 110 may generate a contract acceptance token.
  • the token circuitry 110 includes the sub-circuitry 121 and 122, which may be part of the token circuitry 110 as hardware, executable instructions stored on a machine-readable medium, logic, or as any other form the token circuitry 110 may take.
  • the token circuitry 110 may generate a contract acceptance token comprising an acceptance indication and sensor data captured by the sensor circuitry 112 as well as send the contract acceptance token comprising the sensor data to a different electronic device.
  • FIG 2 shows an example of a contract token exchange between electronic devices, in particular between the electronic devices labeled as 201 and 202 in Figure 2.
  • the electronic devices 201 and 202 may respectively include token circuitry to support the exchange of contract tokens including sensor data.
  • the electronic device 201 includes the token circuitry 210 and the electronic device 202 includes the token circuitry 212.
  • the electronic devices 201 and 202 may exchange one or multiple contract tokens to record an agreement between parties, such as an agreement reached by a user of the electronic device 201 and a user of the electronic device 202.
  • the electronic device 201 may present a contract offer to the electronic device 202 in the form of a contract offer token.
  • the token circuitry 210 of the electronic device 201 may obtain offer terms for a contract.
  • the contract offer terms may include any provision forming part of a contract, such as pricing information, action obligations, contract validity period, breach conditions, and more.
  • the electronic device 201 may include a user interface through which the token circuitry 210 may request and receive offer terms.
  • the token circuitry 210 may present an input screen through which offer terms are input or support direct voice input of the contract terms by a user.
  • the token circuitry 210 may generate a contract offer token that specifies the obtained offer term(s), and in Figure 2, the token circuitry 210 generates the contract offer token labeled as 220.
  • the token circuitry 210 may include any number of token elements as part of the contract offer token 220.
  • the contract offer token 220 may include any number of contract offer terms.
  • the contract offer token 220 may include sensor data.
  • the contract offer token 220 may include sensor data collected by the device generating the contract offer token 220 (which is the electronic device 201 for the example shown in Figure 2).
  • the token circuitry 210 includes offering device sensor data 221 with the contract offer token 220.
  • the sensor data included as the offering device sensor data 221 may vary, and the token circuitry 210 may access specific types of sensor data to include with the contract offer token 220.
  • the token circuitry 210 may include the specific sensor data as an authenticity indicator for the contract offer token 220, e.g., to validate the electronic device 202 or user thereof to a target electronic device receiving the contract offer token 220 or to validate the authenticity of the contract offer token 220 to confirm the authenticity or existence of a contract entered between the parties.
  • the token circuitry 210 accesses location data sensed by electronic device 201 to include in the contract offer token 220.
  • the location data may take the form of global positioning system (GPS) data collected by GPS sensor circuitry of the electronic device 201 , e.g., a GPS antenna.
  • GPS global positioning system
  • the token circuitry 210 may generate a contract token to include location coordinates (such as latitude and longitude coordinate data), altitude or elevation data, bearing, route data, nearby points of interest, or any other data indicative of a location of the electronic device 201.
  • the location data may record a position of the electronic device 201 at which the contract offer token 220 was generated or sent, thus serving to track a particular user location upon presenting a contract offer or entering an agreement.
  • the token circuitry 210 may include digital image data in the contract offer token 220.
  • the electronic device 201 may include a digital camera or other image capture circuitry, and the token circuitry 210 may cause capture of a digital image to include within the contract offer token 220.
  • the token circuitry 210 may cause capture of a user image through a front-facing camera of the electronic device 201 , which may record or verify a particular user, person, agent, individual, or other entity presenting the offer terms specified in the contract offer token 220.
  • the digital image may, as another example, depict the surroundings of the electronic device 201. An image of the device surroundings may verify or record a location of the electronic device 201, for example in combination with location data included with the contract offer token 220.
  • the token circuitry 210 may include accelerometer data or gyroscope data indicating an orientation of the electronic device 201.
  • a proximity sensor (such as infrared circuitry) may capture proximity data for the electronic device 201 , which the token circuitry 210 may include as part of the contract offer token 220.
  • Barometer data tracking atmospheric pressure or temperature data indicating ambient temperature conditions are other examples of sensor data the token circuitry 210 may access to include in a generated token.
  • the token circuitry 210 may access user-specific sensor data to include in the contract offer token 220.
  • the token circuitry 210 may cause sensor circuitry of the electronic device 201 to capture a user heart rate via a heart rate monitor or a user finger print via a fingerprint sensor.
  • the token circuitry 210 may access pedometry data, such as a number of steps tracked by the electronic device 201 within a predetermined time period prior to generating or sending the contract offer token 220.
  • pedometry data such as a number of steps tracked by the electronic device 201 within a predetermined time period prior to generating or sending the contract offer token 220.
  • These user-specific sensor data may indicate, authenticate, or confirm the user as the contract offeror for the contract offer token 220.
  • the token circuitry 210 may record environment data with respect to the electronic device 201 when the contract offer token 220 is generated, allowing present or subsequent authenticity verification of the contract offer token 220.
  • the specific types of sensor data included in a contract token may be configurable, e.g., through user request, adjusting token generation parameters referenced by the token circuitry 210, or in various other ways.
  • the token circuitry 210 may access sensor data previously captured by the sensor circuitry and locally stored on the electronic device 201. Or, the token circuitry 210 may cause the sensor circuitry to capture sensor data as part of the token generation process.
  • the sensor circuitry of the electronic device 201 automatically captures sensor data in response to a token generation trigger, such as a user indication to generate a contract token.
  • the token circuitry 210 may include various other elements within a contract token as well.
  • the token circuitry 210 may specify a contract type for the contract offer token 220.
  • the contract type may denote a field or category with respect to the contract offer terms of contract formed through acceptance of the contract offer terms.
  • the token circuitry 110 may include a date and time within the contract offer token 220, which may specify the date and time the contract offer token 220 was generated.
  • the token circuitry 210 may include a token element indicating an offer validity period in the contract offer token 220, after which an offer specified through the contract offer token 220 expires. While some example token elements have been described, the token circuitry 210 may include any element that specifies any aspect of a contract, agreement, or understanding represented through the token.
  • a token element may differentiate a particular contract token from other contract tokens.
  • the token circuitry 210 may generate the contract offer token 220 to include an identification value, such as through a global unique identifier (GUID) according to any implementation of the universally unique identifier (UUID) standard.
  • GUID global unique identifier
  • UUID universally unique identifier
  • the token circuitry 210 may thus differentiate the contract offer token 220 from other contract tokens generated or received by the token circuitry 210.
  • the identification value may likewise differentiate a particular token generated by an electronic device from other tokens also generated by the electronic device.
  • the token circuitry 210 may send the contract offer token 220 to a different electronic device.
  • the different electronic device may be an electronic device of a user or entity to which the contract offers terms are offered to.
  • the token circuitry 210 sends the contract offer token 220 to the electronic device 202.
  • the token circuitry 210 may send the contract offer token 220 through a direct connection between the electronic device 201 and the electronic device 202, such as through a direct wired connection (e.g., via a linking cable) or direct wireless connection (e.g., via a near field communication link, a Bluetooth link, or other forms of direct wireless links).
  • the token circuitry 210 utilizes an indirect data connection to send the contract offer token 220 to the electronic device 202.
  • token circuitry 212 of the electronic device 202 may process the contract offer token 220.
  • the token circuitry 212 may extract particular elements of the contract offer token 220 to present, such as through a user interface of the electronic device 202. Through the user interface, the token circuitry 212 may present contract offer terms specified in the contract offer token 220, the offering device sensor data 221 , other contract token elements, or combinations thereof. Also, the token circuitry 212 may present an acceptance prompt via the user interface, through which a user may indicate an acceptance or rejection of the contract offer terms. When the contract offer terms are accepted, the token circuitry 212 may obtain an acceptance indication through the acceptance prompt in the user interface.
  • the token circuitry 212 may generate a contract acceptance token that includes an acceptance indication for the contract offer terms specified in the contract offer token 220.
  • the token circuitry 212 generates the contract acceptance token 230.
  • the contract acceptance token 230 may include sensor data captured by the electronic device 202, shown as the accepting device sensor data 231 in Figure 2.
  • the token circuitry 212 may include any number of types of sensor data to record or authenticate the contract acceptance indication, including any combination of the sensor data discussed above with respect to the contract offer token 220.
  • the token circuitry 212 may include any number of other contract token elements discussed above as part of the contract acceptance token 230 as well.
  • token circuitry 212 may send the contract acceptance token 230 to the electronic device 201 as a response to the contract offer token 220.
  • the token circuitry 212 obtains a rejection indication for the contract offer terms specified in the contract offer token 220.
  • the token circuitry 212 may generate and send a contract rejection token to the electronic device 201.
  • the contract rejection token may instead include a rejection indication for contract offer terms, though the contract rejection token may nonetheless include any of the sensor data or other token elements discussed above.
  • the token circuitry 212 may support present or subsequent authenticity validation of a response to the contact offer terms, which may resolve disputes over the validity or existence of a contract or offer rejection.
  • Electronic devices may exchange distinct contract tokens with one another.
  • the contract offer token 220 generated by the token circuitry 210 of the electronic device 201 may be a distinct, separate data file from the contract acceptance token 230 generated by the token circuitry 212 of the electronic device 202.
  • the contract offer token 220 and contract acceptance token 230 may include different GUIDs, for example, through which electronic devices may identify the tokens 220 and 230 as separate.
  • Token circuitry of an electronic device may pair correlated contract tokens.
  • the token circuitry 210 may send the contract offer token 220 to the electronic device 202 as well as store the contract offer token 220 on a local memory of the electronic device 201 or at a remote storage location.
  • the token circuitry 210 may pair the response with the contract offer token 220 to record the contract token exchange for subsequent reference.
  • the token circuitry 210 may pair the contract offer token 220 with the contract acceptance token 230 from the electronic device 202.
  • the token circuitry 210 may pair the contract offer token 220 with the contract rejection token.
  • the token circuitry 210 may store the correlated tokens in a common table entry, link the GUIDs of the correlated tokens, or add an entry to a pairing table mapping correlated tokens.
  • the token circuitry of an electronic device may secure a contract token to prevent tampering.
  • the token circuitry may employ secure access mechanisms to limit access to token elements once a contract token is generated.
  • the token circuitry may use any form of cryptography, public key infrastructure (PKI) mechanisms, digital signatures, or other access control technologies to prevent an unauthorized device or party from altering a contract token.
  • the token circuitry may secure a contract token upon generation.
  • the token circuitry may secure a contract token upon resolution, e.g., upon generation or reception of a contract acceptance token or a contract rejection token that responds to a contract offer token.
  • the token circuitry may secure the correlated token pair to prevent tampering after acceptance of a contract or rejection of contract offer terms.
  • token circuitry of an electronic device may support an exchange of contract tokens with other electronic devices. Doing so may provide an efficient and reliable mechanism to electronically record or effectuate an agreement between parties. Sensor data included within or accompanying a contract token may provide an authenticity indicator, to a different electronic device to which a contract token is sent or upon subsequent reference. While the above examples illustrate token exchange in the form of a contract token, the token circuitry 210 and 212 may provide token exchange capabilities for any type of agreement or promise. Token circuitry may include a set of predefined agreement or contract types that a user may select from when exchanging tokens through electronic devices. In some examples, the token circuitry may support generation and exchange of custom token types, e.g., with specific parameters, terms, or format different from the predefined types provided by the token circuitry.
  • the token circuitry of an electronic device may support exchange of contract tokens for non-financial contracts, promises, obligations, and agreements.
  • the token circuitry may generate and exchange tokens recording barter exchanges or an agreement involving action without monetary terms.
  • the token circuitry may support exchange of tokens for unilateral promises, actions, or agreements.
  • the token circuitry 210 may generate and send a token to the electronic device 202 indicating a unilateral promise and the token circuitry 212 of the electronic device 202 may respond with an acknowledgment token.
  • token exchange capabilities provided by the token circuitry may record or validate various types of transactions, agreements, and promises between parties. While many of illustrations presented herein relate to contract tokens, the token circuitry may consistently implement the features described above and below for token exchanges of any type.
  • the electronic device 201 and the electronic device 202 may each store the contract offer token 220 and the contract acceptance token 230 after the exchange.
  • either electronic device may support archiving and reference of the contract exchange for subsequent reference.
  • the electronic device 201 , the electronic device 202, or both may store paired contract tokens in a remote location, one example of which is shown in Figure 3 through a token authority.
  • FIG 3 shows an example of an electronic device 201 storing contract tokens at a token authority 310.
  • the token circuitry 210 may send a contract offer token 220 and a contract acceptance token 230 to the token authority 310 for archival.
  • the token authority 310 may support subsequent retrieval of the correlated token pair by an electronic device that generated a token among the correlated contract tokens.
  • the token authority 310 may grant access to the electronic device 201 (which generated the contract offer token 220) and the electronic device 202 (which generated the contract acceptance token 230).
  • the token authority 310 may be remote to the electronic device 201.
  • the token authority 310 may provide non-local storage of contract tokens or correlated token pairs.
  • the token authority 310 may take the form of any remote system accessible to the electronic device 201 , such as a cloud server or a web server.
  • the token authority 310 may include circuitry and logic to implement any of the token authority features described herein.
  • the token authority 310 authenticates the electronic device 201 prior to storing a token on behalf of the electronic device 201.
  • the token authority 310 may implement any number of authentication techniques, such as verifying user login and password data provided by the token circuitry 210 of the electronic device 201.
  • the token authority 310 may support token exchanges between electronic devices. In some examples, the token authority 310 itself generates tokens to exchange between electronic devices. By doing so, the token authority 310 may provide a consistent format and common generation entity for tokens exchanged between electronic devices. In these examples, the token authority 310 may regulate token generation as well, for example by limiting token generation for a particular electronic device based on any number of token generation criteria.
  • One illustration of a contract token exchange through the token authority 310 is provided through Figures 4 and 5.
  • FIG. 4 shows an example of a contract token exchange between electronic devices through the token authority 310.
  • the electronic device 201 initiates a contract token exchange with the electronic device 202.
  • the token circuitry 210 of the electronic device 201 obtains an offer term 421 and sensor data 422, for example according to any of the features discussed above.
  • the token circuitry 210 may send the offer term 421 and the sensor data 422 to the token authority 310 for generation of a contract offer token that includes the offer term 421 and sensor data 422.
  • the token circuitry 210 may also send a target device indication to the token authority 310, indicating the electronic device 202 as the target electronic device to receive the contract offer token generated by the token authority 310.
  • the token authority 310 may generate a contract offer token according to the offer term 421 and sensor data 422 received from the token circuitry 210 of the electronic device 201.
  • the token authority 310 generates the contract offer token labeled as 430, which includes the offer term 421 and sensor data 422 provided by the electronic device 201.
  • the token authority 310 may include any combination of the token elements discussed above within the contract offer token 430 as well, which the token authority 310 may obtain from the electronic device 201 (e.g., as provided by the token circuitry 210 with the offer term 421 and sensor data 422) or via other mechanisms.
  • the token authority 310 may send the contract offer token 430 to the electronic device 202.
  • the token authority 310 may archive the contract offer token 430 as well.
  • the token authority 310 generates the contract offer token 430 upon determining that any number of token generation criteria are satisfied.
  • the token generation criteria applied by the token authority 310 may be configurable, for example by a system administrator or user request.
  • a token generation criterion may be particular to the electronic device 201 , such as a criterion limiting the number of tokens the electronic device 201 can generate or receive to a threshold number (e.g., over a predetermined period of time).
  • a token generation criterion may limit particular offer terms or token elements to upper or lower limits, e.g., an upper purchase price threshold, an upper limit on an offer validity period, or various other numerical limits. These limits may apply particularly to the electronic device 201 , to a class of devices or user types, or for each token generated by the token authority 310.
  • the token authority 310 applies contract generation criteria to control the quality or type of sensor data provided by the electronic device 201.
  • the token authority 310 may require a threshold image quality or image resolution for sensor data 422 in the form of a user image.
  • the token generation criteria may specify specific sensor data types that the electronic device 201 should send in order to generate a contract offer token or a requisite capture time that the sensor data 422 must satisfy (e.g., captured within a recent time threshold such as within the previous 24 hours, within the last 2 minutes, or within the 10 seconds prior to sending to the token authority 310).
  • a token generation criterion applied by the token authority 310 is not satisfied, the token authority 310 may determine not to generate a contract offer token for the electronic device 201.
  • Figure 5 shows another example of a contract token exchange between electronic devices through the token authority 310.
  • the electronic device 202 may receive the contract offer token 430 from the token authority 310, and the token circuitry 212 of the electronic device 202 may respond with an acceptance indication 521 and sensor data 522 captured by the electronic device 202.
  • the token circuitry 212 may send the acceptance indication 521 and the sensor data 522 to the token authority 310 for generating a contract acceptance token 530 that responds to the contract offer token 430.
  • the token authority 310 may generate the contract acceptance token 530 and send the contract acceptance token 530 to the electronic device 201.
  • the token authority 310 may apply token generation criteria for generating the contract acceptance token as well, including any combination of the criteria discussed above.
  • the token authority 310 generates the contract acceptance token 530 to include both the acceptance indication 521 and the sensor data 522 captured by the electronic device 202.
  • the token authority 310 may generate a token to include selected portions of the sensor data provided by an electronic device.
  • the token authority 310 may include some, but not all, of the sensor data 522 in the contract acceptance token 530.
  • the token authority 310 does not include any of the sensor data 522 in the contract acceptance token 530, though the token authority 310 may store the sensor data 522 for subsequent reference or token validation.
  • the token authority 310 may flexibly vary the particular sensor data included in generated tokens according to system requirements for authenticity, efficiency, resource consumption, or various other factors.
  • the token authority 310 may itself generate tokens according to token generation criteria. However, the token authority 310 may validate tokens generated by electronic devices. The token authority 310 may validate the content, form, or integrity of a generated token. To illustrate, an electronic device may send a generated token to the token authority 310 for validation, and prior to sending the token to a target electronic device. The token authority 310 may validate the token authority according to any number of token validation criteria, which may include any combination of the token generation criteria described above. The token authority 310 may determine whether contract terms are valid or within threshold parameters. The token authority 310 may confirm a generated token is generated according to a particular format, data type, or structure.
  • the token authority 310 may verify that the token has not been tampered, e.g., by verifying the structural integrity of a generated token.
  • the contract authority 310 may verify the integrity or format of the custom token, but not the content as the content may be user-specific.
  • the token authority 310 may validate, limit, or control token exchanges between electronic devices even when the token authority 310 itself does not generate the tokens.
  • the token authority 310 may provide a validation indication to the electronic device that generated the particular token.
  • the token authority 310 may, for instance, embed the validation indication within the particular token itself by setting a particular field in the token, adding a digital signature for the token authority 310, or in any number of other ways.
  • the token authority 310 may return the particular token with the embedded validation indication to the electronic device that first generated the particular token.
  • the token authority 310 may provide the validation indication as a separate message to the electronic device indicating the particular token has been validated.
  • the electronic device may then send the particular token to the target electronic device.
  • FIG. 6 shows an example of logic 600 that an electronic device may implement to support exchange of contract tokens including sensor data.
  • the electronic device may implement the logic 600 through token circuitry of the electronic device, for example as hardware, executable instructions stored on a machine-readable medium, or in various other ways.
  • the token circuitry of the electronic device may perform or execute the logic 600 as a method to support contract token exchange.
  • the token circuitry of the electronic device may obtain, through a user interface of the electronic device, an offer term for a contract (602).
  • the token circuitry may also receive a token indication to send a contract offer token to a different electronic device, for example also through the user interface.
  • the token circuitry may access sensor data captured through sensor circuitry of the electronic device (604).
  • the token circuitry instructs the sensor circuitry to capture the sensor data after receiving the token indication, including any of the sensor data examples provided above.
  • the token circuitry may then generate a contract offer token that specifies the offer term and includes the sensor data (606) as well as send the contract offer token that includes the sensor data to a different electronic device (608).
  • the token circuitry may further receive a contract acceptance token different from the contract offer token.
  • the contract acceptance token and contract offer token may have different GUIDs for example.
  • the token circuitry may pair the contract offer token with the contract acceptance token, thus linking the tokens as part of a common exchange or transaction.
  • the token circuitry may store the contract offer token, the contract acceptance token, or both at a token authority.
  • the token circuitry may validate the contract offer token with a token authority.
  • the token authority may apply any number of criteria to determine whether to validate the generated contract offer token, including any of the token validation or token generation criteria presented above.
  • FIG. 7 shows an example of an electronic device 700 that supports exchange of contract tokens including sensor data.
  • the electronic device 700 may be any electronic device, such as a computing system shown in Figure 7, a mobile phone, a tablet device, or any other electronic device.
  • the electronic device 700 may include a processor 710.
  • the processor 710 may include a central processing unit (CPU), microprocessor, and/or any hardware device suitable for executing instructions stored on a machine-readable medium.
  • the electronic device 700 may include a machine-readable medium 720.
  • the machine-readable medium 720 may be any non-transitory electronic, magnetic, optical, or other physical storage device that stores executable instructions, such as the contract token instructions 722 shown in Figure 7.
  • the machine-readable medium 720 may be, for example, Random Access Memory (RAM), an Electrically-Erasable Programmable Read-Only Memory (EEPROM), a storage drive, an optical disk, and the like.
  • RAM Random Access Memory
  • EEPROM Electrically-Erasable Programmable Read-Only
  • the electronic device 700 may execute instructions stored on the machine-readable medium 720 through the processor 710. Executing the instructions may cause the processor 710 to perform or support any combination of the features described herein, including any features of the token circuitry described above. To illustrate, executing the contract token instructions 722 may cause the processor 710 to obtain an offer term for a contract through a user interface of the electronic device 700 and capture sensor data through sensor circuitry of the electronic device 700. In some examples, the contract token instructions 722 cause the processor 710 to obtain a non-financial offer term as the offer term.
  • Executing the contract token instructions 722 may further cause the processor 710 to send the offer term and the sensor data to a token authority for generating, by the token authority, a contract offer token that includes the offer term and the sensor data and for sending, by the token authority, the contract offer token that includes the sensor data to a different electronic device.
  • executing the contract token instructions 722 causes the processor 710 to capture the sensor data by capturing GPS data through a GPS sensor circuitry of the electronic device 700 and send the sensor data by sending the GPS data to the token authority for generating a contract offer token that includes the GPS data.
  • executing the contract token instructions 722 causes the processor 710 to capture the sensor data by capturing a user image through a camera of the electronic device 700 and send the sensor data by sending the user image to the token authority for generating a contract offer token that includes the user image.
  • the contract token instructions 722 may support generation of non-financial tokens, e.g., tokens without financial terms.
  • executing the contract token instructions 722 may cause the processor 710 to send the offer term and the sensor data to a token authority for generating, by the token authority, a contract offer token without a financial offer term.
  • token circuitry may include circuitry in a controller, a microprocessor, or an application specific integrated circuit (ASIC), or may be implemented with discrete logic or components, or a combination of other types of analog or digital circuitry, combined on a single integrated circuit or distributed among multiple integrated circuits.
  • a product such as a computer program product, may include a storage medium and machine readable instructions stored on the medium, which when executed in an endpoint, computer system, or other device, cause the device to perform operations according to any of the description above.
  • the processing capability of the systems, devices, and circuitry described herein, including the token circuitry may be distributed among multiple system components, such as among multiple processors and memories, optionally including multiple distributed processing systems.
  • Parameters, databases, and other data structures may be separately stored and managed, may be incorporated into a single memory or database, may be logically and physically organized in many different ways, and may implemented in many ways, including data structures such as linked lists, hash tables, or implicit storage mechanisms.
  • Programs may be parts (e.g., subroutines) of a single program, separate programs, distributed across several memories and processors, or implemented in many different ways, such as in a library, such as a shared library (e.g., a dynamic link library (DLL)).
  • the DLL for example, may store code that performs any of the system processing described above.

Abstract

In some examples, an electronic device includes sensor circuitry and token circuitry. The sensor circuitry may capture sensor data and the contract token circuitry may generate a contract acceptance token including an acceptance indication and sensor data captured by the sensor circuitry. The token circuitry may send the contract acceptance token including the sensor data to a different electronic device.

Description

CONTRACT TOKEN INCLUDING SENSOR DATA
BACKGROUND
[0001] Electronic devices are widely used in nearly every facet of society today. Advances in computing ability, increases in power-efficiency, and cost decreases have contributed to the widespread distribution and use of electronic devices in homes, travel, schools, businesses, entertainment, commerce, and countless other arenas of society. Increasing the capability of electronic devices may result in even greater use of electronic devices in the future.
BRIEF DESCRIPTION OF THE DRAWINGS
[0002] Certain examples are described in the following detailed description and in reference to the drawings.
[0003] Figure 1 shows an example of an electronic device that supports exchange of contract tokens including sensor data.
[0004] Figure 2 shows an example of a contract token exchange between electronic devices.
[0005] Figure 3 shows an example of an electronic device storing contract tokens at a token authority.
[0006] Figure 4 shows an example of a contract token exchange between electronic devices through a token authority.
[0007] Figure 5 shows another example of a contract token exchange between electronic devices through a token authority.
[0008] Figure 6 shows an example of logic that an electronic device may implement to support exchange of contract tokens including sensor data.
[0009] Figure 7 shows an example of an electronic device that supports exchange of contract tokens including sensor data.
DETAILED DESCRIPTION
[0010] The discussion above may provide devices, systems, logic, circuitry, and methods for the exchange of contract tokens including sensor data by electronic devices. The features below may support efficient generation and exchange of data tokens effectuating or recording a transaction, contract, obligation, agreement, or common understanding between parties. Sensor data included in such tokens may record an environment characteristic surrounding the electronic device at the time of exchange, and may provide user verification or authenticity validation for generated tokens. As such, the features described herein may increase the efficiency and authenticity of contract token exchanges between electronic devices.
[0011] Figure 1 shows an example of an electronic device 100 that supports exchange of contract tokens including sensor data. The electronic device 100 may take any number of forms. In the particular example shown in Figure 1 , the electronic device 100 takes the form of a mobile communication device, e.g., a mobile phone. Other example forms the electronic device 100 may take include a laptop or desktop computer, tablet device, personal digital assistant (PDA) device, portable music device, any wearable electronic device (such as a smartwatch device or an optical head-mounted display device), a token exchange device, and various other devices.
[0012] The electronic device 100 may include token circuitry 110. The token circuitry 110 may generate tokens, such as a contract token. Through a generated contract token, the electronic device 100 may log a transaction, contract, obligation, agreement, or understanding, e.g., as agreed upon by a user of the electronic device 100 and user of a different electronic device. The token circuitry 110 may generate the contract token as any data file storing elements relevant to a particular contract, agreement, or other understanding. Such elements may include, as examples, contract terms, a contract type, party indication (e.g., an offeror or offeree indicator), relevant date information (e.g., date offered, date accepted, validity period), and more. Example elements of a contract token are discussed in greater detail below.
[0013] The electronic device 100 may include sensor circuitry 112 to capture sensor data. The sensor circuitry 112 may capture sensor data, and thus include various types of circuitry to sense location data, image data, temperature, atmospheric pressure, user-specific traits, surrounding landmarks, or any other information pertaining to or obtained with respect to a surrounding physical environment. The token circuitry 110 may generate a contract token that includes sensor data. In particular, the token circuitry 110 may generate a contract token including sensor data specifically captured for inclusion in the contract token. By including sensor data with or as part of a contract token, the contract token may include data to verify the authenticity of the contract token, the electronic device or party providing the contract token, the location at which the contract token was generated, or combinations thereof.
[0014] The token circuitry 110 may generate tokens of various types. For example, the token circuitry 110 may generate a contract token including offer terms for a contract, which may be referred to as a contract offer token. In response to receiving a contract offer token and obtaining an acceptance indication (e.g., from a device user), the token circuitry 110 may generate a contract acceptance token. In the example shown in Figure 1 , the token circuitry 110 includes the sub-circuitry 121 and 122, which may be part of the token circuitry 110 as hardware, executable instructions stored on a machine-readable medium, logic, or as any other form the token circuitry 110 may take. Through the sub-circuitry 121 and 122, the token circuitry 110 may generate a contract acceptance token comprising an acceptance indication and sensor data captured by the sensor circuitry 112 as well as send the contract acceptance token comprising the sensor data to a different electronic device.
[0015] Figure 2 shows an example of a contract token exchange between electronic devices, in particular between the electronic devices labeled as 201 and 202 in Figure 2. The electronic devices 201 and 202 may respectively include token circuitry to support the exchange of contract tokens including sensor data. In Figure 2, the electronic device 201 includes the token circuitry 210 and the electronic device 202 includes the token circuitry 212. The electronic devices 201 and 202 may exchange one or multiple contract tokens to record an agreement between parties, such as an agreement reached by a user of the electronic device 201 and a user of the electronic device 202.
[0016] In the contract token exchange example shown in Figure 2, the electronic device 201 may present a contract offer to the electronic device 202 in the form of a contract offer token. In doing so, the token circuitry 210 of the electronic device 201 may obtain offer terms for a contract. The contract offer terms may include any provision forming part of a contract, such as pricing information, action obligations, contract validity period, breach conditions, and more. To obtain the offer terms, the electronic device 201 may include a user interface through which the token circuitry 210 may request and receive offer terms. In some examples, the token circuitry 210 may present an input screen through which offer terms are input or support direct voice input of the contract terms by a user. The token circuitry 210 may generate a contract offer token that specifies the obtained offer term(s), and in Figure 2, the token circuitry 210 generates the contract offer token labeled as 220.
[0017] The token circuitry 210 may include any number of token elements as part of the contract offer token 220. As noted above, the contract offer token 220 may include any number of contract offer terms. As another example of a token element, the contract offer token 220 may include sensor data. In particular, the contract offer token 220 may include sensor data collected by the device generating the contract offer token 220 (which is the electronic device 201 for the example shown in Figure 2). As seen in Figure 2, the token circuitry 210 includes offering device sensor data 221 with the contract offer token 220. The sensor data included as the offering device sensor data 221 may vary, and the token circuitry 210 may access specific types of sensor data to include with the contract offer token 220. The token circuitry 210 may include the specific sensor data as an authenticity indicator for the contract offer token 220, e.g., to validate the electronic device 202 or user thereof to a target electronic device receiving the contract offer token 220 or to validate the authenticity of the contract offer token 220 to confirm the authenticity or existence of a contract entered between the parties.
[0018] Some example types of sensor data that token circuitry may include in a token are presented next. In some examples, the token circuitry 210 accesses location data sensed by electronic device 201 to include in the contract offer token 220. The location data may take the form of global positioning system (GPS) data collected by GPS sensor circuitry of the electronic device 201 , e.g., a GPS antenna. The token circuitry 210 may generate a contract token to include location coordinates (such as latitude and longitude coordinate data), altitude or elevation data, bearing, route data, nearby points of interest, or any other data indicative of a location of the electronic device 201. The location data may record a position of the electronic device 201 at which the contract offer token 220 was generated or sent, thus serving to track a particular user location upon presenting a contract offer or entering an agreement.
[0019] As another example of sensor data, the token circuitry 210 may include digital image data in the contract offer token 220. The electronic device 201 may include a digital camera or other image capture circuitry, and the token circuitry 210 may cause capture of a digital image to include within the contract offer token 220. For instance, the token circuitry 210 may cause capture of a user image through a front-facing camera of the electronic device 201 , which may record or verify a particular user, person, agent, individual, or other entity presenting the offer terms specified in the contract offer token 220. The digital image may, as another example, depict the surroundings of the electronic device 201. An image of the device surroundings may verify or record a location of the electronic device 201, for example in combination with location data included with the contract offer token 220.
[0020] As more examples of sensor data, the token circuitry 210 may include accelerometer data or gyroscope data indicating an orientation of the electronic device 201. A proximity sensor (such as infrared circuitry) may capture proximity data for the electronic device 201 , which the token circuitry 210 may include as part of the contract offer token 220. Barometer data tracking atmospheric pressure or temperature data indicating ambient temperature conditions are other examples of sensor data the token circuitry 210 may access to include in a generated token.
[0021] As yet another example of sensor data, the token circuitry 210 may access user-specific sensor data to include in the contract offer token 220. For instance, the token circuitry 210 may cause sensor circuitry of the electronic device 201 to capture a user heart rate via a heart rate monitor or a user finger print via a fingerprint sensor. When the electronic device 201 includes a pedometer, the token circuitry 210 may access pedometry data, such as a number of steps tracked by the electronic device 201 within a predetermined time period prior to generating or sending the contract offer token 220. These user-specific sensor data may indicate, authenticate, or confirm the user as the contract offeror for the contract offer token 220.
[0022] Through any of the above examples of sensor data, the token circuitry 210 may record environment data with respect to the electronic device 201 when the contract offer token 220 is generated, allowing present or subsequent authenticity verification of the contract offer token 220. The specific types of sensor data included in a contract token may be configurable, e.g., through user request, adjusting token generation parameters referenced by the token circuitry 210, or in various other ways. The token circuitry 210 may access sensor data previously captured by the sensor circuitry and locally stored on the electronic device 201. Or, the token circuitry 210 may cause the sensor circuitry to capture sensor data as part of the token generation process. In some examples, the sensor circuitry of the electronic device 201 automatically captures sensor data in response to a token generation trigger, such as a user indication to generate a contract token.
[0023] Aside from sensor data, the token circuitry 210 may include various other elements within a contract token as well. For example, the token circuitry 210 may specify a contract type for the contract offer token 220. The contract type may denote a field or category with respect to the contract offer terms of contract formed through acceptance of the contract offer terms. As another example, the token circuitry 110 may include a date and time within the contract offer token 220, which may specify the date and time the contract offer token 220 was generated. For a contract offer token, the token circuitry 210 may include a token element indicating an offer validity period in the contract offer token 220, after which an offer specified through the contract offer token 220 expires. While some example token elements have been described, the token circuitry 210 may include any element that specifies any aspect of a contract, agreement, or understanding represented through the token.
[0024] A token element may differentiate a particular contract token from other contract tokens. In that regard, the token circuitry 210 may generate the contract offer token 220 to include an identification value, such as through a global unique identifier (GUID) according to any implementation of the universally unique identifier (UUID) standard. The token circuitry 210 may thus differentiate the contract offer token 220 from other contract tokens generated or received by the token circuitry 210. The identification value may likewise differentiate a particular token generated by an electronic device from other tokens also generated by the electronic device.
[0025] Upon generating the contract offer token 220, the token circuitry 210 may send the contract offer token 220 to a different electronic device. The different electronic device may be an electronic device of a user or entity to which the contract offers terms are offered to. In the example shown in Figure 2, the token circuitry 210 sends the contract offer token 220 to the electronic device 202. The token circuitry 210 may send the contract offer token 220 through a direct connection between the electronic device 201 and the electronic device 202, such as through a direct wired connection (e.g., via a linking cable) or direct wireless connection (e.g., via a near field communication link, a Bluetooth link, or other forms of direct wireless links). In other examples, the token circuitry 210 utilizes an indirect data connection to send the contract offer token 220 to the electronic device 202.
[0026] Upon receiving of the contract offer token 220, token circuitry 212 of the electronic device 202 may process the contract offer token 220. The token circuitry 212 may extract particular elements of the contract offer token 220 to present, such as through a user interface of the electronic device 202. Through the user interface, the token circuitry 212 may present contract offer terms specified in the contract offer token 220, the offering device sensor data 221 , other contract token elements, or combinations thereof. Also, the token circuitry 212 may present an acceptance prompt via the user interface, through which a user may indicate an acceptance or rejection of the contract offer terms. When the contract offer terms are accepted, the token circuitry 212 may obtain an acceptance indication through the acceptance prompt in the user interface.
[0027] The token circuitry 212 may generate a contract acceptance token that includes an acceptance indication for the contract offer terms specified in the contract offer token 220. In the example shown in Figure 2, the token circuitry 212 generates the contract acceptance token 230. The contract acceptance token 230 may include sensor data captured by the electronic device 202, shown as the accepting device sensor data 231 in Figure 2. For the contract acceptance token 230, the token circuitry 212 may include any number of types of sensor data to record or authenticate the contract acceptance indication, including any combination of the sensor data discussed above with respect to the contract offer token 220. The token circuitry 212 may include any number of other contract token elements discussed above as part of the contract acceptance token 230 as well. Then, token circuitry 212 may send the contract acceptance token 230 to the electronic device 201 as a response to the contract offer token 220.
[0028] In some examples, the token circuitry 212 obtains a rejection indication for the contract offer terms specified in the contract offer token 220. In these examples, the token circuitry 212 may generate and send a contract rejection token to the electronic device 201. In contrast to the contract acceptance token, the contract rejection token may instead include a rejection indication for contract offer terms, though the contract rejection token may nonetheless include any of the sensor data or other token elements discussed above. By including sensor data in a contract acceptance token or contract rejection token generated in response to the contract offer token 220, the token circuitry 212 may support present or subsequent authenticity validation of a response to the contact offer terms, which may resolve disputes over the validity or existence of a contract or offer rejection.
[0029] Electronic devices may exchange distinct contract tokens with one another. To illustrate, the contract offer token 220 generated by the token circuitry 210 of the electronic device 201 may be a distinct, separate data file from the contract acceptance token 230 generated by the token circuitry 212 of the electronic device 202. The contract offer token 220 and contract acceptance token 230 may include different GUIDs, for example, through which electronic devices may identify the tokens 220 and 230 as separate.
[0030] Token circuitry of an electronic device may pair correlated contract tokens. For instance, the token circuitry 210 may send the contract offer token 220 to the electronic device 202 as well as store the contract offer token 220 on a local memory of the electronic device 201 or at a remote storage location. Upon receiving a response to the contract offer token 220, the token circuitry 210 may pair the response with the contract offer token 220 to record the contract token exchange for subsequent reference. Thus, in the example shown in Figure 2, the token circuitry 210 may pair the contract offer token 220 with the contract acceptance token 230 from the electronic device 202. When the electronic device 202 responds to the contract offer token 220 with a contract rejection token, the token circuitry 210 may pair the contract offer token 220 with the contract rejection token. To pair correlated contract tokens, the token circuitry 210 may store the correlated tokens in a common table entry, link the GUIDs of the correlated tokens, or add an entry to a pairing table mapping correlated tokens.
[0031] The token circuitry of an electronic device may secure a contract token to prevent tampering. To do so, the token circuitry may employ secure access mechanisms to limit access to token elements once a contract token is generated. The token circuitry may use any form of cryptography, public key infrastructure (PKI) mechanisms, digital signatures, or other access control technologies to prevent an unauthorized device or party from altering a contract token. In some examples, the token circuitry may secure a contract token upon generation. In other examples, the token circuitry may secure a contract token upon resolution, e.g., upon generation or reception of a contract acceptance token or a contract rejection token that responds to a contract offer token. In these examples, the token circuitry may secure the correlated token pair to prevent tampering after acceptance of a contract or rejection of contract offer terms.
[0032] As described above, token circuitry of an electronic device may support an exchange of contract tokens with other electronic devices. Doing so may provide an efficient and reliable mechanism to electronically record or effectuate an agreement between parties. Sensor data included within or accompanying a contract token may provide an authenticity indicator, to a different electronic device to which a contract token is sent or upon subsequent reference. While the above examples illustrate token exchange in the form of a contract token, the token circuitry 210 and 212 may provide token exchange capabilities for any type of agreement or promise. Token circuitry may include a set of predefined agreement or contract types that a user may select from when exchanging tokens through electronic devices. In some examples, the token circuitry may support generation and exchange of custom token types, e.g., with specific parameters, terms, or format different from the predefined types provided by the token circuitry.
[0033] As one example, the token circuitry of an electronic device may support exchange of contract tokens for non-financial contracts, promises, obligations, and agreements. Thus, the token circuitry may generate and exchange tokens recording barter exchanges or an agreement involving action without monetary terms. As another example, the token circuitry may support exchange of tokens for unilateral promises, actions, or agreements. In this example, the token circuitry 210 may generate and send a token to the electronic device 202 indicating a unilateral promise and the token circuitry 212 of the electronic device 202 may respond with an acknowledgment token. Thus, token exchange capabilities provided by the token circuitry may record or validate various types of transactions, agreements, and promises between parties. While many of illustrations presented herein relate to contract tokens, the token circuitry may consistently implement the features described above and below for token exchanges of any type.
[0034] Returning to the contract token exchange shown in Figure 2, the electronic device 201 and the electronic device 202 may each store the contract offer token 220 and the contract acceptance token 230 after the exchange. Thus, either electronic device may support archiving and reference of the contract exchange for subsequent reference. In some examples, the electronic device 201 , the electronic device 202, or both, may store paired contract tokens in a remote location, one example of which is shown in Figure 3 through a token authority.
[0035] Figure 3 shows an example of an electronic device 201 storing contract tokens at a token authority 310. In particular, the token circuitry 210 may send a contract offer token 220 and a contract acceptance token 230 to the token authority 310 for archival. The token authority 310 may support subsequent retrieval of the correlated token pair by an electronic device that generated a token among the correlated contract tokens. Thus, for a token pairing of the contract offer token 220 and the contract acceptance token 230, the token authority 310 may grant access to the electronic device 201 (which generated the contract offer token 220) and the electronic device 202 (which generated the contract acceptance token 230). [0036] The token authority 310 may be remote to the electronic device 201. Thus, the token authority 310 may provide non-local storage of contract tokens or correlated token pairs. The token authority 310 may take the form of any remote system accessible to the electronic device 201 , such as a cloud server or a web server. The token authority 310 may include circuitry and logic to implement any of the token authority features described herein. In some examples, the token authority 310 authenticates the electronic device 201 prior to storing a token on behalf of the electronic device 201. The token authority 310 may implement any number of authentication techniques, such as verifying user login and password data provided by the token circuitry 210 of the electronic device 201.
[0037] The token authority 310 may support token exchanges between electronic devices. In some examples, the token authority 310 itself generates tokens to exchange between electronic devices. By doing so, the token authority 310 may provide a consistent format and common generation entity for tokens exchanged between electronic devices. In these examples, the token authority 310 may regulate token generation as well, for example by limiting token generation for a particular electronic device based on any number of token generation criteria. One illustration of a contract token exchange through the token authority 310 is provided through Figures 4 and 5.
[0038] Figure 4 shows an example of a contract token exchange between electronic devices through the token authority 310. In the example shown in Figure 4, the electronic device 201 initiates a contract token exchange with the electronic device 202. To do so, the token circuitry 210 of the electronic device 201 obtains an offer term 421 and sensor data 422, for example according to any of the features discussed above. The token circuitry 210 may send the offer term 421 and the sensor data 422 to the token authority 310 for generation of a contract offer token that includes the offer term 421 and sensor data 422. The token circuitry 210 may also send a target device indication to the token authority 310, indicating the electronic device 202 as the target electronic device to receive the contract offer token generated by the token authority 310.
[0039] The token authority 310 may generate a contract offer token according to the offer term 421 and sensor data 422 received from the token circuitry 210 of the electronic device 201. In Figure 4, the token authority 310 generates the contract offer token labeled as 430, which includes the offer term 421 and sensor data 422 provided by the electronic device 201. The token authority 310 may include any combination of the token elements discussed above within the contract offer token 430 as well, which the token authority 310 may obtain from the electronic device 201 (e.g., as provided by the token circuitry 210 with the offer term 421 and sensor data 422) or via other mechanisms. After generating the contract offer token 430, the token authority 310 may send the contract offer token 430 to the electronic device 202. The token authority 310 may archive the contract offer token 430 as well.
[0040] In some examples, the token authority 310 generates the contract offer token 430 upon determining that any number of token generation criteria are satisfied. The token generation criteria applied by the token authority 310 may be configurable, for example by a system administrator or user request. A token generation criterion may be particular to the electronic device 201 , such as a criterion limiting the number of tokens the electronic device 201 can generate or receive to a threshold number (e.g., over a predetermined period of time). As another example, a token generation criterion may limit particular offer terms or token elements to upper or lower limits, e.g., an upper purchase price threshold, an upper limit on an offer validity period, or various other numerical limits. These limits may apply particularly to the electronic device 201 , to a class of devices or user types, or for each token generated by the token authority 310.
[0041] In some implementations, the token authority 310 applies contract generation criteria to control the quality or type of sensor data provided by the electronic device 201. Thus, the token authority 310 may require a threshold image quality or image resolution for sensor data 422 in the form of a user image. The token generation criteria may specify specific sensor data types that the electronic device 201 should send in order to generate a contract offer token or a requisite capture time that the sensor data 422 must satisfy (e.g., captured within a recent time threshold such as within the previous 24 hours, within the last 2 minutes, or within the 10 seconds prior to sending to the token authority 310). When a token generation criterion applied by the token authority 310 is not satisfied, the token authority 310 may determine not to generate a contract offer token for the electronic device 201.
[0042] Figure 5 shows another example of a contract token exchange between electronic devices through the token authority 310. In Figure 5, the electronic device 202 may receive the contract offer token 430 from the token authority 310, and the token circuitry 212 of the electronic device 202 may respond with an acceptance indication 521 and sensor data 522 captured by the electronic device 202. The token circuitry 212 may send the acceptance indication 521 and the sensor data 522 to the token authority 310 for generating a contract acceptance token 530 that responds to the contract offer token 430.
[0043] Upon receiving the acceptance indication 521 and the sensor data 522, the token authority 310 may generate the contract acceptance token 530 and send the contract acceptance token 530 to the electronic device 201. The token authority 310 may apply token generation criteria for generating the contract acceptance token as well, including any combination of the criteria discussed above.
[0044] In the example shown in Figure 5, the token authority 310 generates the contract acceptance token 530 to include both the acceptance indication 521 and the sensor data 522 captured by the electronic device 202. In other examples, the token authority 310 may generate a token to include selected portions of the sensor data provided by an electronic device. In these other examples, the token authority 310 may include some, but not all, of the sensor data 522 in the contract acceptance token 530. In some examples, the token authority 310 does not include any of the sensor data 522 in the contract acceptance token 530, though the token authority 310 may store the sensor data 522 for subsequent reference or token validation. The token authority 310 may flexibly vary the particular sensor data included in generated tokens according to system requirements for authenticity, efficiency, resource consumption, or various other factors.
[0045] In the examples shown in Figures 4 and 5, the token authority 310 may itself generate tokens according to token generation criteria. However, the token authority 310 may validate tokens generated by electronic devices. The token authority 310 may validate the content, form, or integrity of a generated token. To illustrate, an electronic device may send a generated token to the token authority 310 for validation, and prior to sending the token to a target electronic device. The token authority 310 may validate the token authority according to any number of token validation criteria, which may include any combination of the token generation criteria described above. The token authority 310 may determine whether contract terms are valid or within threshold parameters. The token authority 310 may confirm a generated token is generated according to a particular format, data type, or structure. Regarding integrity, the token authority 310 may verify that the token has not been tampered, e.g., by verifying the structural integrity of a generated token. For a custom token, the contract authority 310 may verify the integrity or format of the custom token, but not the content as the content may be user-specific. Thus, the token authority 310 may validate, limit, or control token exchanges between electronic devices even when the token authority 310 itself does not generate the tokens.
[0046] Upon determining a particular token passes token validation criteria applied by the token authority 310, the token authority 310 may provide a validation indication to the electronic device that generated the particular token. The token authority 310 may, for instance, embed the validation indication within the particular token itself by setting a particular field in the token, adding a digital signature for the token authority 310, or in any number of other ways. Then, the token authority 310 may return the particular token with the embedded validation indication to the electronic device that first generated the particular token. As other examples, the token authority 310 may provide the validation indication as a separate message to the electronic device indicating the particular token has been validated. Upon receiving the validation indication, the electronic device may then send the particular token to the target electronic device.
[0047] Figure 6 shows an example of logic 600 that an electronic device may implement to support exchange of contract tokens including sensor data. The electronic device may implement the logic 600 through token circuitry of the electronic device, for example as hardware, executable instructions stored on a machine-readable medium, or in various other ways. As such, the token circuitry of the electronic device may perform or execute the logic 600 as a method to support contract token exchange.
[0048] The token circuitry of the electronic device may obtain, through a user interface of the electronic device, an offer term for a contract (602). The token circuitry may also receive a token indication to send a contract offer token to a different electronic device, for example also through the user interface. To include with the contract offer token, the token circuitry may access sensor data captured through sensor circuitry of the electronic device (604). In some examples, the token circuitry instructs the sensor circuitry to capture the sensor data after receiving the token indication, including any of the sensor data examples provided above. The token circuitry may then generate a contract offer token that specifies the offer term and includes the sensor data (606) as well as send the contract offer token that includes the sensor data to a different electronic device (608).
[0049] In some examples, the token circuitry may further receive a contract acceptance token different from the contract offer token. The contract acceptance token and contract offer token may have different GUIDs for example. The token circuitry may pair the contract offer token with the contract acceptance token, thus linking the tokens as part of a common exchange or transaction. The token circuitry may store the contract offer token, the contract acceptance token, or both at a token authority. Prior to sending the contract offer token to the different electronic device, the token circuitry may validate the contract offer token with a token authority. The token authority may apply any number of criteria to determine whether to validate the generated contract offer token, including any of the token validation or token generation criteria presented above.
[0050] Figure 7 shows an example of an electronic device 700 that supports exchange of contract tokens including sensor data. The electronic device 700 may be any electronic device, such as a computing system shown in Figure 7, a mobile phone, a tablet device, or any other electronic device. The electronic device 700 may include a processor 710. The processor 710 may include a central processing unit (CPU), microprocessor, and/or any hardware device suitable for executing instructions stored on a machine-readable medium. [0051] The electronic device 700 may include a machine-readable medium 720. The machine-readable medium 720 may be any non-transitory electronic, magnetic, optical, or other physical storage device that stores executable instructions, such as the contract token instructions 722 shown in Figure 7. Thus, the machine-readable medium 720 may be, for example, Random Access Memory (RAM), an Electrically-Erasable Programmable Read-Only Memory (EEPROM), a storage drive, an optical disk, and the like.
[0052] The electronic device 700 may execute instructions stored on the machine-readable medium 720 through the processor 710. Executing the instructions may cause the processor 710 to perform or support any combination of the features described herein, including any features of the token circuitry described above. To illustrate, executing the contract token instructions 722 may cause the processor 710 to obtain an offer term for a contract through a user interface of the electronic device 700 and capture sensor data through sensor circuitry of the electronic device 700. In some examples, the contract token instructions 722 cause the processor 710 to obtain a non-financial offer term as the offer term. Executing the contract token instructions 722 may further cause the processor 710 to send the offer term and the sensor data to a token authority for generating, by the token authority, a contract offer token that includes the offer term and the sensor data and for sending, by the token authority, the contract offer token that includes the sensor data to a different electronic device.
[0053] In some examples, executing the contract token instructions 722 causes the processor 710 to capture the sensor data by capturing GPS data through a GPS sensor circuitry of the electronic device 700 and send the sensor data by sending the GPS data to the token authority for generating a contract offer token that includes the GPS data. In other examples, executing the contract token instructions 722 causes the processor 710 to capture the sensor data by capturing a user image through a camera of the electronic device 700 and send the sensor data by sending the user image to the token authority for generating a contract offer token that includes the user image. The contract token instructions 722 may support generation of non-financial tokens, e.g., tokens without financial terms. Thus, executing the contract token instructions 722 may cause the processor 710 to send the offer term and the sensor data to a token authority for generating, by the token authority, a contract offer token without a financial offer term.
[0054] The methods, devices, systems, and logic described above, including the token circuitry, may be implemented in many different ways in many different combinations of hardware, executable instructions stored on a machine-readable medium, or both. For example, token circuitry may include circuitry in a controller, a microprocessor, or an application specific integrated circuit (ASIC), or may be implemented with discrete logic or components, or a combination of other types of analog or digital circuitry, combined on a single integrated circuit or distributed among multiple integrated circuits. A product, such as a computer program product, may include a storage medium and machine readable instructions stored on the medium, which when executed in an endpoint, computer system, or other device, cause the device to perform operations according to any of the description above.
[0055] The processing capability of the systems, devices, and circuitry described herein, including the token circuitry, may be distributed among multiple system components, such as among multiple processors and memories, optionally including multiple distributed processing systems. Parameters, databases, and other data structures may be separately stored and managed, may be incorporated into a single memory or database, may be logically and physically organized in many different ways, and may implemented in many ways, including data structures such as linked lists, hash tables, or implicit storage mechanisms. Programs may be parts (e.g., subroutines) of a single program, separate programs, distributed across several memories and processors, or implemented in many different ways, such as in a library, such as a shared library (e.g., a dynamic link library (DLL)). The DLL, for example, may store code that performs any of the system processing described above.
[0056] While various examples have been described above, many more implementations are possible.

Claims

1. A method comprising:
by token circuitry of an electronic device:
obtaining, through a user interface of the electronic device, an offer term for a contract;
accessing sensor data through sensor circuitry of the electronic device; generating a contract offer token that specifies the offer term and includes the sensor data; and
sending the contract offer token that includes the sensor data to a different electronic device.
2. The method of claim 1 , wherein:
accessing the sensor data comprises accessing a user image captured through a camera of the electronic device; and
generating the contract offer token comprises generating the contract offer token to include the user image.
3. The method of claim 1 , wherein:
accessing the sensor data comprises accessing location data captured through a location sensor circuitry of the electronic device; and
generating the contract offer token comprises generating the contract offer token to include the location data.
4. The method of 1 , further comprising, prior to sending the contract offer token to the different electronic device:
validating the contract offer token with a token authority.
5. The method of 1 , further comprising, after sending the contract offer token: receiving a contract acceptance token from the different electronic device, the contract acceptance token different from the contract offer token and including an acceptance indication for the offer term specified in the contract offer token; and pairing the contract offer token with the contract acceptance token to form a contract token pair.
6. The method of 5, wherein the contract offer token and the contract acceptance token differ by having differing global unique identifier values.
7. The method of claim 5, wherein the contract acceptance token further includes sensor data captured by the different electronic device.
8. An electronic device comprising:
sensor circuitry to capture sensor data; and
contract token circuitry to:
generate a contract acceptance token comprising:
an acceptance indication; and
the sensor data captured by the sensor circuitry; and
send the contract acceptance token comprising the sensor data to a different electronic device.
9. The device of claim 8, wherein the contract token circuitry is to generate the contract acceptance token after receiving a contract offer token from the different electronic device.
10. The device of claim 9, wherein the contract token circuitry is further to pair the contract acceptance token with the contract offer token from the different electronic device.
11. The device of claim 9, wherein the contract offer token specifies a non- financial offer term; and
wherein the contract token circuitry is to generate the contract acceptance token to include the acceptance indication for the non-financial offer term.
12. A non-transitory machine-readable medium storing executable instructions that, when executed by a processor, cause the processor to:
obtain an offer term for a contract through a user interface of an electronic device;
capture sensor data through sensor circuitry of the electronic device; and send the offer term and the sensor data to a token authority for generating, by the token authority, a contract offer token that includes the offer term and the sensor data and for sending, by the token authority, the contract offer token that includes the sensor data to a different electronic device.
13. The non-transitory machine-readable medium of claim 12, wherein the executable instructions cause the processor to:
capture the sensor data by capturing global positioning system (GPS) data through a GPS sensor circuitry of the electronic device; and
send the sensor data by sending the GPS data to the token authority for generating a contract offer token that includes the GPS data.
14. The non-transitory machine-readable medium of claim 12, wherein the executable instructions further cause the processor to:
capture the sensor data by capturing a user image captured through a camera of the electronic device; and
send the sensor data by sending the user image to the token authority for generating a contract offer token that includes the user image.
15. The non-transitory machine-readable medium of claim 12, wherein the executable instructions cause the processor to send the offer term and the sensor data to a token authority for generating, by the token authority, a contract offer token without a financial offer term.
PCT/US2015/032083 2015-05-21 2015-05-21 Contract token including sensor data WO2016186678A1 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/US2015/032083 WO2016186678A1 (en) 2015-05-21 2015-05-21 Contract token including sensor data
EP15892779.8A EP3298723A4 (en) 2015-05-21 2015-05-21 Contract token including sensor data
US15/575,794 US11961154B2 (en) 2015-05-21 2015-05-21 Contract token including sensor data

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/US2015/032083 WO2016186678A1 (en) 2015-05-21 2015-05-21 Contract token including sensor data

Publications (1)

Publication Number Publication Date
WO2016186678A1 true WO2016186678A1 (en) 2016-11-24

Family

ID=57318948

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2015/032083 WO2016186678A1 (en) 2015-05-21 2015-05-21 Contract token including sensor data

Country Status (3)

Country Link
US (1) US11961154B2 (en)
EP (1) EP3298723A4 (en)
WO (1) WO2016186678A1 (en)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
SG10201610686SA (en) * 2016-12-20 2018-07-30 Mastercard International Inc Systems and methods for processing a payment transaction authorization request
KR20200039982A (en) * 2018-10-08 2020-04-17 현대자동차주식회사 multi device system, AND CONTROL METHOD THEREOF

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080289020A1 (en) * 2007-05-15 2008-11-20 Microsoft Corporation Identity Tokens Using Biometric Representations
US20090117883A1 (en) * 2006-07-20 2009-05-07 Dan Coffing Transaction system for business and social networking
US20140025583A1 (en) * 2009-07-02 2014-01-23 Biometric Payment Solutions Electronic transaction verification system with biometric authentication
US20150026057A1 (en) * 2013-07-19 2015-01-22 Bank Of America Corporation Completing mobile banking transaction with different devices
US20150112774A1 (en) * 2013-10-22 2015-04-23 Retailmenot, Inc. Providing Offers and Associated Location Information

Family Cites Families (23)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5794207A (en) * 1996-09-04 1998-08-11 Walker Asset Management Limited Partnership Method and apparatus for a cryptographically assisted commercial network system designed to facilitate buyer-driven conditional purchase offers
US20080141033A1 (en) * 1995-02-13 2008-06-12 Intertrust Technologies Corporation Trusted and secure techniques, systems and methods for item delivery and execution
US6240396B1 (en) * 1996-09-04 2001-05-29 Priceline.Com Incorporated Conditional purchase offer management system for event tickets
MY134895A (en) * 2000-06-29 2007-12-31 Multimedia Glory Sdn Bhd Biometric verification for electronic transactions over the web
CA2418050C (en) * 2000-08-04 2014-05-20 First Data Corporation Linking public key of device to information during manufacture
EP1209579A1 (en) * 2000-11-21 2002-05-29 DR. Riccardo Genghini Studio Notarile Genghini System for automatic performing transactions by active identity managment
US20020147607A1 (en) * 2001-02-14 2002-10-10 Sarvajit Thakur Automated INS application filing system
US20050027608A1 (en) * 2003-07-29 2005-02-03 Andreas Wiesmuller System and method for providing commercial services over a wireless communication network
JP2005128996A (en) * 2003-09-30 2005-05-19 Dainippon Printing Co Ltd Information processing apparatus and system, and program
CN101122977A (en) * 2006-08-09 2008-02-13 鸿富锦精密工业（深圳）有限公司 Contract electronic signing and checking system and method
US20090077386A1 (en) * 2007-06-08 2009-03-19 Jeffrey Alan Simonian Notary enforcement - fraud prevention
US20090083064A1 (en) * 2007-09-24 2009-03-26 David Mahinda Competitive online prescription pricing system
US20090298491A1 (en) * 2008-06-03 2009-12-03 United Parcel Service Of America, Inc. Contract Acceptance Systems and Methods
US20110270751A1 (en) * 2009-12-14 2011-11-03 Andrew Csinger Electronic commerce system and system and method for establishing a trusted session
SG182664A1 (en) * 2010-01-26 2012-08-30 Geodesixs Inc A trading apparatus and method
US20120110681A1 (en) * 2010-11-03 2012-05-03 Yat Wai Edwin Kwong Systems for email communications
US20120198570A1 (en) * 2011-02-01 2012-08-02 Bank Of America Corporation Geo-Enabled Access Control
US8655796B2 (en) * 2011-06-17 2014-02-18 Sanjay Udani Methods and systems for recording verifiable documentation
US10706132B2 (en) * 2013-03-22 2020-07-07 Nok Nok Labs, Inc. System and method for adaptive user authentication
US20150006474A1 (en) * 2013-06-28 2015-01-01 Pingstripe, Inc Secure cloud based document storage and management system and method
US20150112778A1 (en) * 2013-10-22 2015-04-23 Microsoft Corporation Offer sharing
US10032133B2 (en) * 2014-01-24 2018-07-24 Adobe Systems Incorporated Automatically identifying authorized signatories from an organization for executing an electronic document
US20150269692A1 (en) * 2014-03-18 2015-09-24 Jed Ryan Electronic Contract Creator

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20090117883A1 (en) * 2006-07-20 2009-05-07 Dan Coffing Transaction system for business and social networking
US20080289020A1 (en) * 2007-05-15 2008-11-20 Microsoft Corporation Identity Tokens Using Biometric Representations
US20140025583A1 (en) * 2009-07-02 2014-01-23 Biometric Payment Solutions Electronic transaction verification system with biometric authentication
US20150026057A1 (en) * 2013-07-19 2015-01-22 Bank Of America Corporation Completing mobile banking transaction with different devices
US20150112774A1 (en) * 2013-10-22 2015-04-23 Retailmenot, Inc. Providing Offers and Associated Location Information

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP3298723A4 *

Also Published As

Publication number Publication date
US20180144422A1 (en) 2018-05-24
EP3298723A1 (en) 2018-03-28
US11961154B2 (en) 2024-04-16
EP3298723A4 (en) 2019-01-09

Similar Documents

Publication Publication Date Title
US11550935B2 (en) Method, apparatus, and electronic device for blockchain-based recordkeeping
US20230129693A1 (en) Transaction authentication and verification using text messages and a distributed ledger
EP3721578B1 (en) Methods and systems for recovering data using dynamic passwords
US11621827B2 (en) Blockchain validation system
US10958438B2 (en) Method, apparatus, and electronic device for blockchain-based recordkeeping
US11831710B2 (en) Tracking and certification of digital media via distributed ledger
US10601859B2 (en) Anti-replay systems and methods
WO2020063176A1 (en) Method and device for user identity authentication in network
KR20200081448A (en) Cross blockchain authentication method and device
US9596234B2 (en) Methods and systems for providing bidirectional authentication
CN104903902A (en) Systems and methods for authenticating user based on biometric model associated with user
CN111600716A (en) Authentication method and device and electronic equipment
US10812458B2 (en) Systems and methods for two-factor location-based device verification
US11961154B2 (en) Contract token including sensor data
US20170187700A1 (en) Pregenerated two-factor authentication tokens
US20230316274A1 (en) Activity authentication using time-based one-time password
KR20160039593A (en) Method for Providing OTP based on Location
JP2023136248A (en) Information processing apparatus, information processing method, and information processing program
JP2023135821A (en) Information processing apparatus, information processing method, and information processing program

Legal Events

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

Ref document number: 15892779

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15575794

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2015892779

Country of ref document: EP