U.S. patent application number 17/064676 was filed with the patent office on 2021-05-20 for caching geolocated offers.
The applicant listed for this patent is RetailMeNot, Inc.. Invention is credited to Alexander M. Cheng, J. Seth Randle, Jeffrey R. Rego.
Application Number | 20210150578 17/064676 |
Document ID | / |
Family ID | 1000005368986 |
Filed Date | 2021-05-20 |
![](/patent/app/20210150578/US20210150578A1-20210520-D00000.png)
![](/patent/app/20210150578/US20210150578A1-20210520-D00001.png)
![](/patent/app/20210150578/US20210150578A1-20210520-D00002.png)
![](/patent/app/20210150578/US20210150578A1-20210520-D00003.png)
![](/patent/app/20210150578/US20210150578A1-20210520-D00004.png)
![](/patent/app/20210150578/US20210150578A1-20210520-D00005.png)
![](/patent/app/20210150578/US20210150578A1-20210520-D00006.png)
![](/patent/app/20210150578/US20210150578A1-20210520-D00007.png)
![](/patent/app/20210150578/US20210150578A1-20210520-D00008.png)
United States Patent
Application |
20210150578 |
Kind Code |
A1 |
Cheng; Alexander M. ; et
al. |
May 20, 2021 |
CACHING GEOLOCATED OFFERS
Abstract
Provided is a process, including: receiving, with one or more
processors, from a remote user computing device, a geographic
location of the user computing device; determining that the user
computing device is in a cache geographic area in which information
about potentially relevant geographically-targeted offers is to be
predictively loaded into memory of the user computing device before
the user requests the information about geographically-targeted
offers; selecting, with one or more processors, an offer from a
repository of offers based on the selected offer being associated
with the cache geographic area or a location in the cache
geographic area; and in response to the determination, sending,
with one or more processors, the selected offer to the user
computing device for storage in cache memory of the user computing
device before the user requests the selected offer.
Inventors: |
Cheng; Alexander M.;
(Austin, TX) ; Rego; Jeffrey R.; (Austin, TX)
; Randle; J. Seth; (Austin, TX) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
RetailMeNot, Inc. |
Austin |
TX |
US |
|
|
Family ID: |
1000005368986 |
Appl. No.: |
17/064676 |
Filed: |
October 7, 2020 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
16256893 |
Jan 24, 2019 |
|
|
|
17064676 |
|
|
|
|
14661392 |
Mar 18, 2015 |
10229434 |
|
|
16256893 |
|
|
|
|
61969119 |
Mar 22, 2014 |
|
|
|
62103652 |
Jan 15, 2015 |
|
|
|
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06Q 30/0261 20130101;
G06Q 30/0267 20130101; H04W 4/021 20130101 |
International
Class: |
G06Q 30/02 20060101
G06Q030/02 |
Claims
1-25. (canceled)
26. A method, comprising: receiving, with one or more processors,
from a remote user computing device, a geographic location of the
user computing device; determining that the user computing device
is within a threshold distance or transit time to an offer-related
location; selecting, with one or more processors, an offer from a
repository of offers based on the selected offer being associated
with the offer-related location; and in response to the
determination, sending, with one or more processors, the selected
offer to the user computing device for storage in cache memory of
the user computing device before the user requests the selected
offer.
27. The method of claim 26, wherein sending the selected offer
comprises: sending content describing the selected offer, wherein
the content describing the selected offer is smaller than content
that is sent when another user requests the same offer outside of
the context of a request to cache content.
28. The method of claim 26, wherein sending the offer comprises:
obtaining a bar code number and a bar code type of the offer; and
sending the bar code number and the bar code type to the user
computing device without sending an image of the bar code, wherein
the bar code number and bar code type are sent in a format that,
when input into a bar code image generation routine executing on
the user computing device, cause the bar code image generation
routine to generate an image of the bar code for presentation on
the user computing device.
29. The method of claim 26, wherein selecting the offer comprises:
selecting a plurality of offers, including the offer, based on a
record of offers previously redeemed by other users in the
offer-related location or based on a record of offers previously
redeemed by the user.
30. The method of claim 26, comprising: before receiving the
geographic location, profiling a plurality of geographic areas as
having inadequate wireless connectivity based on reports from a
plurality of other user devices indicating failed attempts to
access content related to offers while in respective ones of the
plurality of geographic areas, and creating at least part of the
offer-related location in response to the profiling.
31. The method of claim 26, wherein sending the selected offer
comprises: obtaining a plurality of application program interface
(API) request responses, at least one of the responses including
the offer, at least some of the responses including a plurality of
offers responsive to the respective API request; associating a
description of each API request with the respective response; and
sending the composed responses, the description of each API
request, and the association between the description of each API
request and the respective response to the user computing
device.
32. The method of claim 26, wherein: the selected offer is a
single-use offer having a unique single-use offer code
corresponding to an instance of the single-use offer and different
from other instances of the single-use offer; the method comprises:
after selecting the offer, designating, in memory, the instance of
the single-use offer as reserved, but not redeemed; and receiving a
request for the single-use offer from a different user computing
device; and sending one of the other instances of the single-use
offer to the different user computing device in response to the
instance of the single-use offer being designated as reserved.
33. The method of claim 26, wherein: the selected offer is a
single-use offer having a single-use offer code corresponding to an
instance of the single-use offer and different from other instances
of the single-use offer; the method comprises: after selecting the
offer, designating, in memory, the instance of the single-use offer
as reserved; and after sending the selected offer, receiving an
indication from the user computing device that the single-use offer
was not redeemed; receiving an indication from the user computing
device that the single-use offer was removed or expired from cache
memory; and in response to at least one of the indications,
designating the single-use offer as not being reserved.
34. The method of claim 26, comprising: after sending the selected
offer, and after losing and then regaining a network connection
with the remote user computing device, receiving a report
indicating whether the offer was presented to the user while the
network connection was lost.
35. The method of claim 26, comprising: receiving request from the
mobile device for offers when the mobile device has wireless
connectivity; and sending one or more offers to the mobile device
in response to the request.
36. A system, comprising: one or more processors; and memory
storing instructions that when executed by at least some of the
processors effectuate operations comprising: receiving, with one or
more processors, from a remote user computing device, a geographic
location of the user computing device; determining that the user
computing device is within a threshold distance or transit time to
an offer-related location; selecting, with one or more processors,
an offer from a repository of offers based on the selected offer
being associated with the offer-related location; and in response
to the determination, sending, with one or more processors, the
selected offer to the user computing device for storage in cache
memory of the user computing device before the user requests the
selected offer.
37. The system of claim 36, wherein: receiving a geographic
location comprises receiving data by which a cellular carrier of
the user computing device is identified.
38. The system of claim 36, wherein: receiving a geographic
location comprises receiving data by which a mobile device model of
the user computing device is identified.
39. The system of claim 36, wherein sending the selected offer
comprises: sending content describing the selected offer, wherein
the content describing the selected offer is smaller than content
that is sent when another user requests the same offer outside of
the context of a request to cache content.
40. The system of claim 36, wherein sending the offer comprises:
obtaining a bar code number and a bar code type of the offer; and
sending the bar code number and the bar code type to the user
computing device without sending an image of the bar code, wherein
the bar code number and bar code type are sent in a format that,
when input into a bar code image generation routine executing on
the user computing device, cause the bar code image generation
routine to generate an image of the bar code for presentation on
the user computing device.
41. The system of claim 36, wherein selecting the offer comprises:
selecting a plurality of offers, including the offer, based on a
record of offers previously redeemed by other users in the
offer-related location or based on a record of offers previously
redeemed by the user.
42. The system of claim 36, the operations comprising: before
receiving the geographic location, profiling a plurality of
geographic areas as having inadequate wireless connectivity based
on reports from a plurality of other user devices indicating failed
attempts to access content related to offers while in respective
ones of the plurality of geographic areas, and creating at least
part of the offer-related location in response to the
profiling.
43. The system of claim 36, sending the selected offer comprises:
obtaining a plurality of application program interface (API)
request responses, at least one of the responses including the
offer, at least some of the responses including a plurality of
offers responsive to the respective API request; associating a
description of each API request with the respective response; and
sending the composed responses, the description of each API
request, and the association between the description of each API
request and the respective response to the user computing
device.
44. The system of claim 36, wherein: the selected offer is a
single-use offer having a unique single-use offer code
corresponding to an instance of the single-use offer and different
from other instances of the single-use offer; the operations
comprise: after selecting the offer, designating, in memory, the
instance of the single-use offer as reserved, but not redeemed; and
receiving a request for the single-use offer from a different user
computing device; and sending one of the other instances of the
single-use offer to the different user computing device in response
to the instance of the single-use offer being designated as
reserved. after the user is presented with at least some of the
cached offers without successfully using wireless connectivity, and
after the given computing device regains wireless connectivity,
receiving, with one or more processors, a logged record from the
given computing device indicating which offers were presented to
the user including offers presented during the loss of wireless
connectivity; and storing, with one or more processors, metrics of
at least some of the presented offers based on the received logged
record.
Description
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] The present application is a continuation of U.S. patent
application Ser. No. 16/256,893, titled "CACHING GEOLOCATED
OFFERS," filed 24 Jan. 2019, which is a continuation of Ser. No.
14/661,392, titled "CACHING GEOLOCATED OFFERS," filed 18 Mar. 2015,
which claims the benefit of U.S. Provisional Patent Application
61/969,119, titled "MULTI-STAGE GEOLOCATED OFFERS," filed 22 Mar.
2014, and claims the benefit of U.S. Provisional Application
62/103,652, titled "CACHING GEOLOCATED OFFERS," filed 15 Jan. 2015.
The entire content of each aforementioned patent filing is hereby
incorporated by reference.
BACKGROUND
1. Field
[0002] The present invention relates generally to electronically
distributed coupons and other offers and, more specifically, to
caching geolocated offers related to geographic areas in which
users are known to have low quality or no wireless connectivity
prior to users entering those areas.
2. Description of the Related Art
[0003] Offer distribution systems are used by merchants (e.g.
retailers, service providers, and the like) to convey offers (e.g.
coupons, rewards, or sales) to consumers over networks, like the
Internet. In some cases, offers may be redeemable in-store, for
example, by a consumer printing the offer at home and presenting
the printout to a store clerk or by the consumer presenting the
offer with a mobile device, like a cell phone, to the merchant. In
some cases, offers may be redeemable online, for example, on a
merchant's website by a consumer entering an offer-specific code at
checkout. Generally, one or more entities operating an offer
distribution system obtain data describing the offers from
merchants, and the offer distribution system is used to distribute
the offers to (in some cases, select) consumers and help consumers
find relevant offers. In many cases, merchants compensate entities
operating offer distribution systems for such services, for
example, based on offer impressions or redemptions by consumers. In
one type of offer distribution system, an affiliate network
distributes offers to publishers, and the publishers then
distribute offers to consumers. In this type of system, the
affiliate network typically tracks redemptions of the offers, such
that the publishers can be compensated by merchants. In another
type of offer distribution system, a single entity obtains the
offers from a merchant and distributes those offers to consumers,
e.g., using websites or native mobile applications provided by that
entity to consumers to access the offer distribution system.
SUMMARY
[0004] The following is a non-exhaustive listing of some aspects of
the present techniques. These and other aspects are described in
the following disclosure.
[0005] Some aspects include a process, including: receiving, with
one or more processors, from a remote user computing device, a
geographic location of the user computing device; determining that
the user computing device is in a cache geographic area in which
information about potentially relevant geographically-targeted
offers is to be predictively loaded into memory of the user
computing device before the user requests the information about
geographically-targeted offers; selecting, with one or more
processors, an offer from a repository of offers based on the
selected offer being associated with the cache geographic area or a
location in the cache geographic area; and in response to the
determination, sending, with one or more processors, the selected
offer to the user computing device for storage in cache memory of
the user computing device before the user requests the selected
offer.
[0006] Some aspects include a tangible, non-transitory,
machine-readable medium storing instructions that when executed by
a data processing apparatus cause the data processing apparatus to
perform operations including the above-mentioned process.
[0007] Some aspects include a system, including: one or more
processors; and memory storing instructions that when executed by
the processors cause the processors to effectuate operations of the
above-mentioned process.
BRIEF DESCRIPTION OF THE DRAWINGS
[0008] The above-mentioned aspects and other aspects of the present
techniques will be better understood when the present application
is read in view of the following figures in which like numbers
indicate similar or identical elements:
[0009] FIG. 1 shows an embodiment of an offer distribution system
and consumer mobile devices configured to distribute and
predictively cache geolocated offers;
[0010] FIG. 2 shows an embodiment of a process for distributing and
tracking multi-stage geolocated offers that may be performed by
some embodiments of the offer distribution system of FIG. 1;
[0011] FIG. 3 shows an embodiment of a process for presenting and
redeeming multi-stage geolocated offers based on a sequence of
geographic locations sensed by a consumer mobile device, such as
the consumer mobile devices of FIG. 1;
[0012] FIG. 4 shows an example of a process performed by some
embodiments of a client application to log instances in which
requests for offer content fail;
[0013] FIG. 5 shows an example of a process performed by some
embodiments of an offer distribution system to gather reports of
failed requests for offer content and designate geographic areas
for predictive caching of offers;
[0014] FIG. 6 shows an example of a distributed computing process
performed by some embodiments of client devices and offer
distribution systems to cache geographically targeted offers;
[0015] FIG. 7 shows an example of a process performed by some
embodiments of an offer distribution system to cache single-use
offers on client devices; and
[0016] FIG. 8 shows an example of a computer system that may be
used to implement some or all of the components described
herein.
[0017] While the invention is susceptible to various modifications
and alternative forms, specific embodiments thereof are shown by
way of example in the drawings and will herein be described in
detail. The drawings may not be to scale. It should be understood,
however, that the drawings and detailed description thereto are not
intended to limit the invention to the particular form disclosed,
but to the contrary, the intention is to cover all modifications,
equivalents, and alternatives falling within the spirit and scope
of the present invention as defined by the appended claims.
DETAILED DESCRIPTION OF CERTAIN EMBODIMENTS
[0018] FIG. 1 is a block diagram showing an example of a
distributed computing environment 10 having components that
mitigate various problems with traditional offer distribution
systems. For example, some embodiments mitigate problems that arise
in the context of geo-targeted offer distribution due to poor
wireless connectivity. For instance, when a user, such as a
consumer, is within a merchant's brick-and-mortar store, and at a
geolocation at which a particular offer is relevant, many systems
fail to alert that user to the offer (e.g., either automatically
based on location, or in response to user searches for local
offers) because diminished or absent wireless connectivity prevents
delivery of the offer from a remote server. Often store walls or
shelves contain relatively large amounts of conductive material,
forming, in effect, a Faraday cage, in which it is difficult for a
user's hand-held wireless device to exchange signals with an
external cellular tower (or other wireless access point, e.g.,
in-store WiFi.TM.) to convey data to an offer-related mobile client
application (e.g., a native application executing on the user's
wireless device, or an web page rendered in a browser executing on
the wireless device). Poor wireless connectivity can also be a
problem in outdoor areas, e.g., for offers targeted to rural areas,
or offers targeted to events in which high-density, large crowds
overwhelm local cell tower capacity, such as during a sporting
event or concert.
[0019] In many cases, due to poor connectivity, users are not
alerted to relevant offers, stores fail to capture marginal revenue
that such offers would have driven, and publishers of offers fail
to receive compensation for driving desired user behavior. These
and other problems are expected to be mitigated by some of the
following embodiments. It should be understood, however, that
various independently inventive concepts are disclosed and not all
embodiments necessarily address all described problems. Various
engineering and cost tradeoffs may favor use of only a subset of
the described techniques in certain scenarios.
[0020] This problem with connectivity may be mitigated with some of
the techniques described below. Some embodiments of the computing
environment 10 1) automatically detect offer-related areas (e.g.,
stores, malls, and their surrounding area) in which wireless
connectivity is unreliable or absent based on periodic (e.g.,
nightly, or weekly) analysis of logged user interactions with an
offers application in those areas indicating failed attempts by the
application to retrieve offers; 2) later, in response to
identifying such an area, and in response to detecting that a user
is approaching such an area (e.g., within a threshold distance of),
cache offers related to those areas before users enter the areas
with cache memory of an offers application executing as a
background process on users' mobile devices; 3) later present the
cached offers (e.g., a location-relevant subset of the cached
offers) from the cache memory to the user while the user is in the
area (e.g., a portion of the area in which the offer is
particularly relevant, e.g., as indicated by a beacon signal
emitted in the relevant area), without that presented offer being
retrieved at the time of presentation from a remote server via a
wireless (e.g., cellular, or local area wireless network)
connection. Not all embodiments, however, necessarily perform all
of this steps, e.g., profiling may be offloaded to a third party,
which is not to imply that any other feature may not be
omitted.
[0021] These and other problems with traditional offer distribution
systems are mitigated by aspects of embodiments described below.
But it should be appreciated that some embodiments address only a
subset of these problems or other problems apparent to those of
skill in the art upon reading the present disclosure. Indeed, as
explained in the concluding paragraphs of this specification, the
present disclosure includes a number of independently useful
inventions that are described in a single document because those
inventions are also useful together. Accordingly, any description
of a problem or a benefit associated with the present techniques
should not be read as defining "the invention" of the present
application, as the present application relates to several
inventions, some of which are defined in the originally filed
claims, and others that may be addressed in later claim amendments
or continuation applications.
[0022] In some embodiments, the computing environment 10 includes
an offer distribution system 12 and consumer mobile devices 14
(e.g., cell phones, hand-held tablet computers, wearable computing
devices, and the like having portable power supplies, like
batteries) configured to alert users to an offer in response to the
users being geographically proximate a merchant's physical
location, like a relevant subset of a merchant's physical location
(e.g., a store entrance, department, aisle, or subset thereof to
which an offer relates). Proximity may depend upon the use case. In
some embodiments, offers may be determined to be relevant to the
user's current location in response to the user being within 50
meters of a store entrance, within 10 meters of a store department
or aisle, or within around one meter of a particular product
display, for example. In many cases, the area of relevance is
substantially or entirely within a store or larger structure (like
a mall) that impairs wireless connectivity.
[0023] In some applications, the user may be notified of an offer
upon that consumer's mobile device 14 detecting that the user is
within a first geographic location (e.g., a notification geographic
location). A notification geographic location (e.g., an area or
point) may be characterized by some designation of a geographic
location to which an application on a consumer's mobile device is
responsive, like a geofence 16 defined by a polygon having vertices
expressed as longitude and latitude coordinate pairs; a store in
which the user has checked-in; or in a broadcast area in which a
store, department, or aisle identifier is embedded in some radiated
signal like in-store lighting, a WiFi.TM. service set identifier
(SSID), or in-store audio; an aisle or department in which a
Low-Energy Bluetooth beacon is received; or position where a
location identifier is scannable by the consumer's mobile device,
such as in viewable range of a QR code, or within range of a
near-field communication tag. In some cases, the geographic
location is defined by a wireless beacon 20 (such as a Low Energy
Bluetooth.TM. beacon defined by a version of the Bluetooth standard
including or post dating the Bluetooth Core Specification Version
4.0). The geographic location may be sized such that users in the
geographic location are within the store of a merchant issuing the
offer, are near the store of a merchant issuing the offer (for
instance, within a short walk, like 50 or 100 meters for the
notification geographic location), or are in a particular
department of a merchants store, depending on the marketing
objectives of the merchant.
[0024] In some embodiments, the computing environment 10 includes
the offer distribution system 12, consumer mobile devices 14, a
consumer wearable device 22, the Internet 24, a point-of-sale
terminal 26, a merchant transaction data repository 28, and a
merchant computing device 30. The offer distribution system 12, in
some embodiments, may manage (e.g., store, distribute, and track)
offers created by a merchant, e.g., with merchant device 30. These
components are described in greater detail below after a brief
overview of a use case.
[0025] In some applications, the offers may be distributed to
consumer mobile devices in response to those consumer mobile
devices determining that the respective devices are within the
geographic location 16 or the surrounding area. In some cases, the
offers may be redeemed based on the consumer mobile devices 14
determining that the respective devices are within the other
geographic location 18, which may be specified in the offer as the
place where the offer is redeemed. The consumer mobile devices 14
may report travel to location 18 to the offer distribution system
12 for centralized tracking. In some cases, users enticed to visit
a store at location 18 may purchase goods or services with the
point-of-sale terminal 26, and the entity operating the offer
distribution system 12 may be compensated based on records of those
purchases stored in the merchant transaction data repository 28.
The various components of the computing environment 10 may be
geographically distributed and may communicate with one another
remotely via the Internet 24 and various other networks, such as
cellular networks, wireless area networks, local area networks, and
the like.
[0026] In some embodiments, the offer distribution system 12
includes an offer data repository 32, a merchant data repository
34, user data repository 36, a wireless-connectivity profiler 37,
an offer server 38, a pre-cacher module 39, and an offer management
module 40. The offer data repository 32 may store offer records
describing offers, the merchant data repository 34 may store
merchant records describing merchants, the user data repository 36
may store user profiles, the offer server may send data about
offers over the Internet 24 and receive data about offers, and the
offer management module 40 may coordinate the operation of these
other components to provide the functionality described herein. The
profiler 37 may perform a process described below with reference to
FIG. 5 to identify geographic areas in which offers are to be
cached due to poor wireless connectivity. The pre-cacher 39 may
participate in the processes described below with reference to
FIGS. 6 and 7 to cache locally-relevant offers on mobile devices
entering areas designated by the profiler 37.
[0027] In some cases, the offer distribution system 12 manages
offers for hundreds of merchants issuing tens of thousands or
hundreds of thousands of offers to relatively large geographic
areas, such as the United States or a substantial portion of the
world, and those offers are distributed to millions, tens of
millions or hundreds of millions of consumer mobile devices.
Accordingly, some embodiments of the offer distribution system 12
may include computing components that are replicated and use
load-balancing servers to reduce latency and operate at such
scales. It is expected that users generally desire to interact with
offers selected from a relatively large pool of offers to see
offers that are relatively likely to be relevant to those users,
and merchants generally desire to distribute their offers to a
relatively large number of users. At the same time, it is expected
that such users are often relatively sensitive to latency when
interacting with such offers, e.g., changes on the order of 300
milliseconds are expected to materially affect usage statistics.
Accordingly, to facilitate both scale and speed, some embodiments
may be constructed in a data center, and content may be hosted by
content delivery networks to expedite delivery of bandwidth
intensive content, such as images or video. Further, records in the
various data repositories may be replicated in various indexed data
structures, such as hash tables, sorted list, prefix trees, and the
like that are pre-processed to facilitate relatively fast retrieval
of records based on multiple, frequently-used query values.
[0028] In some embodiments, the offer-data repository 32 includes a
plurality of offer records, each offer record describing an offer,
such as a coupon, sale, conditions for entry to a game of chance,
conditions to receive some other benefit, or the like. Each offer
record may include a unique offer identifier, a summary of the
offer, a more detailed description of the terms of the offer, a
identifier of a merchant issuing the offer, an expiration time for
the offer, content for presenting the offer (e.g., images, like
video, illustrating the good or service subject to the offer), and
a category or subcategories of the offer (e.g. restaurants,
sporting goods, retail clothing, and various other hierarchical
categories in an offer ontology).
[0029] Some of the offer records may describe geolocated offers,
which specify one or more geographic locations (e.g., areas or
points) in which a consumer mobile device travels in order for a
respective consumer to be presented with (or otherwise alerted to)
the offer or (i.e., and/or) to redeem the offer.
[0030] Offer records for multi-stage geolocated offers may include
a notification geographic location defining a geographic location
where a consumer is to be alerted to the offer. Geographic
locations may be described with a value indicating the type of
geographic location description. An example description is a
geofence, with which the geographic location is described with
reference to an absolute geographic reference, like geographic
coordinates, for instance, latitude and longitude coordinates
defining vertices of a polygon specifying the geographic location,
or latitude and longitude coordinates for a vector graphics
representation of the geographic location (e.g., a center point
coordinate and a radius). Another example description is a wireless
transmission range in which the geographic area is defined by the
range over which a wireless signal is discernible (or is received
with greater than a threshold signal strength or less than a
threshold amount of attenuation as indicated by calculating
difference between a signal strength with which the signal is
received and a broadcast signal strength value encoded in the
signal), such as the range over which a consumer mobile device can
discern an identifier encoded in a Low Energy Bluetooth Beacon, a
Bluetooth Beacon, a Wi-Fi Beacon, or the like. In some cases, the
signal is deemed discernible if a value encoded in the wireless
signal is received by a consumer mobile device, such as a value
uniquely identifying the transmitter (or the merchant, or the
merchant's site) that corresponds to the geographic location, like
a beacon identifier or an SSID value selected with reference to a
namespace that distinguishes other transmitters and other
locations. Another example of wireless transmission includes such
values being encoded in audio signals in a merchant's on-site music
(which may be detected by a consumer mobile device's microphone) or
such values being encoded in a merchant's overhead lighting (which
may be detected by a light sensor on a consumer mobile device).
Other examples include scannable signals, for instance an
identifier received upon the user placing their mobile device near
a near-field communication tag, or directing a camera of the mobile
device toward a QR code or bar code. These wirelessly encoded
identifiers may be stored in the offer record in association with
the geographic location, such that consumer mobile devices may be
sent the identifier and detect transmission of the identifier to
determine that the consumer mobile device is at a geographic
location.
[0031] Geolocation may be determined based on one or more wireless
signals, e.g., receipt of an identifier in, or signal strength of,
a beacon from a Low Energy Bluetooth transmitter, an identifier of
one or more cellular base stations in range, a SSID in a WiFi
beacon, a value encoded in overhead lighting, a value encoded in
ambient audio, satellite navigation signals (e.g., Global
Positioning system, Glonass, or Galileo signals), or the magnetic
landscape produced by interaction between a building and the
Earth's magnetic field (e.g., according to geolocation services
from IndoorAtlas of Mountain View Calif.). In some cases
determining a geolocation can include determining a geolocation
entirely on the client device or in cooperation with a remote
system that identifies the geolocation based on signature of the
wireless environment sent by the client device (e.g., based on
cooperation with the geolocation service of SkyHook of Boston
Mass.). In some cases, geolocation may be determined with a variety
of different techniques with tradeoffs between speed, accuracy, and
power consumption, e.g., based on a cellular tower identifier for
relatively low power consumption, high speed, and low accuracy
(like on the order of one kilometer), or based on GPS signals for
relatively high power consumption, low speed, and high accuracy
(like on the order of 10 meters). In some cases, a geolocation may
be determined with a relatively fast technique and then later
updated based on slower, more accurate techniques.
[0032] In some cases, the description, type, and size of geographic
locations are selected based on the desired type of user
interaction. In some embodiments, geofences are used for outdoor or
geographic areas larger than approximately 10,000 m.sup.2 due to
the relatively low resolution and reliability of signals by which
geographic coordinates of a mobile devices current geographic
location are determined by mobile devices. In some cases, wireless
transmission ranges are used for an indoor or geographic areas
smaller than approximately 10,000 m.sup.2 due to their higher
reliability offsetting the higher cost of providing such signals in
these cases. In some examples, a wireless transmission range may be
configured such that the corresponding geographic location is
larger than approximately 100 m.sup.2 to make it relatively easy
for users to find the respective geographic location, for instance,
by walking into the interior of an identified store or passing
through a door of an identified store. In another example, the
wireless transmission range may be on the order of approximately 1
meter or less, for example, based on near field communication (NFC)
transmissions, and users may be targeted in a relatively specific
location, for instance, when standing in front of a particular
shelf in a store. Because of the distinct use cases, some
embodiments may use a different description type for NFC and
similar transmission ranges, referring to these geolocation
descriptions as point geolocations. In some cases, point geographic
locations are distinct from the point-of-sale terminal 26, such
that the user is targeted near merchandise or services that the
merchant wishes to sell, rather than to a checkout counter where
the user would not necessarily be exposed to such merchandise or
services.
[0033] In some cases, some or all of the offers (including
multi-stage geolocated offers) are single-use offers for which each
instance of the offer is separately tracked by the offer
distribution system 12 and is redeemable a limited number of times
(e.g., once), in contrast with multi-use offers in which the same
information (e.g., an offer code) may be used by a relatively large
number of users, and the number of users in possession of the offer
is not necessarily known (e.g., due to email sharing, photocopying,
and the like). For single-use offers, each offer record may include
an amount (e.g., a number) of instances of the offer to be
redeemed, to be reserved (as some merchants wish to avoid
disappointing users who believe they have a valid offer only to
arrive at a store and find that all permitted redemptions have
occurred), or both. Further, for single-use offers, each offer
record may include a plurality of offer instance records, each
instance record including an offer instance identifier, a value
indicating whether the offer instance has been reserved, a value
indicating whether the offer instance has been redeemed, an
identifier of a user who has redeemed the offer instance if
available, and an identifier of a user who has reserved the offer
instance if available. For some multi-stage single-use geolocated
offers, offer instances may be reserved by simply being in the
notification geographic area. In other cases, the user may be asked
to take further affirmative steps, such as interacting with an
interface on the consumer mobile device 14 to cause the mobile
device to indicate to the offer distribution system 12 that the
user wishes to reserve an offer instance. Thus, the value
indicating whether the offer instance has been reserved may be used
to determine whether a user who later enters the reward geographic
area qualifies for the reward, or some embodiments may perform this
determination based on client-side offer state data stored in
consumer mobile devices, such as a value indicating that the
consumer mobile device was previously in the notification
geographic location. In some cases, digital offer instances may be
maintained as a rivalrous good without a centralized arbiter of the
offer instances, for instance with a blockchain public database, or
distributed public ledger, in which transactions of offers (like
allocation to users or publishers by merchants, transfers between
or to users, and redemption of coupons or other offers) are
validated by broadcasting the transactions to computing nodes that
perform proof of work algorithm (or demonstrate proof of storage of
some value), like processing a cryptographic hash function, such as
SHA-256, and indicate a consensus as to whether the transaction is
valid (e.g., to prevent double redemption of offer instances).
[0034] The merchant data repository, in some embodiments, may
include a plurality of merchant records, each merchant record
describing an individual merchant. Each merchant record may include
a name of the merchant, a unique identifier of the merchant,
content used to present offers from the merchant (e.g., images,
like the merchant's logo), roles and permissions defining (a term
which is used here interchangeably with the term "specifying")
which merchant employees are permitted to control (e.g., create,
change, and track) offers, templates for creating offers (e.g.,
preconfigured geographic locations from which the offer creator
might select), and a plurality of store records, each store record
describing a geographic location one of the merchant's stores, such
that offers may be selected for presentation to users based on a
user's proximity to a store by the offer distribution system
12.
[0035] The user data repository 36, in some embodiments, may
include a plurality of user profiles. Each user profile may include
a username, a password, a unique user identifier, demographic
information about the user (e.g., a residential address, an
occupation type, interests, and the like), and interaction records
describing previous interactions by the user with the offer
distribution system 12. In some cases, the geolocated offers may be
selected for presentation to (or caching for contingent
presentation) a user by the offer distribution system 12 based both
on the user's location and the user's user profile satisfying
criteria relating to the demographic information or a pattern in
the interaction records. For example, a merchant may specify, when
defining an offer, that users scoring above a threshold on a metric
indicative of affinity for sports may be alerted to a multi-stage
geolocated offer in response to those users entering a geofence. Or
two geofenced offers may be ranked by the offer distribution system
12 based on similarities between those offers and previous offers
the user has redeemed, and the offer more similar to previously
redeemed offers may be sent to the user based on the ranking.
[0036] The offer server 38 may interface between the offer
management module 40 and the Internet 24. For example, the offer
server 38 may listen to a port through which information is
exchanged with the other components of the computing environment 10
and translate signals (e.g., data, like commands or content) into a
format to which the offer management module 40 is responsive or
from a format in which such signals are supplied by the offer
management module 40. In some cases, the offer server 38 may parse
received hypertext transport protocol (HTTP) requests (or other
application layer protocol exchanges, like SPDY) to identifying
corresponding functions of the offer management module 40 and call
the corresponding functions of the offer management module 40 with
data encoded in the HTTP requests as function parameters. In some
cases, the offer server 38 includes a web server, an application
program interface server, or both.
[0037] The offer management module 40 may perform a process
described below with reference to FIG. 2 and interact with the
other components of the offer distribution system 12 to provide the
functionality described herein. For instance, the offer management
module 40 may receive requests for offers from the consumer mobile
devices 14 (including requests for offers to cache), query the
offer data repository, and return responsive offers via the offer
server 38. In some cases, such requests indicate a current
geographic location of the respective requesting consumer mobile
device 14 as sensed based on the current wireless environment of
the consumer mobile device 14, for instance, including an
identifier conveyed with a wireless beacon or a geolocation sensed
based on satellite navigation signals received by the consumer
mobile device 14. In some cases, the offer management module 40 may
retrieve geolocated offers (e.g., offers associated with a
geographic location in which users are to be alerted to the offer
based on location sensed with a cell phone) based on the location
in such a query. As noted above, offers may be ranked for
presentation in response to such a query based on previous user
actions stored in the user data repository 36 as well as geographic
proximity. Further, some embodiments may score offers based on an
expected return to the entity operating the offer distribution
system calculated according to the user profile, a merchant
profile, and attributes of the offers, like an amount of a
discount, redemption rates for the offer, or a category of the
offer.
[0038] Some embodiments of the offer management module 40 may send
offers corresponding to both the current geographic location of the
consumer mobile device and the surrounding area, such that nearby
geolocated offers (e.g., offers not presently relevant, but
potentially relevant should the user move) may be stored in cache
memory of the consumer mobile device 14. Cached offers may be
recalled from memory by the consumer mobile device 14, for
instance, in the event that the consumer mobile device 14 moves
into a relevant geographic area and lacks adequate signal strength
to communicate with the offer distribution system 12. Caching both
currently relevant and potentially relevant geolocated offers is
expected to further offer benefits relating to battery consumption
of the consumer mobile devices 14, as fewer interactions with the
offer distribution system may be used to convey information. That
said, not all embodiments use this caching technique, as other
aspects are independently useful, which is not to suggest that any
other feature is not also optional in some embodiments.
[0039] In some cases, the offer management module 40 may update
records in the offer data repository 32 and interaction records in
the user data repository 36 to reflect interactions with offers.
For example, upon a user being sent an offer, both records may be
updated, and upon a user redeeming the offer or taking affirmative
steps to reserve the offer, both records may be updated by the
offer management module 40 based on corresponding signals
indicative of such interactions sent by the consumer mobile device
14, merchant device 30, or POS terminal 26, depending on the
activity and configuration.
[0040] In some cases, before sending instructions to present a
notification, embodiments of the offer management module 40 may
compare a threshold amount of instances of an offer to be reserved
or redeemed (e.g., as specified by a merchant) to a current amount
of instances of an offer that have been reserved or redeemed. In
response to determining that the amount exceeds the threshold,
embodiments may determine that the offer is not to be sent. And in
response to determining that the amount does not exceed the
threshold, embodiments may determine that the offer may be sent and
adjust the current amount (e.g., increment or decrement a count).
In some use cases, offers are not rivalrous, and offers may be
distributed without regard to how many were previously distributed
or redeemed. Some embodiments may distribute offers in a
non-rivalrous fashion but cap redemptions to a certain number,
e.g., the first 100 redemptions when 200 offers were
distributed.
[0041] The data indicating that the consumer mobile device 14 has
moved into a geographic location (e.g., a notification geographic
location) may come from the consumer mobile device itself (as
described below) or from another device, such as a beacon sensor at
a merchant store sensing the consumer mobile device is transmitting
such an indication to the offer distribution system 12, depending
on the embodiment. In some cases, a client offer application
described below causes the consumer mobile device to transmit a
beacon (such as a Low Energy Bluetooth beacon, or other wireless
signal, like a signal in a near field communication transmission),
and a computing device operated by the merchant detects the
wireless signal and sends an indication to the offer distribution
system 12. In some cases, the wireless signal includes an
identifier of the consumer mobile device or an identifier of the
user corresponding to a user profile, and this identifier is sent
by the merchant computing device to the offer distribution system
12 indicating that the user is at the specified geographic
location.
[0042] Data indicating a user is entitled to redeem an offer may be
conveyed by the offer management module 40 with a variety of
techniques. For example, the respective consumer mobile device 14
may be texted, emailed, or otherwise sent instructions (e.g.,
commands or other data that when processed causes a corresponding
activity to occur) to display a notification indicating a uniform
resource identifier (URI) from which the user may retrieve proof
that the user is in possession of the offer. For example, the user
may be sent a URI with which the user may retrieve a code that when
presented to a merchant validates that the user is entitled to the
reward. In one example, the offer management module 40 may send the
respective consumer mobile device 14 an image of a validation code
in a one-dimensional visual code (e.g., a bar code or a flashing
screen) or a two-dimensional visual bar code (e.g., a QR code)
format, and an optical scanner or mobile device operated by a
merchant employee may scan the code from a display screen of the
consumer mobile device with an image sensor, like a camera. In some
cases, the point-of-sale terminal 26 or a merchant employee mobile
device may send an indication that the validation code has been
scanned or otherwise entered or presented to the offer distribution
system 12, and the offer distribution system 12 may determine
whether the validation code is valid (e.g., corresponds to a
validation code in memory previously sent to a qualified user and
has not been previously validated) and respond with a signal
indicating whether the validation code is valid. Further, the offer
management module 40 may update a record of an offer instance in
which such a code is stored to indicate that the reward has been
claimed, so that the offer management module 40 may determine that
subsequent request to validate the same validation code are to be
rejected. In another example, offers may be conveyed to an
electronic wallet account associated with a user profile of the
user or a card-linked offer account associated with a profile of
the user, and the user may redeem the offer by accessing their
electronic wallet account with their mobile device or presenting
the appropriate card to a merchant. In some cases, e.g., for
particularly valuable single-use offers, a user mobile device (or
corresponding merchant-provided device, such as the point-of-sale
terminal) may sense biometric data of the user and validate that
the user is present as a condition of validating the offer. For
instance, some embodiments may authenticate the user's presence
with a finger print sensor of the mobile device, some embodiments
may capture an image of the user's face with a camera of the mobile
device, or some embodiments may instruct the user to speak a phrase
and capture an audio sample of the user's voice. The captured
biometric data may be compared to a record in memory (e.g., in
memory of the user device, of a manufacture of the user device, or
in the user profile of the offer discover system) of the user's
biometric attributes to determine whether the user is present based
on whether the acquired biometric data sufficiently matches that
stored in memory.
[0043] In some cases, the entity operating the offer distribution
system 12 may be compensated by a merchant for various activities
that may be tracked in the computing environment 10. For instance,
the entity may be compensated for users being presented with
notifications, users reserving offers, users traveling to the
reward geographic location, users claiming their reward, or user
purchases after one or more of these events (e.g., within some
threshold duration of time corresponding to a typical single visit
to a merchant's physical site, such as within the next six hours
following one of these events). Accordingly, the consumer mobile
device 14 and the merchant device 30 may send signals to the offer
distribution system 12 indicating when such events occur and
providing data by which compensation may be determined, such as
transaction data indicating what a consumer purchased and a
validation code presented by the user to claim the reward.
Traditional offer distribution systems often suffer from what is
referred to as "breakage" when sales clerks fail to credit the
entity operating the offer distribution system 12 for sales driven
by that entity. Tying transaction records to a value presented when
claiming a reward and associated with a user profile is expected to
reduce breakage. That said, not all embodiments necessarily provide
this benefit, as the other aspects described herein are
independently useful, which is not to suggest that any other
feature described herein may not be omitted in some
embodiments.
[0044] The consumer mobile devices 14 may be cell phones, tablet
computers, or other computing devices having a portable source of
power and that are typically with a user when away from their home
and work. Two consumer mobile devices 14 are illustrated by way of
example, but as noted above, embodiments are consistent with
substantially more, for example, more than ten-million consumer
mobile devices distributed over a relatively large geographic area,
such as North America and Europe. In some embodiments, consumer
mobile devices 14 may each execute a client offer application 42
configured to cooperate with the offer distribution system 12 to
manage multi-stage geolocated offers. Various resources of the
consumer mobile device 14, including a location sensor 44, wireless
interfaces 46, and user interfaces 48 may be accessed by the client
offer application 42 via the operating system of consumer mobile
devices 14 to effectuate operations described herein. The location
sensor 44 may include a global positioning system (or other
satellite navigation system, like GLONASS) sensor operative to
determine a current latitude and longitude of the consumer mobile
device 14 based on satellite navigation system signals. In some
cases, the location sensor 44 also or alternatively uses
identifiers of cell towers in range or other wirelessly transmitted
identifiers, such as SSID identifiers of wireless area networks. In
some cases, the consumer mobile device 14 may determine location by
sensing such wireless signals analyzing those signals with the
techniques described above. The wireless interfaces 46 may include
Bluetooth, NFC, cellular, and Wi-Fi wireless interfaces among
others, through which the various signals noted herein may be
exchanged. In some cases, the mobile device further includes a
magnetometer by which the wireless landscape of space may be
sensed, e.g., by fusing data from the magnetometer with
accelerometer data and wireless signals sensed by the mobile device
to profile changes in magnetic fields over space (like an in-door
space where other techniques may be less accurate in some cases)
and match those profiles with known profiles indicative of
geolocation. The user interfaces 48 may include a display screen of
the consumer mobile device 14 upon which notifications are
displayed and various interfaces for reserving offers and claiming
rewards are displayed. User interfaces 48 may further include a
haptic interface by which, for example, the consumer mobile device
14 may be caused to vibrate when a notification is received, and a
speaker that may be caused to emit sound when a notification is
received.
[0045] In some embodiments, the client offer application includes
an offer cache 50, a geo-event handler 52, and a controller 54.
These components may communicate with one another and the various
resources 44, 46, and 48 to manage geolocated offers.
[0046] In some cases, controller 54 may instruct the location
sensor 44 to generate a geolocation event when (e.g., in response
to the following) the consumer mobile device 14 moves more than a
threshold amount, for example, more than a threshold distance, or
from one area to another, such as from one cell tower to another.
Using coarser-grained locations (e.g., by setting a desired
accuracy attribute of a geolocation framework or library of a
mobile device operating system to approximately 1 kilometer or
larger) to generate such events is expected to reduce battery
consumption relative to systems that continually monitor
fine-grained location readings, though embodiments are consistent
with monitoring of fine-grained location data.
[0047] In response to such an event, the geo-event handler 52 may
signal the controller 54 to execute a routine by which geolocated
offers are requested from the offer distribution system 12. The
request may include an identifier of the current geographic
location (e.g., a latitude and longitude, or an identifier of a
geofence or beacon), and the offer distribution system 12 may
respond with a plurality of geolocated offers. In some cases,
responsive offers may include offers in a surrounding geographic
area, some of which specify geographic locations in which the
consumer mobile device 14 is not presently residing.
[0048] The surrounding offers may be stored in the offer cache 50
for reference in the event that the consumer mobile device 14 moves
into areas in which these surrounding multi-staged geo-located
offers are relevant, or in the case of an area designated for
caching of offers, the offers may relate to locations in the cache
geographic area. Caching a group of offers corresponding to such an
area (which may be a cache geofence) with a single request is
expected to reduce battery consumption of the consumer mobile
device 14 and render the client offer application 42 more resilient
to interruptions in communication with the offer distribution
system 12 (though other embodiments may use multiple requests to,
e.g., favor fresher data over battery life). For example, some
embodiments of the client offer application 42 may determine
whether the consumer mobile device location sensor 44 indicates the
consumer mobile device is in a cached notification geolocation, and
in response, present the appropriate notification that the
corresponding offer is available, in some cases, even in the
absence of contemporaneous communication with the offer
distribution system 12. Later, upon communication being
reestablished, a buffer storing corresponding updates for the offer
distribution system 12 may be accessed, and the stored data may be
transmitted to the offer distribution system 12 to synchronize the
state of the geolocated offers between the offer distribution
system 12 and the client consumer mobile device 14.
[0049] The controller 54 may periodically (or intermittently in
response to some external stimulus, like a change in the current
wireless environment) determine whether the current geographic
location sensed by the location sensor 44 or wireless signals
received by the wireless interfaces 46 corresponds to any
geolocated offers. For instance, upon determining that the current
latitude and longitude of the consumer mobile device 14 is within a
notification geofence to which a cached offer is responsive, or a
wireless identifier received by the wireless interfaces 46
corresponds to a wireless range geolocation, the controller 54 may
cause the offer to be presented and update the record of the
corresponding geolocated offer in the offer cache 50 and send
instructions to the offer distribution system 12 to do the same (or
add such an instruction to a buffer of data to be sent when a data
connection is restored). For example, the controller 54 may
periodically poll a Bluetooth.TM. interface for identifiers of
Bluetooth.TM. beacons within range and query multi-stage geolocated
offers in the offer cache 50 for geographic locations corresponding
to the identifiers. And the controller 54 may periodically poll the
location sensor 44 for a current latitude and longitude and
determine whether the current latitude and longitude is within any
geofences identified in the offer cache 50.
[0050] In some cases, embodiments may execute (e.g., on the client
or server) a ray-casting algorithm or a winding number algorithm to
determine whether a current location is within a geofence. For
instance, some embodiments may determine whether a current location
is within a polygon corresponding to a geofence by counting a
number of times a ray originating at the current location
intersects a side of a polygon defining a geofence and, then,
determining whether the current location is within the geofence
based on whether the count is odd (corresponding to being inside)
or even (corresponding to being outside). In some such
implementations, every edge of the polygon may be tested for
intersection with the ray, and vertices may be tested for
intersection with the ray and tracked in memory as already having
been deemed intersected to avoid double counting of vertices for
adjacent sides. Alternatively, or additionally, the current
location may be compared to a geofence by summing angles between
rays extending from the current location and vertices defining each
sequential side of the polygon. Some embodiments may deem the
current location to be inside the geofence in response to
determining that the sum is non-zero. Some embodiments may
calculate such angles according to an inverse trigonometric
function, or to expedite processing and avoid computationally
expensive calculations, some embodiments may leverage the closed
shape of the polygon and simply account for which quadrant each
additional edge places each sum.
[0051] In some cases, notifications may be presented by the
controller 54 requesting the operating system to present a
notification using an application program interface of the
operating system, such that notifications are presented on a lock
screen of the consumer mobile device 14 or on a header area of the
home screen of the consumer mobile device where users typically
expect to view such notifications. Notifications may be presented
by a background process, or notifications may be displayed in the
context of a mobile client application having the focus of the user
interface.
[0052] Some embodiments provide the user a multi-screen experience
in which the state of geolocated offers is consistent across
multiple devices and multiple consumer devices perform different
portions of the client-side functionality described herein. For
example, an in-dash automotive computer may correspond to one of
the consumer mobile devices 14, and a cell phone may correspond to
another one of the mobile devices 14. In this use case, the in-dash
computer may determine that the user is in a cache geographic
location and instruct a cell phone to cache corresponding offers,
and the cell phone of that same user may later determine that the
user is later in the notification geographic location. To this end,
cached offers may be updated by the offer management module 40 on
each consumer mobile device executing a client offer application
associated with a given user profile, such that a given user has a
consistent experience across multiple devices.
[0053] In another example, the consumer mobile device 14 may be a
cell phone that causes a consumer wearable device 22 to display
information about offers via a personal area network, such as via a
Bluetooth.TM. network. In some cases, the consumer wearable device
22 is a smart watch or head-mounted display coupled with the
consumer mobile device 14 via Bluetooth.TM. connection, and
notifications may be displayed on the consumer wearable device 22,
indicating that the user may redeem an offer. In some cases, as
noted above, the location of the user may be determined based on
the consumer device transmitting a beacon, in which case the beacon
may be transmitted by the consumer wearable device 22 or the
consumer mobile device 14, which is not to imply that consumer
wearable devices are not a type of consumer mobile device.
[0054] FIG. 1 illustrates two types of designations of geographic
areas, a geofence 16 defined by geographic coordinates and geofence
defined by a wireless range 18 (defined in this example by the
wireless range of a beacon transmitter 20). In other embodiments,
other arrangements may be used to specify geolocation, depending
upon a merchant's goals. For example, both of the geographic
locations may be geofences or both of the geographic locations may
be of the wireless range type. In one example, a mall is ringed
with a plurality of beacon transmitters in spaced relation, such
that users crossing a perimeter defined by the wireless range of
these transmitters may be presented with a notification relating to
a given store within that mall. In the illustrated example, the
cache geographic location is a geofence 16 and the notification
geographic location is a wireless range 18, but those roles may be
reversed, again depending upon engineering objectives. In some
cases, cached offer is one or both states of a multi-stage
geolocation offer, and users are rewarded for moving closer to
(e.g., traveling to) a merchant's store, for example. Some
embodiments may implement a cache geolocation corresponding to an
entrance to a mall or store in range of a Low Energy Bluetooth
beacon, with notification geographic locations corresponding to
other beacons, QR codes, bar codes, or the like, at various places
within the store.
[0055] In other examples, the notification geographic location is a
location at which the user happens to interact with an offers
application on the mobile device, such as when a user pauses to
search for offers while in a store. In some cases, in response to a
user request for offers, embodiments may search the offer cache for
responsive (e.g., in a category or having terms specified by the
user in the request), location-relevant offers (e.g., offers
corresponding to the store, a location within the store, or within
a threshold distance or transit time), and cached offers may be
presented to the user (e.g., before or upon determining that the
mobile device does not have a data connection or has an impaired
data connection).
[0056] In some cases, the notification geographic location may be
defined, in part, by a negative space within the notification
geographic location. The negative space may be a contained
geographic location (e.g., in interior concentric circle of the
notification geographic location) in which users are not notified
of a geolocated offer. Some merchants may wish to avoid sending
such notifications to users likely already on their way to a given
merchant's physical site without the added enticement of an offer.
The negative space may be defined by either the geofence or a
wireless range type geographic location, in some cases, the
wireless range geographic location defining the reward geographic
location.
[0057] In some embodiments, the merchants store or other physical
site includes a point-of-sale terminal 26 operable to record
transactions in, and retrieve data from, a merchant transaction
data repository 28. In some cases, as noted above, upon requesting
offers, users may be sent information that when presented to a
merchant sales clerk, may be used by the merchant sales clerk to
provide a benefit specified by the offer when the user redeems the
offer (e.g., a validation code unique to that user). In some
embodiments supporting single-use offers, after a user claims an
offer, the offer management module 40 may generate a unique
validation code and store the unique validation code in the
corresponding offer instance record. Validation codes may be
validated with a number of techniques, including the techniques
described above by which the validation code is sent to the offer
management module 40, which may respond with an indication of
whether the code is valid (e.g., was claimed and has not yet
redeemed). In some cases, the offer management module 40 may
retrieve an authorization code corresponding to the merchant's
point-of-sale terminal 26 from the merchant data repository 34, and
that code may be sent for entry into the point-of-sale terminal 26
to authorize conveyance of the corresponding benefit. In another
example, the unique validation code may also be sent to the
consumer mobile device 14, such that when the unique validation
code is presented by the user and entered into the point-of-sale
terminal 26, that code may be recognized in the merchant
transaction data repository 26 as a valid code and the appropriate
benefit may be recorded in the course of redeeming the offer.
[0058] The merchant transaction data repository 28 may store data
about user transactions with the merchant, including timestamps for
transactions, inventories of items or services purchased, prices
for purchases, and the like. In some cases, validation codes (which
may identify the offer distribution system 12, or other such
identifying values) are also stored, such that the merchant can
calculate the appropriate amount of compensation for the entity
operating the offer distribution system 12 for directing users to
the merchant's physical site. Or in some cases, the entity may be
compensated based on some other metric, such as an amount of foot
traffic directed into a store.
[0059] Merchant device 30 represents one or more computing devices
of the merchant or merchant employees that may be used to create
new geolocated offers. In some cases, merchant employees may log
into a web-based interface hosted by the offer distribution system
12 and design geolocation offers according to template stored in
the merchant data repository 34. In some cases, merchant employees
authenticate themselves using usernames and passwords indicating
that the employee is entitled to create offers on behalf of the
merchant. In another example, merchant employees may direct the
entity operating the offers discovered distribution system 12 to
create such offers. As noted above, in some embodiments, the
merchant device 30 may be a merchant employee mobile device used to
scan a visual display of a validation code and send a request to
the offer distribution system 12 to validate the validation code.
Thus, the merchant device 30 may be used to determine whether a
user is presenting a valid validation code or one that is fake or
has already been claimed.
[0060] The present techniques are applicable to both single-stage
geolocated offers and multi-stage geolocated offers. The latter,
being a more complex use case, is described to explain some
applicable distribution mechanisms. FIG. 2 shows an embodiment of a
process 56 for distributing multi-stage geolocated offers. The
process 56 may be performed by some embodiments of the
above-described offer distribution system 12, but is not limited to
such implementations. In this example, the process 56 begins with
obtaining data defining a multi-stage geolocated offer, as
indicated by block 58. Next, the multi-stage geolocated offer may
be sent to a consumer mobile device, as indicated by block 60.
Embodiments may further receive an indication that the consumer
mobile device is in the second geographic location of the
multistage geolocation offer, as indicated by block 62. In some
cases, embodiments determine that the multi-stage geolocated offer
has been redeemed based on receiving this indication, as indicated
by block 64.
[0061] FIG. 3 shows an embodiment of a process 66 for presenting
and redeeming multi-stage geolocated offers. In some embodiments,
the process 66 is performed by the above-described client offer
application 42 of FIG. 1, but is not limited to those
implementations. In this embodiment, the process 66 includes
obtaining data defining an offer available based on the consumer
mobile device being in a first geographic location and redeemable
based on the consumer mobile device later being a second geographic
location, as indicated by block 68. Next, embodiments may determine
whether the consumer mobile device is in the first geographic
location, as indicated by block 70. In some cases, a consumer
mobile device may be determined to be in a geographic location in
response to the consumer mobile device crossing a geofence, or
embodiments may make this determination in response to the consumer
mobile device being determined to currently be positioned within a
geographic location (which is not to suggest that geofence
traversal into the geofence is distinct from being in the geofence,
i.e., within the geofence, or at the corresponding geographic
location). Upon determining that the consumer mobile device is not
in the first geographic location, embodiments may continue to wait
until the consumer mobile device is in the first geographic
location. Upon determining that the consumer mobile device is in
the first geographic location, embodiments may present a
notification indicating that the offer is available, as indicated
by block 72. In some cases, the notification may indicate to the
user that the user will receive a reward in exchange for the user
traveling to the second geographic location. Some embodiments may
include content with a map illustrating the second geographic
location to assist users or request a mapping application on the
consumer mobile device to display the second geographic location.
Next, embodiments may determine whether the consumer mobile device
is in the second geographic location, as indicated by block 74. If
the consumer mobile device is not in the second geographic
location, embodiments may continue to wait until it is. In some
cases, offers may be associated with an expiration time, and
embodiments may include a step in which the process 66 is
terminated in response to determining that the current time is
after the expiration time. Upon determining that the consumer
mobile device is in the second geographic location, embodiments may
determine that the offer has been redeemed, as indicated by block
76. Redeeming the offer may include determining that the user is
entitled to a reward as described above, which may include entering
a game of chance, a cache reward, another offer, or the like.
[0062] Thus, some embodiments may manage multi-stage geolocated
offers. Further, some embodiments may do so in a way that is
amenable to operating at the scales frequently presented in
commercial offer distribution systems and with the speed and low
latency expected by users using such systems. Moreover, some
embodiments may implement such offers in a battery-friendly way,
and in a manner that is resilient to loss of data signals, such
that user experiences with multi-stage geolocated offers are
expected to be relatively robust. Again, however, applicants wish
to emphasize that the present techniques provide a number of
benefits that may be achieved independently and that not all
embodiments necessarily provide all of these benefits.
[0063] As noted above, some embodiments may cache offers for users
to accommodate areas with limited wireless connectivity. Some
embodiments may dynamically determine when a geofenced area has no
or slow internet connectivity and cache data (e.g., offers related
to the area) on mobile devices before the user enters the geofenced
area. Mobile network connectivity can often be unreliable,
especially in indoor spaces and at large events. In these
situations, users are often unable to obtain the desired offer data
when they most want to use the data. Some embodiments increase the
likelihood of delivery of the desired offer data when users
encounter these scenarios. To mitigate this problem, some
embodiments may dynamically detect geofenced areas that have
limited network connectivity and cache offer data when limited data
connection is detected. Some embodiments may also detect when
connectivity is re-established in cached areas and remove the
caching designation.
[0064] When a device enters a profiled geographic area (defined
using one or more of the techniques described above, such as with
geofences), some embodiments may toggle a flag within a mobile
client application, like those described above, e.g., as part of a
background process on the mobile device, to store records of
network connectivity issues. In some cases, profiled geofenced
areas may be the same as cache geographic areas or a notification
geographic areas. While in the profiled geographic area, the mobile
client application may profile the area by recording data
indicative of wireless connectivity issues, e.g., the application
may detect that a web request or API request timed out or was slow
(e.g., took longer than two seconds to service), and in response
create, in local memory, a record of the limited request. Each such
record may include a timestamp indicating the time of the limited
request, data describing the current geographic location (such as a
geofence identifier of the last geofence the user was determined by
the application to have entered), information about the mobile
device and wireless carrier (like mobile country codes/mobile
network codes and related data identifying the carrier and user
equipment). The resulting records may be stored in a log on the
mobile device. When connectivity returns, an event may be generated
(or connectivity may be polled periodically) that causes the
application to supplement records for these logged events (e.g., to
indicate a difference in location relative to where connectivity
was restored, or identify the cell tower or carrier, if such
information was not already in memory and used to create the
record), and send data on the failed requests. This data may be
analyzed by some embodiments of an offer distribution system (like
that described above) to determine which cellular (or other)
network is having connection issues in which geofence.
[0065] Based on the type of the geofenced area and number of failed
requests versus number of successful requests (e.g., aggregated
across a number of users over time), some embodiments may
automatically determine if a geofenced area should be marked as
limited for a particular carrier. In some cases, these records may
be updated as the wireless environment changes. A geofenced area,
in some embodiments, may also recover to full access, e.g., if
embodiments detect that the ratio of failed requests to successful
requests from a mobile client application to the offer distribution
system drops below a threshold.
[0066] Some embodiments may designate trouble areas based on other
feedback (customer support contact, or other user-imitated contact
like a prompt in the mobile client offers application), or manually
by hand-coding of geofenced areas, e.g., after sending an employee
to walk the area with a collection of handsets from different
wireless carriers to test connectivity in the area. In some cases,
designations of poor connectivity may be tied to a window of time
corresponding to an upcoming event. For example, some embodiments
may geofence (or otherwise designate an area of) a music concert or
a sporting event at a large stadium based on the expectation that
connectivity will be poor, and embodiments may determine that the
corresponding window of time is occurring and in response mark the
area as such so that users are less likely to have problems.
[0067] Once an area is marked as having limited connectivity, some
embodiments may automatically trigger caching of coupons (or other
offers) for stores within the geofenced area. When a matching
device (e.g., on the carrier associated with the geofence for
carrier-specific geofences) enters the geofenced area (for example,
the parking lot of a mall that has poor connectivity), the offer
distribution system may push a dynamically generated, compressed
coupon data package to the application, in some embodiments. This
data may contain information needed to search for and redeem deals
inside the geofence without sending requests to a remote server at
the time of offer discovery (e.g., due to automated notifications
or user interactions, like searching for offers, in an offers
application on the mobile device) by the user or at the time of
offer redemption. Some embodiments may store the data as a
preloaded cache of API responses from the offer distribution
system. Some embodiments may cache a smaller (e.g., lower image
resolution, or image-less content) set of data that can drive an
alternate display when richer content is not available. Some
embodiments may cache data containing a collection of stores and
coupons, where some coupons are described by records containing
barcode text, a barcode type, and active time range.
[0068] The application executing on the mobile device, in some
embodiments, may then store this cache until the application
determines the cache, or entries in the cache, expire, e.g., either
at a pre-determined time or at a set amount of time after the user
exits the geofence. To reduce bandwidth and storage consumption,
particularly for offers cached but never seen by the user, some
embodiments may render barcode images with the mobile client
application based on barcode code numbers (e.g., text) held in
cache, rather than sending images of the barcodes. Or some
embodiments may render QR codes natively in the application using a
similar technique for similar purposes.
[0069] While within the geofenced area, some embodiments of the
mobile client application may still attempt to fetch the data from
the remote offer distribution system wirelessly. However, the
application may determine that it is in a limited network area and,
in response, may render the cached coupon data first and network
data may be used as a backup, e.g., to supplement or update the
cached data after the cached data is presented to the user.
[0070] This caching technique is not limited to areas with poor
connectivity. Some embodiments may use this technique to reduce
response times to likely user interactions. Some embodiments may
cache when the offer discovery system or offers application
determines a user is likely (e.g., more than a 0.1% probability) to
view or redeem a given offer based on a user's profile and
attributes of the offer. Upon such a prediction, the offer may be
pushed to (or pulled by) the offers application executing on the
mobile device. Additionally, some embodiments may cache offers the
user has looked at recently (e.g., in response to a user viewing
them within a threshold duration of time).
[0071] Some embodiments may cache single-use offer codes, which in
some implementations, are more complicated to implement than
non-rivalrous unlimited use codes. When cached, single-use codes
may be marked in records of the offer distribution system as
reserved while cached on the user device. In some cases, the single
use codes may be deemed used by the offer distribution system when
the mobile client offers application marks the code as used in a
log of the transaction and later sends that information to the
offer distribution system upon connectivity being determined to
have returned of the application. In a network limited geographic
area, this may happen when the user exits the geofence. Otherwise,
in some embodiments, the reserved code may be designated as
returned to the available state when the user exits the geofence,
in response to an indication of non-use from the application to the
offer distribution system upon the return of connectivity being
detected.
[0072] Additionally, some embodiments of the mobile offers
application may automatically change the reserved codes to
available based on a time decay algorithm. Some embodiments may
take steps to prevent leaking of the codes out through the offers
application, e.g., by encrypting the code in memory, or preventing
single use codes from caching on jailbroken phones, and the mobile
application may determine that once the time decay has passed, the
application should not display the code, even if the user is still
inside the geofence. Some embodiments may reserve codes for users
entering a geofence if the remaining code count is over a certain
threshold, as determined by the offer distribution system. Some
embodiments may cache a portion of data about the offer but exclude
the validation code until the time of redemption, allowing
embodiments to transfer less data for the user to redeem the
single-use offer.
[0073] Some embodiments may log a variety of different types of
data on the mobile device while connectivity is impaired. In
addition to sending a report about having a poor connection back to
the offer distribution system, some embodiments may log analytics
requests that failed to send and batch them for sending when the
mobile device regains connectivity. Some embodiments may use this
data to determine which offers (or types of offers) the user tried
to open or request while inside the geofence, and in response,
prioritize caching those items for future users. For example, in a
mall with store A but no store B, many users may want to check if
store B has a better coupon, even though the nearest store B is a
few miles away. Some embodiments may use resulting analytics data
to determine to deliver store B offers to mobile devices entering
the geofence even though there is no store B inside. If there are
too many offers available inside a geofence to cache all
potentially relevant content, some embodiments may also use other
information in a user profile (including offer views, store
favoriting, or offer saves) to score, rank, and threshold which
offers are sent to be cached, to avoid wasting mobile-device
battery power, memory, and bandwidth by caching offers the user is
unlikely to use.
[0074] The above caching techniques may be implemented in a variety
of different ways. Representative examples are described with
reference to FIGS. 4 through 7. These figures depict examples of
processes that are performed by some embodiments of the
above-described offer distribution system 12 and the client offer
application 42 shown in FIG. 1, but embodiments are not limited to
those implementations.
[0075] FIG. 4 shows an example of a process 78 performed by some
embodiments of a client offer application to log the geographic
location of impaired or failed sessions with a remote offer
distribution system, e.g., due to poor wireless connectivity in the
geographic area. In some embodiments, the process 78 includes
receiving a request for offers, as indicated by block 80. Receiving
a request for offers may include receiving via a touchscreen of a
mobile device, such as a cell phone, user selections within an
offers application that indicate the user is requesting to view
offers. In some cases, the request includes criteria for selecting
the offers specified by the user input, such as a request to search
for offers related to a particular store, a particular geographic
area, a particular category of merchandise or services, or a
particular type of discount.
[0076] In other examples, receiving a request for offers may
include receiving a function call from an event handler that
automatically requests geographically relevant offers in response
to an event indicating the user's mobile device has entered a
notification geofence. For example, some embodiments may register a
plurality of geofences (such as a plurality of geofences within
some threshold distance of the user to conserve battery life by
avoiding monitoring for geofences over areas that are likely
irrelevant) with a library or framework provided by an operating
system of the mobile device (or other service, such as the service
provided by Gimbal, Inc. of San Diego Calif.), and some embodiments
may direct that library or framework to send signals to an offers
application indicating when a user has entered one of the geofences
and identifying which geofence, for example by a geofence
identifier. Offloading this task to the operating system, in some
embodiments, may help conserve battery life, as a plurality of
applications executing in the background on consumer mobile devices
may have similar needs, and sharing the task of detecting geofence
entry among the plurality of applications is expected to be less
power intensive than having each separate application duplicate
this task (though not all embodiments employ this technique). In
some cases, geofence-related events, or user input, may cause a
client offers application to select or otherwise compose an API
request to the offer distribution system, such as a request for
offers satisfying various criteria corresponding to the event or
input, such as search criteria, offers related to the geofence
identifier, or the like.
[0077] Next, some embodiments may determine that a wireless
connection to an offer discovery system is impaired, as indicated
by block 82. In some embodiments, the determination may be made by
determining that an API request sent to the offer distribution
system, or requested by the client offer application to be sent by
the operating system, is taking longer than a threshold amount of
time to receive a response, such as a complete response, from the
offer distribution system. In another example, some embodiments may
query the operating system of the consumer mobile device for a
current state of the wireless connection and determined based on
responsive data whether such a connection exists. To be clear, the
entirety of the connection to the offer distribution system need
not be wireless, and in many cases a first segment of the
connection may be wireless, such as from a mobile handset to a
cellular base station, while other segments are wired, such as from
the cellular base station to the offer distribution system. In
these examples, an impaired connection between a consumer mobile
device and a cellular base station (or other wireless access point)
can cause the determination of block 82 to be made, notwithstanding
a fully functional wired connection along the remainder of the
route.
[0078] In response to the determination of block 82, some
embodiments may log a failed request for an offer, as indicated by
block 84. In some cases, a failed request for an offer may include
a request to establish a networking session by which such a request
is to be sent, and the request itself need not necessarily be sent
if a precondition for sending the request fails, such as a stage of
the transmission control protocol (TCP) three-way handshake. In
some cases, the failed request may be logged in persistent memory
of the consumer mobile device that is accessible to the client
offer application 42. In some embodiments, the failed request may
be logged in persistent client-side browser accessible memory in
the case of a mobile web application, for example, in a
LocalStorage object key-value pair, a web SQL database, or an
indexed database, such as in an ObjectStore, or in a FileSystem
object created by a client-side web browser. In another example,
the log may be created by a native offers application operating
outside of the security sandbox that constrains typical web
applications. In some cases, the log may be created in a database
or document for subsequent retrieval.
[0079] In some cases, a log of failed requests may be maintained by
the client offers application over time, and the log may include a
plurality of failed request records. Each record may include a
timestamp indicating when the failed request occurred, a
geolocation (such as a latitude and longitude and confidence value,
a geofence identifier, or beacon identifier in range), a
description of the request (such as the text of an API request), a
description of the failure (such as an indication of whether the
content never arrived or the content arrived but took longer than a
threshold amount of time), and a description of the state of
wireless connections of the mobile device at the time of the
request (such as the type of wireless connection through which the
attempt was made, for instance, via a cellular connection or
Wi-Fi.TM., and a signal strength or connection quality, like a
signal-to-noise ratio, experienced by the consumer mobile device at
the time of the request). The records may also be associated with a
description of the consumer mobile device, such as an identifier of
the cellular carrier and an identifier of a mobile handset model.
In some cases, each record may be associated with a value
indicating whether the record has been sent to the offer
distribution system, and this value may be initially set to
indicate that the record has not been sent. In some cases, a
plurality of such records may accumulate before wireless
connectivity is restored.
[0080] Next, some embodiments may determine that a connection to an
offer discovery system is available, as indicated by block 86. In
some cases, the offer discovery system may encompass multiple
domains, and a connection to a domain through which log reports are
sent is established while a connection to another domain through
which offers are requested is not, in which case some embodiments
may deem the connection to have been reestablished for purposes of
the process 78. In some cases, the determination may be made by a
background process of the client offer application that
periodically polls the operating system for a state of the wireless
connection, or such a background process may periodically attempt
to communicate with the offer distribution system, for example,
with a heartbeat signal, and upon successful communication, this
background application may deem the connection reestablished. In
another example, the connection may be determined to be
reestablished upon a user interacting with the client offer
application, such as by requesting a mobile webpage from the offer
distribution system or by launching a native offers application,
and successful exchanges over the network may indicate the return
of a connection.
[0081] Some embodiments may determine whether a particular type of
connection is available for purposes of step 86. For example, some
embodiments may conserve a user's cellular data bandwidth by
disregarding cellular connections for purposes of reporting logs
until a Wi-Fi.TM. connection is established. Or some embodiments
may disregard cellular data connections until more than a threshold
amount of time or amount of data has accumulated, favoring
Wi-Fi.TM. connections before the threshold.
[0082] Upon determining that a connection is available, and in
response, some embodiments may send a report of the failed request
to the offer discovery system. Some embodiments may query or
otherwise iterate through a log of failed requests and select those
records associated with a value indicating the record has not yet
been sent to the offer distribution system. In some embodiments,
the selected reports may be sent to the offer distribution system.
In some cases, the failed reports may be sent a substantial amount
of time after receiving the documented requests for offers, such as
more than 10 minutes later or more than a day later.
[0083] FIG. 5 shows an example of a process 90 performed by some
embodiments of an offer distribution system to identify geographic
areas with poor wireless connectivity based on reports of failed
content requests from a plurality of user devices. In some
embodiments, the process 90 includes receiving records of failed
requests from a plurality of user devices, as indicated by block
92. In some cases, a relatively large number, such as millions, of
consumer mobile devices may perform the process described above
with reference to FIG. 4. In some embodiments, log reports from
those mobile devices may be collected by an offer distribution
system. In some cases, the collection may occur over some duration
of time, such as until a threshold amount of reports have been
received, until the reports in the aggregate indicate conditions
have changed in some areas, or until some fixed duration of time
has elapsed, like 24 hours, a week, or a month, depending upon
trade-offs between responsiveness and use of computational
resources. In some cases, the records may be received from consumer
mobile devices distributed over a relatively large geographic area,
such as the United States, North America, or the world.
[0084] In some embodiments, the process 90 includes grouping the
failed requests by geographic location, as indicated by block 94.
In some cases, the received records include an identifier of a
geofence, and the records may be grouped according to geofence,
with each group corresponding to a given geofence, or in the case
of nested geofences, multiple geofences. In other examples,
geographic areas may be segmented according to the geolocations in
the records, for example, by clustering according to geolocation.
Some embodiments may execute a density-based clustering algorithm,
like DBSCAN, to establish groups corresponding to the resulting
clusters and exclude outliers.
[0085] To cluster according to geolocation, some embodiments may
iterate through each of the geolocations reflected in the records
and designate a geolocation as a core geolocation if at least a
threshold number of the other geolocations in the records are
within a threshold geographic distance. Some embodiments may then
iterate through each of the geolocations and create a graph of
reachable geolocations, where nodes on the graph are identified in
response to non-core corresponding geolocations being within a
threshold distance of a core geolocation in the graph, and in
response to core geolocations in the graph being reachable by other
core geolocations in the graph. In this context, geolocations are
reachable from one another if there is a path from one geolocation
to the other geolocation where every link and the path is between
core geolocations, and those core geolocations are within a
threshold distance of one another. The set of nodes in each
resulting graph, in some embodiments, may be designated as a
cluster, and points excluded from the graphs may be designated as
outliers that do not correspond to clusters. In some examples, the
location in the records may be indicated by an identifier of a
wireless transmitter, such as a cellular tower identifier, or a
service set identifier of an in-store Wi-Fi network, and
embodiments may group the failed requests according to this
identifier, such that each group of records has the same
identifier.
[0086] In some embodiments, the received records may be grouped
according to both geolocation and time to capture transient events
with higher temporal fidelity than systems that analyze records
without regard to time. By grouping by time and location, some
embodiments may establish groups corresponding to events, such as
the location of college sports stadiums during weekends in the
fall, indicating poor wireless reception due to large numbers of
users overwhelming cellular networks. In other examples, some
embodiments may filter the records according to time, for instance,
discarding or disregarding records older than a threshold age, such
as older than one week, or older than one month, depending upon
desired responsiveness and statistical power.
[0087] Alternatively or additionally, some embodiments may group
the received records according to a cellular service provider
identified in the records to establish groups corresponding to
areas in which a given service provider has poor wireless
connectivity while other service providers may have adequate
wireless connectivity. In another example, some embodiments may
group the received records according to handset model to identify
areas in which a given model of handset has worse wireless
connectivity than other handsets, for instance, those having more
robust antennas. Some embodiments may compose a vector from scaler
values reflecting each of latitude, longitude, time, cellular
carrier, and handset model and, then, cluster the resulting vectors
using the techniques described above to establish groups indicative
of a temporal, carrier-specific, handset-specific geographic areas
in which connectivity is problematic.
[0088] Some embodiments may then determine, for each geographic
location, or group, whether wireless connectivity is impaired based
on the amount of records, as indicated by block 96. For example,
some embodiments may determine whether a given group has more than
a threshold amount of records, where the amount is, for instance, a
frequency or count, and the threshold is selected according to
trade-offs between the risks of over caching and false negatives.
In some cases, the threshold may be calculated based on a total
amount of requests for offers within the geographic area
corresponding to the group, as some particularly high-traffic areas
may have a relatively large number of failed requests that
represent a relatively small proportion of the total amount of
requests. In some cases, the total amount (which may be estimated
based on a sampling of the area) may be calculated based on a
logged successful request for content or by including an identifier
of the geographic location in a received request for content and
accumulating the total from received requests that are successfully
serviced.
[0089] In some cases, the records may be scored differently
depending upon the severity of the impairment, for instance, with
complete failures to provide content scored as 1 and slow responses
for request for content scored as a 0.5. In these examples, the
score may be compared to a threshold to determine whether
connectivity is impaired. In another example, determining whether a
wireless connectivity is impaired for the group may include
calculating a score for the geographic area indicative of
problematic wireless connectivity, for instance, a ratio of the
above describes score and a total amount of traffic. Some
embodiments may determine whether to cache offers for the
geographic area based on this resulting score and other parameters,
such as an amount of battery power remaining on a given user device
as indicated in the request from the user device for cached offers
or a predicted likelihood that a user will redeem an offer that
would otherwise be cached.
[0090] In response to determining that a geographic location has
impaired wireless connectivity, some embodiments may designate
those geographic locations as cache geographic locations, as
indicating by block 98. Such a designation may be a binary flag
that is associated with a record of the corresponding geolocation
in memory, with a value of true indicating that connectivity is
poor and offers are to be cached, and a value of false indicating
the opposite. In other examples, the designation may be a score
associated with the geographic area, with the score serving as one
of several inputs into a determination of whether offers are to be
cached in a given instance for a given context.
[0091] FIG. 6 shows an example of a process 100 that may be
performed by parts of the offer discovery system 10 described above
to predicatively cache locally relevant offers on consumer mobile
devices entering previously designated cached geographic areas. In
some cases, the cached geographic areas may be identified with the
techniques described above with reference to FIGS. 4 and 5. In some
cases, the cached geographic areas may be identified well in
advance, such as more than an hour or more than one week, of
performing the process of FIG. 6, as identifying cached geographic
areas may be relatively computationally complex and slow relative
to the window of time in which offers are to be cached. FIG. 6
shows a dotted line with a client device on one side and offer
distribution system on the other. Steps performed by these
respective components are positioned on the corresponding side of
the dotted line. The client device may be the consumer mobile
device 14 described above with reference to FIG. 1.
[0092] In some embodiments, the process 100 begins with the client
device obtaining a current geolocation of the client device, as
indicated by block 102. In some cases, the current geolocation may
be obtained upon an event being created by a geolocation library or
framework that indicates the client device has moved more than a
threshold amount, such as more than 1 km or has changed cellular
towers, to conserve battery life and excessive polling of a global
positioning system unit or other geolocation system on the client
device. (Though it should be noted that embodiments are consistent
with more battery intensive techniques, for instance to favor
faster response times and higher fidelity to location.) In some
cases, the current geolocation may be obtained by a background
process of the client offer application that subscribes to the
library or framework to receive such events.
[0093] Next, some embodiments may request geofences near the
current geolocation from the offer distribution system, as
indicated by block 104. In some cases, the request may be a request
executed by the background process in the form of an API request
for geofences within some threshold distance of the current
geolocation. In some cases, the threshold distance may be
relatively large, for instance encompassing an entire city or state
in cases in which geofences are relatively low density relative to
the processing capabilities of the client device. Such distances
may be calculated with a variety of techniques, for instance,
relative to a centroid of the geofences, or in some cases, the
geofences may be obtained based on being grouped with a larger
geographic area in which the client devices currently located, for
instance, in the western half of the United States.
[0094] Upon receiving the request, some embodiments of the offer
distribution system may select geofences based on the current
location reflected in the request, as indicated by block 140. As
noted above, the geofences may be encoded in a variety of formats,
for instance, a center point and radius or a polygon with vertices
corresponding to a latitude and longitude. In some cases, the
obtained geofences may be associated with values that indicate the
purpose of the geofence. Some obtain geofences may be designated as
cache geofences, for instance, responsive to the processes
described above with reference to FIGS. 4 and 5, and some geofences
may be designated as notification geofences. Cache geofences may
correspond to geographic areas in which offers are to be
predicatively loaded to compensate for poor wireless connectivity
in the geographic area, and notification geofences may be
geographic areas in which users are notified of offers in response
to the user being in the area, for instance, automatically upon
detecting that the client device is in the notification geographic
area. In some cases geofences (or other designations of geographic
areas) are labeled as both cache geofences and notification
geofences, and the user is notified of the offer, but additional
content relating to the offer (such as images and a fuller
description) is held in cache memory in case the user elects to
engage with the offer, for instance, by selecting the notification.
The responsive geofences, which may include a cache geofence, may
be sent to the client device, as indicated by block 138.
[0095] Upon receiving the geofences, they may be stored by the
client device, as indicated by block 106. Storing the geofences may
include instructing a geolocation framework or library of the
client device to begin monitoring whether the client device is
currently within one of the received geofences. In some cases, the
request for monitoring may identify a desired accuracy, such that
the process may be de-tuned to save battery life. In some cases,
all of the received geofences may begin to be monitored, or some
embodiments may begin monitoring only a subset, such as those
within a threshold distance of the current location. In some
embodiments, upon receiving the geofences, other geofences that
were not among those received may be removed from the set that the
client devices currently monitoring to conserve battery power.
[0096] Next, some embodiments may monitor (e.g. periodically or in
response to some event, such as changing cell towers or moving more
than a threshold distance) whether the client device is in a cache
geofence, as indicated by block 108. Such monitoring may be
performed with any of the techniques described above for
determining whether a client device is in a designated geographic
area. Upon determining that the current location is in a geofence
being monitored and that that geofence was labeled by the offer
distribution system as a cache geofence, some embodiments may
request offers to cache, as indicated by block 110. In some
embodiments, the client device may allow the user to initiate the
request that offers be cached, even if the user is not within a
geofence. For instance, the client offers application may present a
user interface input that, when selected by a user, causes the
client offers application to acquire the device's current
geolocation and submit a request for offers to cache related to
that geolocation, e.g., potentially relevant offers within some
threshold distance, or such offers related to areas within that
distance that are known to have poor wireless connectivity. In some
cases, the offer distribution system, upon receiving such a
request, may select responsive offers, and send those offers to the
client device, which may store the received offers in cache
memory.
[0097] In some cases, determining that the user is in the cache
geofence may include determining that the user has entered the
cache geofence. For instance, some embodiments may determine at a
first time that the user is external to the cache geofence and,
then, at a second time, that the user is within the cache geofence,
to initiate a request for offers to cache. Some such embodiments
may subsequently determine that the user is still in the cache
geofence and, in response to the earlier determination, not issue
another request for cached offers to reduce bandwidth and conserve
batter life.
[0098] Upon receiving this request, some embodiments of the offer
distribution system may select offers to cache, as indicated by
block 134. In some cases, the request includes an identifier of the
cache geofence or a more precise current location of the client
device, and these values are used to select offers to cache based
on geographic location. For instance, periodically after creating a
cache geofence, some embodiments may preselect offers corresponding
to the geographic area to favor relatively low latency responses to
the request while still updating the offers to reflect changing
merchant and user preferences. Or some embodiments may select
offers in response to receiving the request, e.g., to account for
attributes of the user in the user's profile.
[0099] Offers may be selected based on a variety of criteria to
serve a variety of different objectives and satisfy a variety of
different constraints. For instance, offers may be selected based
on a predicted likelihood of the user requesting the offer, to
increase the likelihood that a requested offer is available for the
user regardless of wireless connectivity, to increase user
perception of reliability of the offer application, and to increase
usage generally. In another example, offers may be selected based
on a predicted likelihood of the user redeeming the offer and the
predicted affiliate payment to increase revenues in areas with poor
wireless connectivity. Or some embodiments may accept both of these
inputs and provide a blended selection that balances between these
objectives (e.g., calculating a weighted sum score for each offer
and selecting according to rank). Such predictions may be based on
records of past user interactions with offers and patterns in those
records that correspond with the current context. For instance,
offers that were requested or redeemed more frequently than a
threshold amount by users having a similar user profile to that of
the user associated with the client device may be selected. Or
offers that were previously redeemed or requested more frequently
than a threshold amount in the geographic area, for instance,
during the same day of the week or times of year, may be selected.
Some embodiments may construct a predictive model, such as a neural
net, based on each of these inputs to select offers. Some
embodiments may train such a model based on past user requests and
redemptions according to a gradient descent algorithm, such as a
stochastic gradient descent, and the current context may input into
the model to select the offers to cache. In some cases, the
selected offers are single-use offers, in which case the process of
FIG. 7 may be performed in conjunction with these techniques.
[0100] Next, some embodiments may send the selected offers to the
client device, as indicated by block 132. In some cases, the
selected offers may be preprocessed to account for the
lower-likelihood of being used relative to offers requested by a
user. For instance, some embodiments may provide a downgraded
experience that uses less bandwidth and memory as a backup to the
user experience in which wireless connectivity is present. For
example, some embodiments may retrieve a subset of an offer record
that describes a given offer and is less than what is sent to a
user using a device that has wireless connectivity. Some
embodiments may omit images, or just those that are relatively
large consumers of data. In another example, some embodiments may
omit images of barcodes (e.g., one-dimensional barcodes or
two-dimensional barcodes, like QR codes), and a corresponding
barcode number and barcode type (e.g., indicating that a QR code or
other type that is to be used) may be sent to the client offer
application, which may include a module configured to generate an
image of the specified barcode based on the number and barcode
type, thereby avoiding transmitting a relatively data intensive
image of a barcode. In another example, the selected offers may be
compressed and transmitted in a compressed data format before being
decompressed client-side for usage.
[0101] In some cases, before transmission, the offers may be
associated with API requests or parameters for such requests to
which the offers pertain. For instance, some embodiments may
determine that users are relatively likely to request or redeem
offers relating to the category of sporting-goods while in a
particular area of the cache geofence (e.g. a notification
geofence), and the corresponding offers may be selected in view of
this and associated with API requests for offers in the category of
sporting-goods or offers from a merchant in the category of
sporting-goods retailers.
[0102] Before transmission, the offers may also be associated with
geolocations within the cache geofence, such as a notification
geofence, or a latitude and longitude of a merchant store at which
the offer is redeemable. These geolocations may be processed by the
client device when selecting offers in the absence of wireless
connectivity, for instance, by ranking offers in cache memory
according to distance from the users current location, or to
provide automated notification of offers pertaining to a particular
wireless beacon encountered by the client device. In some cases,
the selected offers may be organized in a database file that, when
loaded in the client device, is responsive to various queries
composed client-side based on user requests for offers, such as an
indexed database. In some cases, prior to sending, some of the
selected offers are associated with an expiration time, which may
be enforced by the client device to avoid presenting offers that
have expired during the period in which the user is without
wireless connectivity.
[0103] Upon receiving the offers, the client device may store the
offers in cache memory, as indicated by block 112. Cache memory may
include any of a variety of different types of client-side memory
and is not limited to cache memory in the context of a central
processing unit, such as L2 cache. In some cases, compressed
binaries of offers may be decompressed to facilitate relatively
fast interrogation of the collection of offers in response to later
requests for offers by the user.
[0104] Next, and potentially repeatedly for several hours or days
in the future, some embodiments may determine whether the user is
requesting offer content, as indicated by block 114. Request for
offer content, as noted above, may include a user interacting with
the user interface of a client offer application, e.g., to search
for offers redeemable near (e.g. within a threshold distance or
ranked in order of distance from) their current geolocation, or to
view offers in various categories. Or requesting offer may include
a background process of a client offers application detecting an
event indicating proximity to a geolocation at which a notification
is to be presented to the consumer, such as presenting a
notification on a lock screen of a cell phone (or on a wearable
device) indicating that an offer is redeemable in response to
detecting an identifier of a transmitter in range corresponding to
the offer.
[0105] As noted above, the notification geofence may be smaller
than the cache geofence, and in some cases multiple notification
geofences may be disposed in the cache geofence. For instance, the
cache geofence may encompass a larger area having multiple pockets
of poor wireless connectivity. In some cases, the cache geofence
may be sized such that a buffer region is present around
notification geofences to allow time for caching to occur while a
user travers further into a cache geofence, like a cache geofence
at a 2-mile radius around a mall, with a notification geofence at a
1-mile radius around the mall.
[0106] Or requesting an offer may include a user selecting such a
notification and requesting to view a fuller description of an
offer corresponding to the notification. Upon determining that user
is not requesting offer content, some embodiments may return to the
determination of block 108. Upon determining that the user is
requesting offer content, some embodiments may proceed to the steps
described next.
[0107] Some embodiments of the client device may send a request for
responsive offers, as indicated by block 116. Sending a request for
responsive offers may include attempting to wirelessly send, or
successfully wirelessly sending, a request to the offer
distribution system. And some cases, sending a request for
responsive offers may include querying an operating system of a
consumer mobile device for a current state of a wireless connection
to determine that such a request cannot be sent, even if the
request is not sent due to the operating system indicating that a
wireless connection is lacking.
[0108] Next, some embodiments may determine whether the request of
block 116 failed, as indicated in block 118. As noted above, a
failed request may be indicated by the operating system signaling
an offer application that wireless connectivity is unavailable (or
connectivity generally to a network is unavailable). In some cases,
a request for offer content may be transmitted or partially
transmitted, but a response, such as a full response, from the
offer distribution system may not be received within a threshold
duration of time, in which case some embodiments may determine that
the request failed. In some cases, requests may be identified as
failing in different ways, such as failing due to a request not
being sent because of a lack of network connections, failing due to
a request being sent but a full response not being received, or
failing due to a request being sent and a full response not being
received within a threshold duration of time, such as within 2 to 5
seconds, depending upon trade-offs between over caching and
presenting higher latencies to users. Upon determining that the
request did not fail, some embodiments may proceed to present the
selected offers, as shown in block 122 and described below. Upon
determining that the request did fail, some embodiments may proceed
to the step described next.
[0109] In response to a failed request, some embodiments may select
offers from among the cached offers received in step 112, as
indicated by block 120. In some cases, offers may be selected from
among the cached offers using the same or a subset of the
techniques with which the offer distribution system selects offers
in response to user requests. In some cases, an API request that
remains unserviced from step 116 may be compared to the text of API
requests associated with the offers in the cache memory, and offers
having the same API requests associated with the offer may be
selected. (In some cases, a single offer may be responsive to
multiple API requests, and the association may be in the form of a
list of offer identifiers associated with each API request, with
some offer identifiers appearing in multiple lists of multiple API
requests.)
[0110] In some cases, a response may be approximated. In some
embodiments, a request in step 116 may be less specific than an API
request stored in cache memory, in which case each of a plurality
of more specific API requests stored in cache memory may be
identified (if available), corresponding offers may be
de-duplicated, and the resulting offers may be selected. Relative
specificity and generality may be determined based on parameters of
the requests, e.g., based on species genus relationships in an
ontology of offers, based on one request having a subset of
keywords to search by relative to those in another request, or
based on varying granularity in specification of geographic
areas.
[0111] In another example, a request in step 116 may be more
specific than an API request stored in cache memory, in which case
some embodiments may identify the closest, more-general API
requests from among the API request stored in cache memory, and the
corresponding offers may be selected. In some cases, the
corresponding offers of the more general API requests may be
filtered according to the criteria specified in the request from
step 116, for example, selecting offers that include a keyword
specified in the request from step 116 or selecting offers
associated with a subcategory identified in step 116 of a category
specified in the more general API request.
[0112] In some embodiments, the offers may be stored client-side in
a relational database, and a query corresponding to the request
from step 116 may be submitted to the database on the client device
by the offer application. In some cases, none of the offers in
cache memory may be responsive, in which case a message to the user
may be presented indicating that wireless connectivity is
preventing a response. In some cases, more than a presentation
threshold amount of offers may be selected, in which case the
offers may be ranked, e.g., based on geographic distance to the
user, an amount of discount, a predicted amount of affiliate
compensation, or a predicted likelihood of redemption, and offers
ranking above the presentation threshold may be presented while
offers below the presentation threshold may be withheld from the
user.
[0113] Next, some embodiments may present the selected offers, as
indicated by block 122. Presenting the selected offers may be
performed in a variety of different ways. In some cases, the offers
may be presented in ranked order. In some cases, the offers may be
presented on the consumer mobile device. In other cases, the offers
may be presented on another device carried with the user, such as a
wearable consumer device, like a smart watch or a head-mounted
display. Or the offers may be presented on an in-dash car computer
or an in-store kiosk (like a tablet computer attached to a
merchant's fixture). In some cases, the consumer's mobile device
may instruct these other proximate computing devices to present the
offer via a Bluetooth.TM. connection, a Wi-Fi Connection.TM., or
the like. In some cases, the offer may be presented multiple times,
for instance, initially as a notification on a consumer mobile
device, and then on a full-screen display of an offers application
(e.g. a web application or a native application) launched in
response to the user selecting a notification. In some cases, one
of the presentations of the offer includes a scannable code (like a
barcode) that when scanned by a point-of-sale terminal indicates
that the user is entitled to redeem the corresponding offer.
[0114] In some cases, a portion of offer content required to redeem
an offer, such as a redemption code, is withheld from the cache,
and a relatively low-data-intensive request for the redemption
code, which is often relatively small portion of the description of
an offer, is sent to the offer distribution system. Often areas
with poor wireless connectivity still support relatively
low-bandwidth transmissions of data, such as those of a redemption
code that exclude a substantial amount of, or all of, the remaining
content by which an offer is presented to a user. Withholding the
offer code is expected to enhance tracking of user redemption of
offers, facilitating more accurate payments from merchants to those
operating affiliate networks and publishers at the risk of some
offers going unredeemed due to zero wireless connectivity.
[0115] Some embodiments may log user interactions with an offer, as
indicated by block 124. In some cases, the log may be maintained in
memory of the client device and held until wireless connectivity
returns and the information can be sent to the offer distribution
system. Some embodiments may log records of a user being notified
of an offer, a user requesting offers, a user being presented with
displays of an offer, and a user requesting a display of an offer
that includes a redemption code, such as a barcode or a text code
that can be scanned or typed into a point-of-sale terminal.
[0116] In some embodiments, the presentation of an offer that
includes such a code may be sequenced such that the user first
views a description of the offer without the code and, then, the
code is displayed in response to a user request (e.g., selecting an
on-screen button) to view the code. Staging the code presentation
in this fashion is expected to yield relatively accurate records
that distinguish between offers that were merely viewed and offers
that were more likely to have been redeemed. The more accurate data
may be used to seek more accurate compensation of affiliates and
publishers from merchants than is available through some
conventional systems. In some cases, each logged user interaction
may be associated with a geolocation and the timestamp for
accumulating metrics that demonstrate value to merchants.
[0117] Next, some embodiments may monitor whether connectivity has
returned, as indicated by block 126. This step may be performed
with the techniques described above with reference to step 86 of
FIG. 4.
[0118] Upon determining connectivity has returned, some embodiments
may send records of the logged user interactions to the offer
distribution system, as indicated by block 128, and the offer
distribution system may store the records of the user interaction
to seek compensation from merchants, as indicated by block 130. In
some cases, the offer distribution system may aggregate such
records across a relatively large number of users over time, and
statistics indicative of the performance of offers may be
calculated for presentation to merchants, for example, in a
dashboard of a web interface hosted by the offer distribution
system viewable in a merchant's account with the system.
[0119] FIG. 7 shows an embodiment of a process 142 performed by an
offer distribution system, e.g., like those described above, for
caching and tracking single-use offers. As noted above, single-use
offers are often distributed with a finite number of instances,
each instance being tracked with a unique identifier of the offer
instance. This attribute can present challenges in the context of
caching offers, as cached offer instances may remain in an
indeterminate state from the perspective of the offer distribution
system after being sent to a client device for caching and while
the client device is an area without wireless connectivity. This
indeterminate state problem may be mitigated by some embodiments of
the process shown by FIG. 7.
[0120] In some cases, the process 142 begins with receiving a
request for offers to cache, as indicated by block 144. In some
cases, this request is the request transmitted in step 110 of FIG.
6. Next, some embodiments may select a single-use offer, as
indicated by block 146. In some cases, a plurality of single-use
offers may be selected, and in some cases both single use and
multi-use offers may be selected. In some cases, the processes
described above with reference to step 134 of FIG. 6 may be
executed to select the offers.
[0121] Next, some embodiments may determine whether any single-use
offer instances are available, as indicated by block 148. In some
embodiments, a merchant may specify that only a finite number of
single-use offer codes are allocated to a given publisher, and that
publisher may determine whether any of those instances remain,
e.g., by querying a repository of offer instances or offer
instances designated as unredeemed and unreserved. Upon determining
that no single-use offer instances are available, the process 142
may terminate, at least as to that single-use offer.
[0122] Upon determining that an offer instance is available, some
embodiments may designate an un-reserved, unredeemed instance of
the single-use offer as reserved in memory, as indicated by block
150. This designation may be performed in some embodiments by
updating an offer instance record in the offer repository described
above with reference to FIG. 1 to include a value indicating that
the instance is reserved. In some cases, the reservation
designation includes a timestamp and a designation of when the
reservation expires, such that reserved offers can be unreserved in
the event that the client device never regains wireless
connectivity.
[0123] Next, some embodiments may send the single-use offer
instance to the client device to be stored in cache memory, as
indicated by block 152. In some cases, the sent offer instance
includes a time at which the offer instance expires and a time at
which the reservation of the offer instance expires. Some
embodiments of the client device application may determine whether
an offer instance is expired in either sense as a precondition to
presenting the offer instance to the user. Consequently, some
embodiments may unreserved offer instances automatically on both
the client and the server side, even in the absence of
communication between the client and server, provided that
timekeeping is roughly aligned between the two systems. In some
cases, the reservation expiration time on the client device may be
sooner than the reservation expiration time on the offer
distribution system to allow for some misalignment, for example,
several hours or one day sooner. The sent offer instance may
include a unique identifier of the offer instance that may be
presented to the user and entered into a merchant point-of-sale
terminal, in which case some embodiments of the point-of-sale
terminal may report back to the offer distribution system that the
offer instance was redeemed.
[0124] Next, some embodiments may determine whether a usage report
has been received indicating that the offer instance was redeemed
or not redeemed, as indicated by block 154. In some cases, the
usage report may be received after a client device performs the
steps described above with reference to blocks 124, 126, and 128 of
FIG. 6. In other cases, the usage report may be received from a
point-of-sale terminal upon a unique identifier of the offer
instance being submitted and the offer instance being validated by
the offer distribution system as a condition of redemption.
[0125] Upon receiving a usage report, some embodiments may parse
the report for an identifier of the single-use offer instance and
determine whether the single-use offer instance is associated with
a value indicating usage. Upon determining that the single-use
offer instance was used, some embodiments may designate the
single-use offer instance as redeemed in memory of the offer
distribution system, as indicated by block 158. Upon determining
that the single-use offer instance was not used, some embodiments
may designate the single-use offer instance as unreserved, as
indicated by block 160.
[0126] Thus, some embodiments may facilitate offer redemption,
including redemption and presentation of single-use offers, even in
areas with poor wireless connectivity. It is expected that
providing offers even in these relatively challenging conditions
will cause users to use the above-described offer applications more
often, even in scenarios where wireless connectivity is robust, as
users generally value reliability and tend to favor services and
applications that work regardless of transient technical
challenges. Accordingly, the processes above should be considered
as including steps by which offers are distributed via a wireless
connection in some, and in many cases most instances, with
challenging cases being handled with the techniques described
above.
[0127] FIG. 8 is a diagram that illustrates an exemplary computing
system 1000 in accordance with embodiments of the present
technique. Various portions of systems and methods described
herein, may include or be executed on one or more computer systems
similar to computing system 1000. Further, processes and modules
described herein may be executed by one or more processing systems
similar to that of computing system 1000.
[0128] Computing system 1000 may include one or more processors
(e.g., processors 1010a-1010n) coupled to system memory 1020, an
input/output I/O device interface 1030, and a network interface
1040 via an input/output (I/O) interface 1050. A processor may
include a single processor or a plurality of processors (e.g.,
distributed processors). A processor may be any suitable processor
capable of executing or otherwise performing instructions. A
processor may include a central processing unit (CPU) that carries
out program instructions to perform the arithmetical, logical, and
input/output operations of computing system 1000. A processor may
execute code (e.g., processor firmware, a protocol stack, a
database management system, an operating system, or a combination
thereof) that creates an execution environment for program
instructions. A processor may include a programmable processor. A
processor may include general or special purpose microprocessors. A
processor may receive instructions and data from a memory (e.g.,
system memory 1020). Computing system 1000 may be a uni-processor
system including one processor (e.g., processor 1010a), or a
multi-processor system including any number of suitable processors
(e.g., 1010a-1010n). Multiple processors may be employed to provide
for parallel or sequential execution of one or more portions of the
techniques described herein. Processes, such as logic flows,
described herein may be performed by one or more programmable
processors executing one or more computer programs to perform
functions by operating on input data and generating corresponding
output. Processes described herein may be performed by, and
apparatus can also be implemented as, special purpose logic
circuitry, e.g., an FPGA (field programmable gate array) or an ASIC
(application specific integrated circuit). Computing system 1000
may include a plurality of computing devices (e.g., distributed
computer systems) to implement various processing functions.
[0129] I/O device interface 1030 may provide an interface for
connection of one or more I/O devices 1060 to computer system 1000.
I/O devices may include devices that receive input (e.g., from a
user) or output information (e.g., to a user). I/O devices 1060 may
include, for example, graphical user interface presented on
displays (e.g., a cathode ray tube (CRT) or liquid crystal display
(LCD) monitor), pointing devices (e.g., a computer mouse or
trackball), keyboards, keypads, touchpads, scanning devices, voice
recognition devices, gesture recognition devices, printers, audio
speakers, microphones, cameras, or the like. I/O devices 1060 may
be connected to computer system 1000 through a wired or wireless
connection. I/O devices 1060 may be connected to computer system
1000 from a remote location. I/O devices 1060 located on remote
computer system, for example, may be connected to computer system
1000 via a network and network interface 1040.
[0130] Network interface 1040 may include a network adapter that
provides for connection of computer system 1000 to a network.
Network interface may 1040 may facilitate data exchange between
computer system 1000 and other devices connected to the network.
Network interface 1040 may support wired or wireless communication.
The network may include an electronic communication network, such
as the Internet, a local area network (LAN), a wide area network
(WAN), a cellular communications network, or the like.
[0131] System memory 1020 may be configured to store program
instructions 1100 or data 1110. Program instructions 1100 may be
executable by a processor (e.g., one or more of processors
1010a-1010n) to implement one or more embodiments of the present
techniques. Instructions 1100 may include modules of computer
program instructions for implementing one or more techniques
described herein with regard to various processing modules. Program
instructions may include a computer program (which in certain forms
is known as a program, software, software application, script, or
code). A computer program may be written in a programming language,
including compiled or interpreted languages, or declarative or
procedural languages. A computer program may include a unit
suitable for use in a computing environment, including as a
stand-alone program, a module, a component, or a subroutine. A
computer program may or may not correspond to a file in a file
system. A program may be stored in a portion of a file that holds
other programs or data (e.g., one or more scripts stored in a
markup language document), in a single file dedicated to the
program in question, or in multiple coordinated files (e.g., files
that store one or more modules, sub programs, or portions of code).
A computer program may be deployed to be executed on one or more
computer processors located locally at one site or distributed
across multiple remote sites and interconnected by a communication
network.
[0132] System memory 1020 may include a tangible program carrier
having program instructions stored thereon. A tangible program
carrier may include a non-transitory computer readable storage
medium. A non-transitory computer readable storage medium may
include a machine readable storage device, a machine readable
storage substrate, a memory device, or any combination thereof.
Non-transitory computer readable storage medium may include
non-volatile memory (e.g., flash memory, ROM, PROM, EPROM, EEPROM
memory), volatile memory (e.g., random access memory (RAM), static
random access memory (SRAM), synchronous dynamic RAM (SDRAM)), bulk
storage memory (e.g., CD-ROM and/or DVD-ROM, hard-drives), or the
like. System memory 1020 may include a non-transitory computer
readable storage medium that may have program instructions stored
thereon that are executable by a computer processor (e.g., one or
more of processors 1010a-1010n) to cause the subject matter and the
functional operations described herein. A memory (e.g., system
memory 1020) may include a single memory device and/or a plurality
of memory devices (e.g., distributed memory devices).
[0133] I/O interface 1050 may be configured to coordinate I/O
traffic between processors 1010a-1010n, system memory 1020, network
interface 1040, I/O devices 1060, and/or other peripheral devices.
I/O interface 1050 may perform protocol, timing, or other data
transformations to convert data signals from one component (e.g.,
system memory 1020) into a format suitable for use by another
component (e.g., processors 1010a-1010n). I/O interface 1050 may
include support for devices attached through various types of
peripheral buses, such as a variant of the Peripheral Component
Interconnect (PCI) bus standard or the Universal Serial Bus (USB)
standard.
[0134] Embodiments of the techniques described herein may be
implemented using a single instance of computer system 1000 or
multiple computer systems 1000 configured to host different
portions or instances of embodiments. Multiple computer systems
1000 may provide for parallel or sequential processing/execution of
one or more portions of the techniques described herein.
[0135] Those skilled in the art will appreciate that computer
system 1000 is merely illustrative and is not intended to limit the
scope of the techniques described herein. Computer system 1000 may
include any combination of devices or software that may perform or
otherwise provide for the performance of the techniques described
herein. For example, computer system 1000 may include or be a
combination of a cloud-computing system, a data center, a server
rack, a server, a virtual server, a desktop computer, a laptop
computer, a tablet computer, a server device, a client device, a
mobile telephone, a personal digital assistant (PDA), a mobile
audio or video player, a game console, a vehicle-mounted computer,
or a Global Positioning System (GPS), or the like. Computer system
1000 may also be connected to other devices that are not
illustrated, or may operate as a stand-alone system. In addition,
the functionality provided by the illustrated components may in
some embodiments be combined in fewer components or distributed in
additional components. Similarly, in some embodiments, the
functionality of some of the illustrated components may not be
provided or other additional functionality may be available.
[0136] Those skilled in the art will also appreciate that while
various items are illustrated as being stored in memory or on
storage while being used, these items or portions of them may be
transferred between memory and other storage devices for purposes
of memory management and data integrity. Alternatively, in other
embodiments some or all of the software components may execute in
memory on another device and communicate with the illustrated
computer system via inter-computer communication. Some or all of
the system components or data structures may also be stored (e.g.,
as instructions or structured data) on a computer-accessible medium
or a portable article to be read by an appropriate drive, various
examples of which are described above. In some embodiments,
instructions stored on a computer-accessible medium separate from
computer system 1000 may be transmitted to computer system 1000 via
transmission media or signals such as electrical, electromagnetic,
or digital signals, conveyed via a communication medium such as a
network or a wireless link. Various embodiments may further include
receiving, sending, or storing instructions or data implemented in
accordance with the foregoing description upon a
computer-accessible medium. Accordingly, the present invention may
be practiced with other computer system configurations.
[0137] To mitigate the problems described herein, the applicants
had to both invent solutions and, in some cases just as
importantly, recognize problems overlooked (or not yet foreseen) by
others in the field. Indeed, applicants wish to emphasize the
difficulty of recognizing those problems that are nascent and will
become much more apparent in the future should trends in industry
continue as applicants expect. Further, because multiple problems
are addressed, it should be understood that some embodiments are
problem-specific, and not all embodiments address every problem
with traditional systems described herein or provide every benefit
described herein. That said, solutions to many of these problems
are described above.
[0138] In block diagrams, illustrated components are depicted as
discrete functional blocks, but embodiments are not limited to
systems in which the functionality described herein is organized as
illustrated. The functionality provided by each of the components
may be provided by software or hardware modules that are
differently organized than is presently depicted, for example such
software or hardware may be intermingled, conjoined, replicated,
broken up, distributed (e.g. within a data center or
geographically), or otherwise differently organized. The
functionality described herein may be provided by one or more
processors of one or more computers executing code stored on a
tangible, non-transitory, machine readable medium. In some cases,
third party content delivery networks may host some or all of the
information conveyed over networks, in which case, to the extent
information (e.g., content) is said to be supplied or otherwise
provided, the information may provided by sending instructions to
retrieve that information from a content delivery network.
[0139] The reader should appreciate that the present application
describes several inventions. Rather than separating those
inventions into multiple isolated patent applications, applicants
have grouped these inventions into a single document because their
related subject matter lends itself to economies in the application
process. But the distinct advantages and aspects of such inventions
should not be conflated. In some cases, embodiments address all of
the deficiencies noted herein, but it should be understood that the
inventions are independently useful, and some embodiments address
only a subset of such problems or offer other, unmentioned benefits
that will be apparent to those of skill in the art reviewing the
present disclosure. Due to costs constraints, some inventions
disclosed herein may not be presently claimed and may be claimed in
later filings, such as continuation applications or by amending the
present claims. Similarly, due to space constraints, neither the
Abstract nor the Summary of the Invention sections of the present
document should be taken as containing a comprehensive listing of
all such inventions or all aspects of such inventions.
[0140] It should be understood that the description and the
drawings are not intended to limit the invention to the particular
form disclosed, but to the contrary, the intention is to cover all
modifications, equivalents, and alternatives falling within the
spirit and scope of the present invention as defined by the
appended claims. Further modifications and alternative embodiments
of various aspects of the invention will be apparent to those
skilled in the art in view of this description. Accordingly, this
description and the drawings are to be construed as illustrative
only and are for the purpose of teaching those skilled in the art
the general manner of carrying out the invention. It is to be
understood that the forms of the invention shown and described
herein are to be taken as examples of embodiments. Elements and
materials may be substituted for those illustrated and described
herein, parts and processes may be reversed or omitted, and certain
features of the invention may be utilized independently, all as
would be apparent to one skilled in the art after having the
benefit of this description of the invention. Changes may be made
in the elements described herein without departing from the spirit
and scope of the invention as described in the following claims.
Headings used herein are for organizational purposes only and are
not meant to be used to limit the scope of the description.
[0141] As used throughout this application, the word "may" is used
in a permissive sense (i.e., meaning having the potential to),
rather than the mandatory sense (i.e., meaning must). The words
"include", "including", and "includes" and the like mean including,
but not limited to. As used throughout this application, the
singular forms "a," "an," and "the" include plural referents unless
the content explicitly indicates otherwise. Thus, for example,
reference to "an element" or "an element" includes a combination of
two or more elements, notwithstanding use of other terms and
phrases for one or more elements, such as "one or more." The term
"or" is, unless indicated otherwise, non-exclusive, i.e.,
encompassing both "and" and "or." Terms describing conditional
relationships, e.g., "in response to X, Y," "upon X, Y,", "if X,
Y," "when X, Y," and the like, encompass causal relationships in
which the antecedent is a necessary causal condition, the
antecedent is a sufficient causal condition, or the antecedent is a
contributory causal condition of the consequent, e.g., "state X
occurs upon condition Y obtaining" is generic to "X occurs solely
upon Y" and "X occurs upon Y and Z." Such conditional relationships
are not limited to consequences that instantly follow the
antecedent obtaining, as some consequences may be delayed, and in
conditional statements, antecedents are connected to their
consequents, e.g., the antecedent is relevant to the likelihood of
the consequent occurring. Statements in which a plurality of
attributes or functions are mapped to a plurality of objects (e.g.,
one or more processors performing steps A, B, C, and D) encompasses
both all such attributes or functions being mapped to all such
objects and subsets of the attributes or functions being mapped to
subsets of the attributes or functions (e.g., both all processors
each performing steps A-D, and a case in which processor 1 performs
step A, processor 2 performs step B and part of step C, and
processor 3 performs part of step C and step D), unless otherwise
indicated. Further, unless otherwise indicated, statements that one
value or action is "based on" another condition or value encompass
both instances in which the condition or value is the sole factor
and instances in which the condition or value is one factor among a
plurality of factors. Unless specifically stated otherwise, as
apparent from the discussion, it is appreciated that throughout
this specification discussions utilizing terms such as
"processing," "computing," "calculating," "determining" or the like
refer to actions or processes of a specific apparatus, such as a
special purpose computer or a similar special purpose electronic
processing/computing device.
[0142] The present techniques will be better understood with
reference to the following enumerated embodiments:
1. A method, comprising: receiving, with one or more processors,
from a plurality of remote wireless computing devices of users,
logged reports of previous impaired or failed attempts by the
wireless computing devices to wirelessly access content while in a
geographic area, the logged reports being received after the
plurality of remote wireless computing devices regain wireless
connectivity; determining that an amount of the impaired or failed
attempts exceeds a threshold; in response to the determination,
designating, with one or more processors, the geographic area as
having poor wireless connectivity with a cache geofence in which
offers corresponding to the area are to be predictively loaded into
cache memory of computing devices entering the area before a user
requests the offers or the user is at a geolocation within the
cache geofence at which the offers are targeted; receiving, with
one or more processors, from a given computing device of a given
user, a geographic location of the given computing device and a
request for geofences corresponding to the geographic location; in
response to the request for geofences, sending the cache geofence
to the given computing device; after sending the cache geofence,
receiving, with one or more processors, from the given computing
device, another request indicating the given user device is within
the cache geofence; in response to the other request, sending, with
one or more processors, the given computing device offers to be
predictively loaded into cache memory of the given computing device
but not presented to the user until other conditions occur; after
the user is presented with at least some of the cached offers
without successfully using wireless connectivity, and after the
given computing device regains wireless connectivity, receiving,
with one or more processors, a logged record from the given
computing device indicating which offers were presented to the user
including offers presented during the loss of wireless
connectivity; and storing, with one or more processors, metrics of
at least some of the presented offers based on the received logged
record. 2. The method of embodiment 1, wherein: determining that
the amount of the impaired or failed attempts exceeds a threshold
comprises calculating the threshold based on an amount of user
requests for content, including successful request for content,
while in the geographic area; the geographic location is external
to the cache geofence when the request for geofences is received;
sending offers to be predictively loaded into cache memory
comprises sending offers associated with different portions of the
cache geofence, wherein at least a first one of the offers is
associated with a first location in the cache geofence, and at
least a second one of the offers is associated with a second
location in the cache geofence that is different from the first
location; and receiving a logged record comprises receiving an
indication that the first one of the offers was presented to the
user and that the second one of the offers was not presented to the
user. 3. The method of any of embodiments 1-2, wherein: at least
some of the logged reports identify a cellular carrier and a
requested offer for which access was impaired or failed;
determining that the amount of the impaired or failed attempts
exceed a threshold comprises: selecting a subset of the logged
reports based on the selected subset being associated with a given
cellular carrier; and determining that an amount of impaired or
failed attempts among the subset of logged reports exceed a
threshold for the given carrier; designating the geographic area
with a cache geofence comprises designating the geographic area
with a cache geofence associated with the given carrier; receiving
a request for geofences corresponding to the geographic location
comprises receiving an identifier of the given carrier; and sending
the cache geofence to the given computing device comprises
selecting the cache geofence based on the identifier of the given
carrier corresponding to the association of the cache geofence with
the given carrier. 4. A method, comprising: receiving, with one or
more processors, from a remote user computing device, a geographic
location of the user computing device; determining that the user
computing device is in a cache geographic area in which information
about potentially relevant geographically-targeted offers is to be
predictively loaded into memory of the user computing device before
the user requests the information about geographically-targeted
offers; selecting, with one or more processors, an offer from a
repository of offers based on the selected offer being associated
with the cache geographic area or a location in the cache
geographic area; and in response to the determination, sending,
with one or more processors, the selected offer to the user
computing device for storage in cache memory of the user computing
device before the user requests the selected offer. 5. The method
of embodiment 4, wherein: receiving a geographic location of the
user computing device comprises receiving an identifier of a
geofence previously sent to the user computing device, the
identifier being received after the user computing device
determines that the user computing device is within the geofence,
and determining that the user computing device is in a cache
geographic area comprises determining that the geofence is a cache
geofence based on a designation of the geofence associated with the
received identifier. 6. The method of any of embodiments 4-5,
wherein: receiving a geographic location comprises receiving data
by which a cellular carrier of the user computing device is
identified; the method further comprising: determining that the
cellular carrier corresponds to the cache geographic area, wherein
the cache geographic area does not correspond to other cellular
carriers of other user devices. 7. The method of any of embodiments
4-6, wherein: receiving a geographic location comprises receiving
data by which a mobile device model of the user computing device is
identified; the method further comprising: determining that the
mobile device model corresponds to the cache geographic area,
wherein the cache geographic area does not correspond to other
mobile device models of other user devices. 8. The method of any of
embodiments 4-7, wherein sending the selected offer comprises:
sending content describing the selected offer, wherein the content
describing the selected offer is smaller than content that is sent
when another user requests the same offer outside of the context of
a request to cache content. 9. The method of any of embodiments
4-8, wherein sending the offer comprises: obtaining a bar code
number and a bar code type of the offer; and sending the bar code
number and the bar code type to the user computing device without
sending an image of the bar code, wherein the bar code number and
bar code type are sent in a format that, when input into a bar code
image generation routine executing on the user computing device,
cause the bar code image generation routine to generate an image of
the bar code for presentation on the user computing device. 10. The
method of any of embodiments 4-9, wherein selecting the offer
comprises: selecting a plurality of offers, including the offer,
based on a record of offers previously redeemed by other users in
the cache geographic area or based on a record of offers previously
redeemed by the user. 11. The method of any of embodiments 4-10,
comprising: before receiving the geographic location, profiling a
plurality of geographic areas as having inadequate wireless
connectivity based on reports from a plurality of other user
devices indicating failed attempts to access content related to
offers while in respective ones of the plurality of geographic
areas, and creating at least part of the cache geographic area in
response to the profiling. 12. The method of any of embodiments
4-11, sending the selected offer comprises: obtaining a plurality
of application program interface (API) request responses, at least
one of the responses including the offer, at least some of the
responses including a plurality of offers responsive to the
respective API request; associating a description of each API
request with the respective response; and sending the composed
responses, the description of each API request, and the association
between the description of each API request and the respective
response to the user computing device. 13. The method of any of
embodiments 4-12, wherein: the selected offer is a single-use offer
having a unique single-use offer code corresponding to an instance
of the single-use offer and different from other instances of the
single-use offer; the method comprises: after selecting the offer,
designating, in memory, the instance of the single-use offer as
reserved, but not redeemed; and receiving a request for the
single-use offer from a different user computing device; and
sending one of the other instances of the single-use offer to the
different user computing device in response to the instance of the
single-use offer being designated as reserved. 14. The method of
any of embodiments 4-13, wherein: the selected offer is a
single-use offer having a single-use offer code corresponding to an
instance of the single-use offer and different from other instances
of the single-use offer; the method comprises: after selecting the
offer, designating, in memory, the instance of the single-use offer
as reserved; and after sending the selected offer, receiving an
indication from the user computing device that the single-use offer
was not redeemed; receiving an indication from the user computing
device that the single-use offer was removed or expired from cache
memory; and in response to at least one of the indications,
designating the single-use offer as not being reserved. 15. The
method of any of embodiments 4-14, comprising: after sending the
selected offer, and after losing and then regaining a network
connection with the remote user computing device, receiving a
report indicating whether the offer was presented to the user while
the network connection was lost. 16. The method of any of
embodiments 4-15, comprising: receiving request from the mobile
device for offers when the mobile device has wireless connectivity;
and sending one or more offers to the mobile device in response to
the request. 17. A tangible, non-transitory, machine-readable
medium storing instructions that when executed by a data processing
apparatus cause the data processing apparatus to effectuate the
operations of any of embodiments 1-16. 18. A system, including: one
or more processors; and memory storing instructions that when
executed by at least some of the processors cause the processors to
effectuate the operations of any of embodiments 1-16.
* * * * *