Patent Application
20150089605
This patent document contains material subject to copyright protection. The copyright owner has no objection to the reproduction of this patent document or any related materials in the files of the United States Patent and Trademark Office, but otherwise reserves all copyrights whatsoever.
This invention relates to enabling digital transactions, and, more particularly, to enabling digital transactions with credential provided by interaction with a physical object.
As used herein, unless used otherwise, the following terms or abbreviations have the following meanings:
API means Application Program(ing) Interface;
DNS means Domain Name System;
EAN means European Article Number;
FQDN means Fully Qualified Domain Name;
GTIN means Global Trade Item Number;
HTTP means Hyper Text Transfer Protocol;
HTTPS means HTTP Secure;
JAN means Japanese Article Number;
NFC means near field communication;
“QR code” means Quick Response Code (“QR code” is a trademark for a type of matrix barcode or two-dimensional barcode);
RFID means radio frequency identification;
SKU means stock-keeping unit
UPC means Universal Product Code;
URI means Uniform Resource Identifier;
URL means Uniform Resource Locator;
UTC means coordinated universal time.
Various other objects, features and attendant advantages of the present invention will become fully appreciated as the same becomes better understood when considered in conjunction with the accompanying drawings, in which like reference characters designate the same or similar parts throughout the several views, and wherein:
As used herein, an “object” may be any item or entity, including, without limitation, a physical and/or material and/or or immaterial item, a virtual item, a location, an event, a thing, a person, a place, an image, a sound, etc.
As used herein, the term “mechanism” refers to any device(s), process(es), service(s), or combination thereof A mechanism may be implemented in hardware, software (e.g., as a software module), firmware, using a special-purpose device, or any combination thereof A mechanism may be integrated into a single device or it may be distributed over multiple devices. The various components of a mechanism may be co-located or distributed. The mechanism may be formed from other mechanisms. In general, as used herein, the term “mechanism” may be considered to be shorthand for the term device(s) and/or process(es) and/or service(s).
A client device 102 may be running multiple applications, e.g., applications related to the functionality of the device. For example, if the device is a phone, the device may be running multiple applications relating to its functionality as a phone. At least one client application 106 (i.e., an application running on client device 102) may interface with or be integrated with a client module 108 providing functionality according to embodiments hereof
The client application 106 may interact and interface with the client module 108 in any known manner in order for the client module to provide information to or obtain information from the client application 106. It should be appreciated, however, that the system is not limited by the manner in which the client application 106 and the client module 108 interact or interface. For example, the client module 108 may be a plug-in associated with the client application 106, or the client module 108 may be a linked or dynamically linked library to which the client application 106 may link, or the client module may be provided as a separate application that the client application 106 may invoke.
In general, the client module 108 is a mechanism and thus may be implemented in hardware, software, firmware, using a special-purpose device, or any combination thereof. Those of ordinary skill in the art will appreciate and understand, upon reading this description, that the client module 108 may be provided in multiple parts or components that may interact with each other and or with the client application 106 in multiple ways.
In a presently preferred implementation, the client module 108 is a software module provided to the client application 106 in source or object code form and incorporated appropriately by the client application, e.g., at compile or link time. Thus, although shown logically in the drawings as two separate components, those of ordinary skill in the art will realize and appreciate, upon reading this description, that in a particular implementation the client application 106 and client module 108 may comprise a single application 109.
Upon request or invocation by the client application 106, the client module 108 provides functionality to invoke and/or control aspects of the client device 102 (e.g., to invoke and/or control sensor(s) such as camera(s) on the client device 102) in order, e.g., to obtain information about an object 104. In a presently preferred implementation the client module 108 uses one or more cameras on the client device 102 to obtain at least one image of an object 104. It should be appreciated that the client module 108 may, in addition to or instead of image data, obtain or determine other data associated with the object 104.
An object 104 may include object one or more indicia 110. As used herein, the term “indicia,” although plural, refers to one or more markings such as alphanumeric markings, barcodes, etc. Indicia may encode information. Indicia may include, for example, a numeric code (such as a serial number, SKU, UPC, JAN, EAN, GTIN, or the like), a one-dimensional barcode, a two-dimensional barcode (such as a QR code) or the like. A particular object 104 may include multiple object indicia 110 which may be encoded and/or associated with the object in the same manner or in different manners. It should be appreciated that the system is not limited by the type or number (if any) of object indicia 110 on any particular object 104, or by the manner in which such indicia are incorporated in or associated with the object. For example, indicia may be printed on the object, printed on a tag or label or sticker or wrapper associated with the object, etched into the object, engraved on the object, etc. Different indicia on the same object may be incorporated in or associated with that object in different ways. It should further be appreciated, as explained below, that some objects 104 may not include any indicia 110 (or at least not include any usable indicia).
Although the client module 108 is described herein as preferably using one or more cameras associated with a client device 102, it should be appreciated that other sensors may be used instead of or in addition to a camera. For example, if the client device has the ability to read contactless tags (e.g., RFID or NFC tags), the client module 108 may also (or instead) obtain object indicia using this ability.
The framework 100 also includes an object information service 112 that maintains information about objects and at least one object identification service 114 (both described in greater detail below).
The object information service 112 generates, maintains, uses, and hosts persistent and structured information profiles that describe and store information about individual objects known to the object information service 112. The object information service 112 may use object information application(s) 116 to perform some or all of its functionality, including generating, maintaining, accessing, using, and hosting the persistent and structured information profiles that describe and store information about individual objects.
The object information service 112 preferably maintains information about individual objects in one or more object databases 118. Each object 104 for which the object information service 112 maintains information has a unique object identifier associated therewith within the object information service 112, and information about each particular object within the object information service 112 is preferably keyed or indexed on the unique object identifier for that particular object. Thus, given a particular unique object identifier corresponding to a particular object, the object information service 112 may use that particular unique object identifier to operate on (e.g., use, access, etc.) that particular object.
The object identification service 114 may include or have access to one or more image recognition services 115.
As used herein, the term “access” means, without limitation, to read, write, copy, update, or use in any way.
Those of ordinary skill in the art will realize and appreciate, upon reading this description, that information within the object information service 112 may also be keyed or indexed on other information or keys.
Although shown in the drawings separate components, it should be appreciated that the object information service 112 and object identification service 114 may be collocated or even implemented on the same device(s).
The object database(s) 118 may use any known methods of storing and accessing object information, and the scope of the system is not limited by the manner in which information is stored or accessed in the object database(s) 118. At least some of the object database(s) 118 may be co-located with the object information service 112, however the object database(s) may be fully or partially located apart from the object information service 112.
Information in object database(s) 118 may be accessed by object information application(s) 116, e.g., through application programming interfaces (APIs) 120. The object information application(s) 116 preferably include one or more applications to support functions such as creation, storage, update, and access of object information object database(s) 118. Exemplary APIs are described in greater detail below.
Access to information in the object information service 112 preferably requires authorization by the object information service, and is preferably authorized for users who are required to be registered in some manner with the object information service 112.
In some exemplary implementations the object information service 112 may use one or more rules databases 124 in order to provide some or all of the functionality. Rules database(s) 124 may be used to support policy/rule-based interaction with the object information. The rules database(s) 124 may be updated.
In order to obtain the unique object identifier associated with a particular object (e.g., a physical object), a client application 106 may interact with an object identification service 114 via an associated client module 108. An object identification service 114 may thus be used to try to identify an object 104 and to provide the invoking client module 108 with a unique identifier for a particular object, based, e.g., on information about the particular object (e.g., processed image and processed image information) it receives from the client module 108. The client module 108 may then provide this unique object identifier to an associated client application 106.
The unique object identifier is preferably a URI (or included in a URI), and an object identification service 114 preferably provides the client module that invoked it with a URI associated with the object 104.
The unique object identifier (e.g., a URI) may be included on and/or directly encoded into an object, e.g., as on object indicia 110 on the object 104. For example, a URI may be encoded in a QR code associated with (e.g., attached to or engraved printed on) an object. It should be appreciated that in such cases the client module 108 may determine the unique object identifier without accessing the object identification service 114. In some cases, even when the unique object identifier is determined without acing the object identification service 114, the client module may access the object identification service 114 and/or the object information service 112 in order to confirm or verify the unique object identifier.
The syntax of URIs is defined in Network Working Group “Uniform Resource Identifier (URI): Generic Syntax,” RFC 3986, STD 66, January, 2005, the entire contents of which are incorporated herein by reference for all purposes. For the purposes of this description, a URI representing or comprising a unique object identifier preferably has the form: <scheme>://<domain>/<path>/<id>
Where <scheme> is “http” or preferably “https”, <domain> is a domain name (preferably a FQDN) that resolves to the object information service 112; <path> is an optional field that represents a path on the object information service 112, and <id> is an identifier (or name) that is unique within the object information service 112.
By way of example, if the object information service 112 (or the APIs 120 associated with the object information service 112) may be accessed at the domain api.evrythng.com, and the <path> is “thugs” (described below with reference to an exemplary API), and a particular object has the unique identifier such as “504766a7c8f205a0744243c1” within the object information service 112, then the URI corresponding to that particular object may look like:
The object information service 112 is preferably an online software web service accessed via network 122 (e.g., the Internet). The object information service 112 is preferably operated independently of client applications. An object identification service 114 is preferably an online web service, and a client module 108 may interact with the object identification service 114 via a network 122 (e.g., the Internet). Although shown in the drawings as using the same network 122, it should be appreciated that the client module need not access the object identification service 114 using the same network as is used to access the object information service 112.
The client application 106 and/or client module 108 may access the various services (object information service 112, object identification service 114) by any connection mechanism(s) or combinations thereof, including wired (e.g., WAN, LAN), wireless (e.g., WiFi), cellular, etc. The system is not limited by the manner or type of connection mechanism(s) used to access the various services.
An object identification service 114 may make use of third party services (not shown) to assist it in identifying the object type, e.g., via image processing or the decryption of a URI encoded in information it receives from a client module 108.
With reference to
This section describes exemplary data structures, object information applications used by/in object information service 112, as well as a public API 120 to those applications.
The API 120 preferably follows the RESTful architectural principles, which means it tries to get the best out of HTTP and the Web. The API 120 may be used in a programming language or via any HTTP client that handles at least POST and GET.
Those of ordinary skill in the art will realize and appreciate, upon reading this description, that the applications, data structures, and API described here are given only by way of example, and any particular embodiment or implementation may use different and/or other applications, data structures, and APIs.
As can be seen in the following, the API allows users to access the functionality (e.g., the object information applications 116) of the object information service 112 using a domain associated with the object information service 112. In the case of a specific object, the domain is preferably specified in the URI comprising the unique object identifier for that specific object. Thus, as will be appreciated by those of ordinary skill in the art will realize and appreciate, upon reading this description, the URI comprising the unique object identifier for a specific object provides a way to access the object information service 112 with respect to that object.
API Overview
A central data structure in the exemplary object information service 112 is referred to as Thngs which are data containers to store all the data generated by and about any object. Various properties can be attached to any Thng, and the content of each property can be updated any time, while preserving the history of those changes. Thngs can be added to various Collections which support sharing a set of Thngs with other Users within the object information service.
Thng
A Thng is essentially an abstract notion of an object which may have property data (e.g., location data) associated with it. Also called Active Digital Identities (ADIs), these resources can model objects such as real-world elements (e.g., persons, places, cars, guitars, mobile phones, etc.). Every thng in the object information service 112 is assigned a unique identifier (ThngID) at creation time. The unique identifier is necessary to access/edit the ding.
An example basic (JSON) document schema of a Thng (as stored within object information service 112) is as follows:
Property
A Thng may have various and arbitrary properties, preferably stored as arbitrary key/value pairs. The values may be updated individually at any time, and may be retrieved historically (e.g., “Give me the values of property X between 10 am and 5 pm on the Aug. 16, 2012”).
Location
Each Thng preferably has a special type of Properties used to store snapshots of its geographic position over time (e.g., as GPS latitude and longitude coordinates).
User
Each interaction with the object information service 112 is preferably authenticated and a user is preferably associated with each action. This approach dictates security access.
Collection
A collection is a grouping of Thngs. Collections can be created by various users, and the same Thng may be in more than one collection.
HTTP Verbs
The exemplary API preferably uses appropriate HTTP verbs for each action, as described, e.g., in the following table:
If no errors has occurred when processing a request, the user will preferably receive one of the reply codes, as described, e.g., in the following table
HTTP Error Codes
When calling the API a user might get an error code, which the user must preferably handle within their application. Error codes may include the following:
Errors preferably also return a payload (e.g., a JSON payload) with error message(s) associated.
Authentication
Access to the API 120 is preferably via HTTPS requests to a domain associated with the object information service 112 (or with the API of the object information service 112), e.g., https://api.OIS.com. Unencrypted HTTP requests may be accepted, although the use of secure HTTP (HTTPS) is preferred in order to store any valuable data.
Every request to the API 120 preferably includes an API key using an Authorization HTTP header to identify the user or application issuing the request and execute it if authorized.
The following is an example request to the API 120 that returns a list of all of the Thngs the user has created (in the following examples https://api.OIS.com is used as a domain associated with the object information service 112):
Create a Single Thng
To create a Thng, POST a JSON document to the /thngs resource. For example:
In response to this POST, the object information service creates an object (Thng) and assigns it a unique ID—the {ThngID}.
Get a Single Thng
To read the data from a thng, do a GET on the THNG URI (returned in the Location header when the thng was created)
Example Query:
GET “https://api.OIS.com/thngs/504766a7c81205a0744243c1”
Update a Thng
A user can update the data of a thng using any subset of a valid document model. The fields are entirely replaced by the new values, so to add a tag for example the user must submit the previous tag array with the new tags. For example:
Deleting a Thng
To delete a thng, send a DELETE to the thng URI.
Example Query:
DELETE ‘https://api.OIS.com/thngs/504766a7c81205a0744243c1’
Get the List of all Thngs
To retrieve the list of all the thngs you have created, do a GET on the /thugs resource.
Example Query:
GET ‘https://api.OIS.com/thngs’
Each ADI can have many properties (which may be arbitrary key/value pairs). Each property update is preferably time stamped and stored, therefore one can retrieve the set of all the values of a property during a specific time range. Properties may have the form:
A Properties JSON document is an array of Objects that always contain a key, a value, and a timestamp. If the optional timestamp is not provided when updating the property, it is automatically set at the moment when the request has been processed.
Updating Properties
When an object is created, a user may specify an initial set of properties and their values. To update those properties or to add new ones subsequently, the user may use PUT on the /thngs/{ThngID}/properties endpoint, with a “Properties” JSON object. If the properties being updated do not exist, they are created automatically by this request and no error/notification is returned.
In a presently preferred implementation, in order to cope with the limitations of mobile network providers a user may use both POST or PUT to update properties, e.g.:
The returned payload is an array of the properties updated, not all the properties.
Example Query:
Get the List of all Properties
A user may retrieve a list of all the properties of a thng using GET on the /thngs/{ThngID}/properties endpoint, e.g.,
The returned payload is the complete array of all the properties with the last value of each.
Example Query:
Get a Single Property
To retrieve the history of each property (their value over time), a user must access the unique endpoint for each property. By default, all the updates of this property are returned using pagination in a reverse history fashion (the first element of the returned array is the last update). An example document schema for a unique property is as follows:
Note that in contrast to <Properties>, the <Property> object model does not have the “key” element as it is already contained in the URL of the resource. E.g.,
For accessing only a subset of all the updates to a single property, A user can specify a time range the ?from=<timestamp> and ?to =<timestamp> to specify respectively the beginning and end of the time window, you will receive an array of all the property updates during this time.
Example Query:
Update a Single Property
In the same manner, properties can be updated individually using their individual endpoint.
Example Query:
Deleting Individual Properties
Property updates are not individually identified, so the only way to delete data points is to append the ?to =<timestamp> URL query parameter to specify a point in time before which all the data points will be removed.
Example Query:
As ADIs may be made to model real-world entities, all thngs preferably also have a special set of properties, called Locations, which model the actual position of the object in space over a time period. The Location document model is as follows:
In presently preferred implementations longitude is a float between [−180;180], while latitude is a float between [−90;90]
Update the Location
Just like properties, the location of a thng can be updated at any time via the /location endpoint of the thng. The payload must always be an array of Location objects, which allows sending several locations (with different timestamps each) to be sent in one single request. This feature is useful for example when a device wants to update a path over a certain period of time. An example would be a taxi that updates the whole set of locations it has been through over the last hour (instead of sending each GPS sensor reading individually).
To cope with the limitations of mobile network providers a user can use both POST and PUT to update the location of a thng.
Example Query:
Note that the first Location object doesn't have a timestamp intentionally, which will be automatically assigned by the engine to the time the request has been processed.
Read the Locations
To access the list of all the location updates for a thng, send a GET to the /location endpoint of the thng.
Example Query:
Deleting Location Updates
Location updates are also not individually identified, so the only way to delete data points is to append the ?to =<timestamp> URL query parameter to specify a point in time before which all the updates will be removed.
Example Query:
Products are similar to thngs, but instead of modeling an individual object instance, products are used to model a class of objects. Products may be used for general classes of thngs, usually a particular model with specific characteristics. Products are useful to capture the properties that are common to a set of thngs.
To create a new Product, POST a JSON document that describes a product to the /products endpoint.
The response payload contains the complete Product document and its URL in the Location header. The URL may look like https://api.OIS.com/products/[PROD-ID], where the [PROD-ID] is the unique product identification number. This number can be then stored in the product field of any thng in the engine, which means that the thng is a unique instance of this particular product.
A collection is a set of thngs that make it easier for users to manage all the thngs they created. Collections have a similar data model to other entities in the engine (a name and description, tags and properties) and are created in a similar manner. Once a collection has been created, users can add or remove manually thngs to that collection, using the /thngs sub-resource of each collection.
The Collection document model is as follows:
A user can create a Collection of thngs by POSTing a JSON document to the /collections endpoint.
Get a Single Collection
Get all Collections
List an authenticated user's collections of thngs:
Editing a Collection
To update a collection, PUT the updated JSON document of the collection to its URI.
Deleting a Collection
Collections can be deleted via sending a DELETE on their URI.
List all Thngs in a Collection
The list of all the thngs in a collection can be retrieved via a GET on the /thngs resource of a collection, as follows:
Example Query:
Adding (Existing) Thngs to a Collection
Thngs can be a collection by PUTing an array with their respective IDs to the /thugs.
Example Query:
Removing a Thug from a Collection
Thngs can be removed from within a collection, by sending a DELETE to their ID within the {CollectionID}/thngs sub-resource of a collection.
Example Query:
Removing all Thngs from a Collection
All thngs within a collection can be removed by sending a DELETE to the
Example Query:
The API endpoint /search allows users to search all the thngs, product, collections, etc. in the object information service 112 to which they have access.
A present implementation supports three search modes (although other search modes may be used): (1) searching a string in any field (free-text search); (2) searching only in a subset of the fields available (field search); and (3) searching for entities based on their geographic location (geographic search). In a present exemplary implementation the modes are mutually exclusive (and so cannot be combined within a single request).
1. Free-text Search:
To search a string over all fields, a user can use the following endpoint:
Find all entities that contain one or more of the strings provided. Results are ordered by relevance, so the first results are those that contain most of the search terms.
Searches for all entities that contain any field matching ‘sensor’ or ‘temperature’.
2. Field Search:
A user can also search over the various fields of any entity in the engine (can be collections, thngs, products etc.) by searching for a string in a specific field of the document.
Find all entities that contain the given string in their field called FieldName. Several field parameters can be given, and the results are ordered by the entities that contain most of the matching parameters.
Finds all entities that contain the string “tv” in their name field or the string ‘plasma’ in their description.
3. Geographic Search:
A user can use the geographic search to filter for entities based on their geographic locations (e.g. “give me all guitars within 500m from my home”), by using the lat, long, maxDist query parameters to specify the search area.
Search for entities whose location are close to the provided latitude (lat=[−180;180]) and longitude (lat=[−180;180]). Optionally, a user can specify the radius for the results using the maxDist=[distance], where distance is the radius in kilometers from the given lat/lon point (by default maximal search radius is 10 Km).
Searches for all entities within a radius of 10 Km from the GPS coordinate lat=43.2 and longitude=−27.1.
By default, the search looks over all types of entities in the engine (thngs, products, and collections). A user may limit the entities to be searched to only some specific types using the type=<String>[,<String>], where <String>=[thng|product|collection]. For example, to search only thngs or product that contain the keyword ‘Alaska’, GET the following URL:
Product Recognition Service APIs
The APIs preferably supports a product recognition service on the endpoint /recognize where an application can POST an image, and which returns information available about the product or a barcode (e.g., 1D or 2D) in the image. These product recognition APIs may be accessed, e.g., by object identification service 114 and/or directly by the client. This makes it straightforward to use the system and related services without the need to implement a barcode scanner/decoder in the client application.
Decode a Barcode Image
The APIs preferably provides multiple image recognition endpoints available where a user may POST an image. If the user knows that the image has a 1D or 2D barcode in it, the user can post the image to the /recognize/barcode to speed up the recognition process. If the user knows that the image is a product, then the user should preferably post it to the /recognize/product endpoint. If the user does not know what the image contains, then they should POST it to /recognize/. The returned object has the same model in all cases.
Exemplary operation of the system 100 (and 100′) is described here with reference to the flowchart in
With reference to the flowchart in
With reference to the flow chart in
Once it obtains the URI for an object's profile in the object information service 112, the client application may use that URI (or information therein) to interact with the object information service 112 with respect to that object. Preferably the client application uses the URI to address and thereby access the API 120.
Recall that each user may have a user identity (ID) 216 or some form of identification within the system. In some cases the system may create or generate a unique object identifier as a function of user identity (ID) 216 and other information determined from or about the object. For example, if the object has a unique product code (e.g., a UPC code), the system may generate the unique object identifier for that object as a function of the user identifier information and the product information. Those of ordinary skill in the art will thus realize and appreciate, upon reading this description, that two distinct users (i.e., two users with different user IDs within the system) may, and preferably will, get different unique object identifiers for the same object. In this manner, each particular user's interactions with each object may be monitored and tracked, and each particular user may have a specific and customized interaction with the system (and with the object information service 112) about the object.
As noted, a unique object identifier may be provided as a URI. However, since the client may already know some of the information needed in the URI (e.g., the domain and path), in some cases the object identification service 114 need only provide the identifier to the client. For example, if the client already knows that the object information service 112 (or the APIs 120 associated with the object information service 112) may be accessed at the domain api.evrythng.com, and the <path> is “thugs”, and a particular object has the unique identifier “504766a7c8f205a0744243c1” within the object information service 112, then the client need only be provided with the unique identifier in order to form the URI corresponding to that particular object:
Those of ordinary skill in the art will realize and appreciate, upon reading this description, that a client module may access and interact with the object identification service 114 in any manner (e.g., via a cellular network, satellite network, or in some other fashion, including combinations of approaches), and the system is not limited by the manner in which such communication or interaction takes place. Similarly, the manner in which a client application interacts with object information service 112 may take place in any manner, and the system is not limited by the manner in which such communication occurs.
Uniqueness
While the drawings show only one object information service 112, it should be appreciated that there may be more than one object information service 112. However, a “unique” object identifier is preferably unique within a particular object information service 112, and client interactions preferably take place with the object information service 112 that issued or created or supports the unique object identifier.
The following are examples of application of the system disclosed herein. These use cases are provided only as examples and are not intended to be in any way limiting of the invention.
Use Case 1
In this scenario, a user installs an application on his mobile phone. It then launches the application, which runs the client software code described above and takes a photo of a product. The product photo is then sent to an identification server application to be identified. A product SKU (or some such indicia) is found in the image, and a unique product identity for that object for the user is generated on the fly. The user can then attach personalized multimedia content (for example a photo of himself) and he can then invite another friend to view the photo.
Use Case 2.
In this scenario, a user buys a bottle of wine that has a UPI tag attached. The user sees an advertisement on a wine review website that prompts him to scan his bottle to take part in a contest. The user clicks on the advertisement, which starts the camera of the device and he can then scan the UPI tag on his bottle. Because the product is verified as genuine and has not yet been used to take part in the contest, the user's participation is validated and the user enters the contest.
Use Case 3.
In this scenario, as in Use case 2, a user buys a bottle of wine that has a UPI tag attached. In this case the UPI tag is a bar code (such as a QR code) that encodes a unique object identifier, e.g., in the form of a URI. The user starts an application and determines the URI associated with the bottle. The user then uses that URI to access information about the bottle and/or to prove ownership of or access to the bottle.
Enabling Digital Transactions with Credential Provided by Interaction with a Physical Object
With reference to
The TA service 402 may also have access to one or more third-party authorization services 414.
Many applications, e.g., electronic games, and the like, make use of existing micro-transaction methods whereby additional services or capabilities are authorized using so-called “in-app” transactions and whereby a payment is made via payment gateway to obtain a credential and from within an application.
In one aspect, the system 100″ allows a user/client to prove or confirm (within an application, and to the satisfaction of the application and perhaps some other external system) that the user/client has some relationship or association with a particular object. The relationship or association may be one of possession (e.g., that the user/client has possession of the object), or it may be one of access (e.g., that the user/client has access to the object). As used herein, the term “has” will be used to cover possession, ownership, access, etc. So, for example, the phrase “a user has an object” means, without limitation, that the user may have the object, may have possession of the object, may have ownership of the object, may have access to the object, etc. It should be appreciated that possession and/or access may be physical and/or virtual. It should be appreciated that, as used herein, the term “possession” does not imply any legal concept of ownership.
Exemplary operation of embodiments including transaction authorization (TA) services 402 are described with reference to the framework in
Each object is preferably uniquely identifiable within the framework 100″. In presently preferred implementations each object 104 has a unique product identity that is preferably provided as object indicia 110 in some association with the object, e.g., by being encoded with a unique product identity tag. The object indicia may be, e.g., a unique identity credential in the form of a URI encoded onto a physical tag attached to a physical product, for example within a barcode (e.g., a QR Code) or other form of printed representation that can be read by image-based scanning through a client device 102.
When a user of client application 106 (e.g., a game or the like) wants to confirm that the user has an object, the application 106 uses the client module 108 and, if needed, object identification service(s) 114 and object information service 112 (e.g., as described above with reference to
In some exemplary embodiments, upon request by the client application 106, the client module 108 provides functionality to control the camera on the client device to capture an image of the object indicia (e.g., a printed product identity tag) on the object. The client module 108 may perform processing on the captured image on client device to extract and/or derive information from the image, and then passes the (possibly processed) image and optionally extracted (and/or derived) information to an online object identification service 114.
As described above, the object identification service 114 is a service (preferably and online web service) that may identify an object based on information (e.g., processed image and processed image information) it receives from a client module 108 used by a specific client application 106. The object identification service 114 determines the corresponding unique identity (e.g., URI) for the object in the object information service 112, and returns that unique identity (e.g., URI) to the requesting client module 108.
A transaction authorization service (TAS) 402 is used to authorize a transaction request by the client application. The TAS 402 is preferably an online web service with a transaction authorization API 406. The client application 106 provides certain information to the transaction authorization service 402 (at S418), preferably via the transaction authorization API 406. The information provided by the client application 106 to the transaction authorization service 402 preferably includes the unique identity credential—UIC (e.g., a URI) for the object. The information provided by the client application 106 to the transaction authorization service 402 may also include other information to be used by the transaction authorization service 402 to confirm (or deny) authorization, along with administrative and/or billing information. For example, the information provided to the TAS 402 may include one or more of: (i) an identifier of the client application, (ii) an identifier of the user; and (iii) an identifier of the requested transaction. Those of ordinary skill in the art will realize and appreciate, upon reading this description, that the TAS 402 may use some or all of the information provided by the client application 106 as well as different/other information from other sources.
Upon receipt of a request from a client application 106, the request including a unique identity credential for a particular object, the TAS 402 tries to authorize a transaction associated with the particular object (at S420). The TAS 402 performs an approval of a requested transaction by applying various rules (e.g., business logic rules). The rules may be stored and maintained in TA Rules Database(s) 412 and may have been previously defined via APIs and by interacting with third party authorization service(s)/gateway(s) 414, if required. The rules may be any kind of rules, and it should be appreciated that the system is not limited by the kind of rules that a particular TAS 402 may implement. For example, the rules may relate to information about a product, the context of the request (for example time of day or the location of the user), or other logic (e.g., the user can only get authorized for this object with a certain frequency, e.g., once per month).
The transaction authorization service 402 provides either a positive or negative response to the invoking client 106 via the TA API(s) 406 (at 5422, S424). With reference to the flowchart in
In the case of a positive reply (an authorization), the TAS 402 preferably provides the invoking client with a transaction credential confirming the authorization. The transaction credential may be signed by the TAS 402, e.g., using a private key of the TAS 402. For this purpose the TAS 402 may have access to a Certification Authority (CA) or the like.
The credential is preferably used within the application to enable or support an aspect of the application. As used herein, an “aspect” of an application may include one or more of: (i) a feature of the application; (ii) an amount of virtual currency within the application; (iii) a reward within said application; and (iv) a purchase within said application.
The client application may thus use the transaction credential, e.g., in order to activate the relevant virtual product or service within the application.
Those of ordinary skill in the art will realize and appreciate, upon reading this description, that different and/or other aspects of an application may be enabled or supported using the process described herein.
Those of ordinary skill in the art will realize and appreciate, upon reading this description, that as the authorization of a transaction (and the issuance of a credential for a transaction) may depend of rules, a particular transaction may be denied by a TAS 402, and that the same transaction may be authorized by a subsequent request. This may occur, e.g., when the rules associated with that transaction are time-based and/or frequency based. This may also occur, e.g., because the TA rules database(s) 412 may be updated to change the rules after the first request.
The following are additional examples of application of the system disclosed herein for enabling digital transactions with credential(s) provided by interaction with a physical object. These use cases are provided only as examples and are not intended to be in any way limiting of the invention.
Use Case 4
A user plays an adventure game on his mobile phone. Because he has lost all his lives and does not want to start the game from the beginning he has the choice to receive an additional life by paying money (e.g., 1ε) with his credit card, or to buy one of the limited summer edition of Ben & Jerry's ice cream. He buys one of these limited ice creams and clicks on the corresponding button in the application (game), which opens the camera application on his mobile phone. The user takes a photo of the unique product UPI tag inside the cover of the ice cream package. The application determines a URI for the particular ice cream (using an object identification service and object information service). The game application then uses the URI in the tag to query the transaction authorization service with the requested transaction. Predefined business rules may be used verify whether the product has already been used by someone else, and returns a positive answer if the business rules are validated.
Use Case 5
A user in a hotel room would like to use a video on demand (VOD) service on his TV. Because the VOD service has a partnership with his luxury watch brand, he can use his mobile phone to scan the unique UPI tag attached to the TV. This opens a Web page on the VOD service that allows him to scan the unique UPI tag on his luxury watch to allow him to watch a free movie of his choice. Because he has not yet taken advantage of this offer that month using his watch, the authorization service authorizes the digital transaction to take place by issuing a request to the VOD service.
Use Case 6
A user is running an application on a mobile device (such as a smartphone). The user wants to enable (or re-enable) a feature of the application and one way to do so is to prove that the user has obtained (perhaps purchased) sweets (i.e., candy) of a particular brand. The user selects a button or some other mechanism on the application that causes the application to take one or more pictures of one or more candy wrappers that the user has. The candy wrapper(s) may have indicia such as barcodes (QR codes), serial numbers, or the like. The application then uses the picture(s) to obtain one or more corresponding identifiers for the wrapper(s). The application then provides the one or more identifiers to an authorization service that confirms that they are valid and have not been previously used. The authorization service provides the application with a credential which it then uses to enable (or re-enable) the feature.
The services, mechanisms, operations and acts shown and described above are implemented, at least in part, by software running on one or more computers or computer systems or user devices. It should be appreciated that each user device is, or comprises, a computer system.
Programs that implement such methods (as well as other types of data) may be stored and transmitted using a variety of media (e.g., computer readable media) in a number of manners. Hard-wired circuitry or custom hardware may be used in place of, or in combination with, some or all of the software instructions that can implement the processes of various embodiments. Thus, various combinations of hardware and software may be used instead of software only.
One of ordinary skill in the art will readily appreciate and understand, upon reading this description, that the various processes described herein may be implemented by, e.g., appropriately programmed general purpose computers, special purpose computers and computing devices. One or more such computers or computing devices may be referred to as a computer system.
According to the present example, the computer system 500 includes a bus 502 (i.e., interconnect), one or more processors 504, one or more communications ports 514, a main memory 506, optional removable storage media 510, read-only memory 508, and a mass storage 512. Communication port(s) 514 may be connected to one or more networks (e.g., computer networks, cellular networks, etc.) by way of which the computer system 500 may receive and/or transmit data.
As used herein, a “processor” means one or more microprocessors, central processing units (CPUs), computing devices, microcontrollers, digital signal processors, or like devices or any combination thereof, regardless of their architecture. An apparatus that performs a process can include, e.g., a processor and those devices such as input devices and output devices that are appropriate to perform the process.
Processor(s) 504 can be (or include) any known processor, such as, but not limited to, an Intel® Itanium® or Itanium 2® processor(s), AMD® Opteron® or Athlon MP® processor(s), or Motorola® lines of processors, and the like. Communications port(s) 514 can be any of an RS-232 port for use with a modem based dial-up connection, a 10/100 Ethernet port, a Gigabit port using copper or fiber, or a USB port, and the like. Communications port(s) 514 may be chosen depending on a network such as a Local Area Network (LAN), a Wide Area Network (WAN), a Content Delivery Network (CDN), or any network to which the computer system 500 connects. The computer system 500 may be in communication with peripheral devices (e.g., display screen 516, input device(s) 518) via Input/Output (I/O) port 520. Some or all of the peripheral devices may be integrated into the computer system 500, and the input device(s) 518 may be integrated into the display screen 516 (e.g., in the case of a touch screen). The input device(s) 518 may include one or more sensors 519 that may comprise one or more image sensors (or cameras) 521.
Main memory 506 can be Random Access Memory (RAM), or any other dynamic storage device(s) commonly known in the art. Read-only memory 508 can be any static storage device(s) such as Programmable Read-Only Memory (PROM) chips for storing static information such as instructions for processor(s) 504. Mass storage 512 can be used to store information and instructions. For example, hard disks such as the Adaptec® family of Small Computer Serial Interface (SCSI) drives, an optical disc, an array of disks such as Redundant Array of Independent Disks (RAID), such as the Adaptec® family of RAID drives, or any other mass storage devices may be used.
Bus 502 communicatively couples processor(s) 504 with the other memory, storage and communications blocks. Bus 502 can be a PCI/PCI-X, SCSI, a Universal Serial Bus (USB) based system bus (or other) depending on the storage devices used, and the like. Removable storage media 510 can be any kind of external hard-drives, floppy drives, Compact Disc—Read Only Memory (CD-ROM), Compact Disc—Re-Writable (CD-RW), Digital Versatile Disk—Read Only Memory (DVD-ROM), etc.
Embodiments herein may be provided as one or more computer program products, which may include a machine-readable medium having stored thereon instructions, which may be used to program a computer (or other electronic devices) to perform a process. As used herein, the term “machine-readable medium” refers to any medium, a plurality of the same, or a combination of different media, which participate in providing data (e.g., instructions, data structures) which may be read by a computer, a processor or a like device. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media include, for example, optical or magnetic disks and other persistent memory. Volatile media include dynamic random access memory, which typically constitutes the main memory of the computer. Transmission media include coaxial cables, copper wire and fiber optics, including the wires that comprise a system bus coupled to the processor. Transmission media may include or convey acoustic waves, light waves and electromagnetic emissions, such as those generated during radio frequency (RF) and infrared (IR) data communications.
The machine-readable medium may include, but is not limited to, floppy diskettes, optical discs, CD-ROMs, magneto-optical disks, ROMs, RAMs, erasable programmable read-only memories (EPROMs), electrically erasable programmable read-only memories (EEPROMs), magnetic or optical cards, flash memory, or other type of media/machine-readable medium suitable for storing electronic instructions. Moreover, embodiments herein may also be downloaded as a computer program product, wherein the program may be transferred from a remote computer to a requesting computer by way of data signals embodied in a carrier wave or other propagation medium via a communication link (e.g., modem or network connection).
Various forms of computer readable media may be involved in carrying data (e.g. sequences of instructions) to a processor. For example, data may be (i) delivered from RAM to a processor; (ii) carried over a wireless transmission medium; (iii) formatted and/or transmitted according to numerous formats, standards or protocols; and/or (iv) encrypted in any of a variety of ways well known in the art.
A computer-readable medium can store (in any appropriate format) those program elements that are appropriate to perform the methods.
As shown, main memory 506 is encoded with application(s) 522 that support(s) the functionality as discussed herein (an application 522 may be an application that provides some or all of the functionality of one or more of the mechanisms described herein). Application(s) 522 (and/or other resources as described herein) can be embodied as software code such as data and/or logic instructions (e.g., code stored in the memory or on another computer readable medium such as a disk) that supports processing functionality according to different embodiments described herein.
During operation of one embodiment, processor(s) 504 accesses main memory 506, e.g., via the use of bus 502 in order to launch, run, execute, interpret or otherwise perform the logic instructions of the application(s) 522. Execution of application(s) 522 produces processing functionality of the service(s) or mechanism(s) related to the application(s). In other words, the process(es) 524 represents one or more portions of the application(s) 522 performing within or upon the processor(s) 504 in the computer system 500.
It should be noted that, in addition to the process(es) 524 that carries (carry) out operations as discussed herein, other embodiments herein include the application 522 itself (i.e., the un-executed or non-performing logic instructions and/or data). The application 522 may be stored on a computer readable medium (e.g., a repository) such as a disk or in an optical medium. According to other embodiments, the application 522 can also be stored in a memory type system such as in firmware, read only memory (ROM), or, as in this example, as executable code within the main memory 506 (e.g., within Random Access Memory or RAM). For example, application 522 may also be stored in removable storage media 510, read-only memory 508, and/or mass storage device 512.
Those skilled in the art will understand that the computer system 500 can include other processes and/or software and hardware components, such as an operating system that controls allocation and use of hardware resources.
As discussed herein, embodiments of the present invention include various steps or operations. A variety of these steps may be performed by hardware components or may be embodied in machine-executable instructions, which may be used to cause a general-purpose or special-purpose processor programmed with the instructions to perform the operations. Alternatively, the steps may be performed by a combination of hardware, software, and/or firmware. The term “module” refers to a self-contained functional component, which can include hardware, software, firmware or any combination thereof.
One of ordinary skill in the art will readily appreciate and understand, upon reading this description, that embodiments of an apparatus may include a computer/computing device operable to perform some (but not necessarily all) of the described process.
Embodiments of a computer-readable medium storing a program or data structure include a computer-readable medium storing a program that, when executed, can cause a processor to perform some (but not necessarily all) of the described process.
Where a process is described herein, those of ordinary skill in the art will appreciate that the process may operate without any user intervention. In another embodiment, the process includes some human intervention (e.g., a step is performed by or with the assistance of a human).
Thus is described a mechanism for an application on a client device (smartphone, tablet computer or similar device) to interact with an object (product or other object) to obtain an identifier credential and using this credential connect with an online information profile associated with that specific physical object. Thus is also described a mechanism for a framework for enabling digital transactions with credential(s) provided by interaction with a physical object.
Aspects of the system may be used by the application to deliver functions or services informed by information from or about the physical object it is interacting with and obtained by the application from the object's online profile, or for information about the physical object collected by the application to be passed to the object's online profile for access by third parties.
As used in this description, the term “portion” means some or all. So, for example, “A portion of X” may include some of “X” or all of “X”. In the context of a conversation, the term “portion” means some or all of the conversation.
As used herein, including in the claims, the phrase “at least some” means “one or more,” and includes the case of only one. Thus, e.g., the phrase “at least some ABCs” means “one or more ABCs”, and includes the case of only one ABC.
As used herein, including in the claims, the phrase “based on” means “based in part on” or “based, at least in part, on,” and is not exclusive. Thus, e.g., the phrase “based on factor X” means “based in part on factor X” or “based, at least in part, on factor X.” Unless specifically stated by use of the word “only”, the phrase “based on X” does not mean “based only on X.”
As used herein, including in the claims, the phrase “using” means “using at least,” and is not exclusive. Thus, e.g., the phrase “using X” means “using at least X.” Unless specifically stated by use of the word “only”, the phrase “using X” does not mean “using only X.”
In general, as used herein, including in the claims, unless the word “only” is specifically used in a phrase, it should not be read into that phrase.
As used herein, including in the claims, the phrase “distinct” means “at least partially distinct.” Unless specifically stated, distinct does not mean fully distinct. Thus, e.g., the phrase, “X is distinct from Y” means that “X is at least partially distinct from Y,” and does not mean that “X is fully distinct from Y.” Thus, as used herein, including in the claims, the phrase “X is distinct from Y” means that X differs from Y in at least some way.
As used herein, including in the claims, a list may include only one item, and, unless otherwise stated, a list of multiple items need not be ordered in any particular manner. A list may include duplicate items. For example, as used herein, the phrase “a list of XYZs” may include one or more “XYZs”.
It should be appreciated that the words “first” and “second” in the description and claims are used to distinguish or identify, and not to show a serial or numerical limitation. Similarly, the use of letter or numerical labels (such as “(a)”, “(b)”, and the like) are used to help distinguish and/or identify, and not to show any serial or numerical limitation or ordering.
No ordering is implied by any of the labeled boxes in any of the flow diagrams unless specifically shown and stated. When disconnected boxes are shown in a diagram the activities associated with those boxes may be performed in any order, including fully or partially in parallel.
While the invention has been described in connection with what is presently considered to be the most practical and preferred embodiments, it is to be understood that the invention is not to be limited to the disclosed embodiment, but on the contrary, is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims.
This application claims the benefit of U.S. Provisional Application No. 61/882,608, filed Sep. 25, 2013, titled “Enabling Digital Transactions With Credential Provided By Interaction With An Object,” the entire contents of which are hereby fully incorporated herein by reference for all purposes. This application is related to U.S. provisional patent application 61/745,638, titled “A System, Method and a Tag for Mapping Tagged Objects to Context-Aware Applications,” filed Dec. 23, 2012, entire contents of which are fully incorporated herein by reference for all purposes.
| Number | Date | Country | |
|---|---|---|---|
| 61882608 | Sep 2013 | US |
