Barcodes and QR (Quick Response) codes are computer readable images for storing information which can be scanned by a scanning device and converted by a computer into data readable by a human. A barcode is scanned in one direction, while a QR code can be thought of a two-dimensional barcode. QR codes can include more information than barcodes and for this reason can be used in many situations where a barcode cannot be used due to the limited amount of data which can be included in a barcode.
Like barcodes, QR codes can be scanned using special purpose scanners or by the camera in a smartphone which can both detect and scan a QR code. QR codes are generated using a QR code generator as is well known in the art.
Applications for QR codes are almost unlimited, but are frequently used in advertising, business, health care, and education. QR codes can be found in brochures, flyers, posters, billboards, product packaging, business cards, and websites such as social media and shopping sites.
There are two types of QR codes: static and dynamic.
Static QR codes are QR codes that are permanently encoded with information that does not change. This type of QR code is static meaning the data encoded within the QR code will always produce the same result when scanned. Static QR code uses include email addresses, URLs, text, and WiFi passwords. That is, it is a single purpose QR code. The amount of data that can be encoded is limited. If too much data is encoded, scanning it will be less reliable since as the amount of data to be encoded increases, the denser the resulting OR code. As density increases, the more difficult it becomes to be properly scanned. Since the encoded data is the same as the data desired to be presented to a user, it can be used at any time in any location without access to any network.
As shown in
Dynamic QR codes are QR codes that store a short URL. When scanned, the linked data associated with the URL is retrieved and whatever action is desired when the link is selected will take place. That is, just as a link on a web page, when selected within a web browser, will produce some action, similarly, the link associated with the URL encoded by the QR code will be activated and any information at that link is transmitted to the device that sent the request after the QR code was scanned. For this reason, when a device scans a dynamic QR code, it must be connected to a network which can access the link associated with the URL obtained by scanning the QR code.
Since a dynamic QR code when scanned links to is embedded URL, it is a simple matter to set up that URL so that it redirects to another URL as a function of additional information provided by the device accessing the URL. The additional information can be the browser being used by the device, the device operating system, the device type, e.g. mobile phone or tablet. The redirected URL can then be set up to provide data in the best form for that device type and browser. Although dynamic QR codes provide more flexibility than static QR codes, they cannot be used to tailor to content to specific end user devices. Additionally, like a static QR code, the only information provided to a website accessed by the decoded URL is the address of device which made the request and possibly information about the browser on the device so that the delivered content can be properly rendered on the device.
Thus, static QR codes and dynamic QR codes are similar in that the embedded value is a static value such as a URL. For example, an admin creates a QR code with a value of a URL “http://www.example1.com/abcdef”. Any end-user device that scans the code will be sent to that web address. However, in the case of a static QR code, the end-user will ALWAYS land on the http://www.example1.com/abcdef website. In the case of the dynamic QR code, an admin can setup a redirection at a later to another website such as “http://www.example2.com”. In this case, any end-user that scans the dynamic QR code will first land at the “http://www.example1.com/abcdef” site and then be redirected to http://www.example2.com.
The invention overcomes these limitation as described below.
The invention uses what can be referred as a sequential QR code or SQR code. Each time a SQR code is scanned (using a camera built into a mobile device such as a cell phone), a different user experience is obtained based on the sequential configuration and trigger settings. Although the SQR code is configured as a static QR code, its implementation as a SQR code enables many if not all of the advantages of a dynamic QR code. Although the data encoded in a SQR code is a URL, and, therefore, always links to the sane webpage, additional data provided by the device used to scan the SQR code enables additional actions to be taken.
Unlike the prior art, in the case of the SQR (sequential QR code), upon scanning, the end-user device will land on the http://www.example1.com/abcdef as in the prior art. However, a web app (website) or client device API presents a custom experience to the end-user based on targeting settings configured by an admin. This means, it is a static QR code with a dynamic web experience based on the uniqueness of the user (device UUID) accessing it and other information provided in addition to a URL and information about the browser on the device.
As shown in
The API client retrieves 313 the trigger ID (unique identifier value for the trigger) from the value decoded from the SQR Code. The identifier value decoded from the SQR code is usually just a URL. However, other possibilities include an app which can be accessed and executed on the device. The decoded value of the QR Code may be a “deep link”, which is a link that is used to launch an-in-app experience (non-web based). In either case, the API client is always a native app (including web browsers) that interacts with the back end server to request content on behalf of an end-user.
The API client requests 317 content from the backend server 303 using the trigger ID and device UUID as part of the request sent to the backend server. The content is simply content which exists on the backend server intended to be provided when requested by a client. Examples of such content include redeemable offers, calendar reminders, quizzes, messages, URL redirects, prizes.
The backend server uses the provided trigger ID and UUID to retrieve the trigger configuration, including the content sequence, and based on targeting and sequence parameters determines 319 which content item to send back to the API client. The content sequence normally includes an offer associated with the content such as a discount on the price of an item from a retail brand and also includes the redemption information and terms of use. The targeting parameters include time of day, location, device OS or any other parameter which is desired to be considered relevant to each offer. Further details are set forth below with reference to
The API client renders the content view using the content item such as an offer returned from the backend server and allows the user to save 323 the content to a digital wallet native app 327. A typical content view includes content brand, content title, content description, content main image, content secondary image, redemption code, redemption instructions, terms of use. The content is also saved 325 to a user account established on backend server 303.
The manner in which the API client renders the content view depends on the specifics of the content. The specific details of how the content is presented are not important to an understanding of the invention, and are generally well known in the art.
The digital wallet app 327 (e.g., Google® Pay, Apple® Pay, custom wallet, etc.) handles the saving of the content as well known in the art by adding the content to the digital wallet. The specific mechanisms employed are handled by the digital wallet app itself. The API client simply passes the content details to the digital wallet app on the end-user device.
The backend server authenticates 403 the user using the provided credentials.
Admin user creates 407 the content such as an offer to be delivered by brand, engagement points, as well as other offer parameters. Also, native wallet integration is enabled at this stage.
The assigned brand is simply the product or products which form the offer which is the subject of the campaign. Engagement points are assigned using criteria such as the location of the retail stores relevant to the content that is delivered (i.e. the location of a retail store where an offer can be redeemed). Other offer parameters include content brand, content title, content description, content main image, content secondary image, redemption code, redemption instructions, terms of use. Native wallet integration is enabled as follows: as part of the content configuration, the admin user is given the option (via a checkmark) to instruct the backend server to generate a native wallet pass that is made available to the API client for the insertion of the content into the native wallet application (i.e. Apple Pay, Google Pay) installed on the end-user device.
After the admin user has completed all elements which form the content such as offers to be presented to end-users, the specifics are saved 409 on the backend server 303.
The admin user repeats this process until the desired number of offers or other content are configured on the backend server. As many offers or other content as desired can be created and saved by repeating the preceding steps for each offer. That is, all offers which are to be sequentially delivered are created and saved.
Admin user creates 413 a SQR code trigger as follows. The sequence of offers or other content created in block 407 is specified. For example, assume that three offers have been created. The three offers can be presented in any order desired. That is, no matter when an offer has been created. It can be presented before or after any other offer, as desired. Delivery settings are configured as delivery mode settings such as Delivery mode=Sequential or Random or Multiple. Sequential means that offers are delivered sequentially in a specified order. Random means that offers are delivered in a random order. Multiple delivery mode means that upon request, the backend server will respond with more than one content item based on the preconfigured target settings.
The admin user assigns any other targeting parameters such as time of day, location, device OS to be used as an SQR trigger
The following table illustrates one possible campaign scenario:
Other types besides offer include Message, Redirect, Prize, Question, URL.
The Brand Name is the trademark for a product or retail store name or other similar identifier. The Brand Point of Interest represent a geographical location (latitude/longitude) relevant a specific brand. For example: the location of a Walmart retail store in Los Angeles, Calif. where an offer for the brand Coke can be redeemed.
The Image is simply a picture of the product, retail store logo, etc. The Redemption code is the code the user uses to exercise the offer or other type of content. Enable Native Wallet is a flag which specifies whether or not the offer or other type of content can be stored in a digital wallet app on the user's mobile device.
Trigger types other than SQR include Media Trigger, Hyperlink Trigger, Audio Trigger, Beacon Trigger, and Geofence Trigger. If Precise location is TRUE, then for the trigger to operate, the location of the device as provided by the device when the request for content delivery is made as described below with reference to
Backend server saves 415 the SQR trigger and its configuration. The SQR trigger and its configuration are stored so that they can be easily retrieved when a request is received from a user device after scanning an SQR code which causes the trigger to be sent to the backend server for handling when the trigger is received.
The admin user then configures 417 the campaign by setting the start date and end date and assigns an SQR trigger. As noted above an SQR trigger can be configured to request precise location data from the device. By default, an approximate location is used by retrieving the metadata based on the IP address associated with the API client.
The backend server saves 419 the campaign configuration. The stored SQR trigger and its configuration and the saved campaign configuration are linked together on the server. They are separated and associated with a link so that, for example, a stored SQR trigger and its configuration can be reused with a different start and end date.
The admin user then launches 421 the campaign by moving all of the related stored data so that it is active and responds to requests from end user devices. That is, the backend server serves content upon request for content delivery from API client(s) based on the previously set start and end dates.
Using the camera of end user device 301 such as a mobile device (i.e. smart phone), an end user 501 scans 503 the SQR code from a media source. The media source can be a digital medium such as a digital screen, smart TV, digital billboard, and the like as well as physical medium such as a poster, sticker, stamp, etc. All that is required is for there to be enough space to display the SQR code.
The ability of a mobile device to use its camera as a QR code scanner is built into most modern mobile devices with no particular action required by the user other than to point the device's camera to the SQR code.
The end user device decodes 505 the URL value encoded within the SQR code. Once the code is recognized, a pop-up appears on the screen which the user can then select and an action is taken based on the data provided by the SQR code which is automatically decoded by a part of the mobile device's operating system designed for this task.
The end-user device launches 507 the API client. The API client can be a Web App (browser) or a native app. Typically, the decoded URL directs a browser app on the mobile device to access the web page pointed to by the URL. It could also be a native app running on the mobile device in which case the app is launched and the information provided by the API client is sent to this app. The information, whether provided whether to the accessed web page or launched app, is as follows: [protocol]://[address].
The API client generates 511 a unique identifier (UUID) for the device and sends a request to the backend to register it. The UUID is generated by the API client via background process running in the background on the native app (including web browser) which retrieves the device parameters made available by the operating system (including OS name, OS version, device model, locale, as well machine learning to generate a value (hash code) that can uniquely identify a device with a 99.5% accuracy. The generated UUID for all practical purposes is unique in that it is randomly generated from a large enough set of possibilities as to make it effectively unique even though a duplicate is theoretically possible. Since the API client generates the UUID, its use and uniqueness only applies to processes accessed by the API client. At this time, the location of the device is also sent using the latitude/longitude values provided by the GPS of the device where the API client is installed. The location is also stored as part of the device record. That is, at the time of scanning the SQR code, the backend server is also provided with the location of the device which can be used to determine the content to be delivered. This is another way in which the same SQR code can provide different results based on location. The backend server also takes into account the date and time when the request is made and uses them as factors when determining what content to deliver as a response. The date and time is determined by the server at the time of the request by creating a timestamp in UTC (Universal Time Coordinated) format which is also stored as part of the device record.
The backend server stores 513 the device record using the UUID provided. The UUID is used by the backend server as described below with reference to
Although the API client already has the trigger ID from the QR code, it is not used until the end user device is registered with the backend server. In this manner, it can be ensured that each request from each end user device is separately tracked and handled
The API client retrieves 515 the trigger ID from the URL (decoded value). As noted above, the trigger ID is typically a URL encoded in the QR code. The trigger ID is retrieved from the URL obtained from the scanned QR code as follows. The native app or web browser looks for the key/value pair “trigger_id=[value]” within the decoded string, and stores the value in its local cache so that it can be used when requesting content from the backend server.
The API client requests 517 the delivery of offers providing the trigger ID and device UUID as part of the request. At this point, the trigger ID/URL is sent to the backend server.
The backend server retrieves the trigger configuration, including the content sequence, and based on targeting and sequence parameters and determines 519 which content item to send back to the API client. This is the information set up by the admin user as described above with reference to
The API client renders 521 the offer view as a user interface which lets the user interact with the offer. All interactions are stored (tracked) 523 in the back end as “impressions.”
By way of example, when an offer is delivered to the API client, a “delivered” impression is recorded; when the API client successfully displays the offer to the end-user, a “view” impression is recorded: when the user taps on the “save offer” button, a “save” impression is recorded; when the end-user taps on the “Redeem Online” button, a “redeem-online” impression is recorded; when the end-user taps on the “Redeem In-Store” button, a “redeem-in-store” impression is recorded; when the end-user taps on “No, thanks” (not interested in such offer), a “decline” impression is recorded; when the end-user taps on the “Delete” button, a “delete” impression is recorded; when the offer is successfully redeemed (it has been applied during the purchase of an item), a “complete” impression is recorded.
If the end user decides to “Save to Wallet” 525, the API client sends a request to the backend server 303 to generate 526 a native wallet pass object. A native wallet pass object is an encrypted string (text value) that contains all the offer details in a format that can be securely transmitted to the native wallet applications. The API client provides the wallet object to the end-user device 310 and the device handles the insertion 529 of the offer into the native wallet. Depending on the native wallet capabilities, reminders 531 can be sent to the user to redeem the offer. Using the expiration date of the offer, the native wallets automatically remind users to redeem the offer as the expiration date approaches. Alternatively, using the points of interest associated with the brand that have been set to the offer, the backend inserts location information (lat/lon coordinates) as part of the native pass. The native wallets use this location information as the basis to trigger reminders when the user is in proximity to a point of interest.
If the end user decides to “Buy Online” 527, the end-user device launches 533 an e-commerce site for the user to complete the purchase. At this point, processing proceeds as in the prior art which enables a user to access an e-commerce site and make a purchase.
If the user decides to “Buy In-Store” 535, the API client displays a redemption code for 537 the user to show to the retail store and redeem 539 where the item is being purchased.
As noted above, the end-user can scan the SQR code again and repeat the process. Since the backend server is able to track new requests from a device based on its UUID, the content which is determined to be delivered by the backend server can be different than the prior content obtained by any prior scan. In this manner, although a static QR code is scanned, the UUID enables the backend server to provide the same advantages as would be obtained by using a dynamic QR code.
API client 305 generates 601 a device UUID and retrieves 603 the trigger ID from the URL decoded from the SQR code as described with reference to
The backend server 303 retrieves 609 the device UUID from the header of the request. A typical request with its header looks like this:
The specifics of the Request Header and Request URL are not important for an understanding of the invention—that is, the manner in which this type of information is generated and used is well known to persons having ordinary skill in the art.
The backend server then retrieves 613 the trigger ID from the body of the request and uses the trigger ID to retrieve 615 the trigger configuration from the database. The retrieved trigger configuration is used to retrieve 617 the content delivery rules. The server software then loops 621 through the configured content and creates a curated list that contains only the content that matches defined target parameters. These include: location (city, state, country), locale (e.g., Southern California, etc.), language (e.g., “English”, “Spanish”, etc.), date/time, operating system, manufacturer (i.e. Apple®, Samsung®, Google®, etc.). The server software then picks 623 the first content item from the curated list.
Using the device UUID, the server software determines 625 if the content item has already been delivered to that device: If it has already been delivered, the next content item 627 in the curated list is selected. This process repeats until a content item is found that has not been delivered. If none exists, no content is returned (HTTP 204—empty response)
If the content has not yet been delivered, it is then delivered 631 to the API client as a HTTP 200 (success) response. The API client then renders 633 the offer view for the user to interact with. An image 639 of the product may be displayed along with a redeem button and a save to wallet 643 button.
In this manner, by using a static QR code which only contains a URL or app to be launched, and providing an API client and backend server as described herein, different content can be provided based on a variety of parameters as described herein,
The invention is implemented as a system and method using the various hardware elements described above with appropriate programming of the sequential configuration, trigger settings, backend server, and API client to provide the described functionality. Each of these elements uses a processor, storage and programming to supplement the generic functionality of these devices to produce functionality not currently available. The specifics of the processors and storage elements utilized are well known to persons skilled in the art, and such details are not needed for a full understanding of the invention. However, providing SQR code functionality on a mobile or other device which operates in conjunction with triggering mechanisms based on desired sequential configurations provides marketing and other advantages not currently available using prior art techniques.
Although the invention has been described using various examples and detailed descriptions, the invention is not intended to be limited by the specific examples and descriptions provided, but rather is limited only by the following claims.
Number | Date | Country | |
---|---|---|---|
63263794 | Nov 2021 | US |