US20210150578A1

US20210150578A1 - Caching geolocated offers

Info

Publication number: US20210150578A1
Application number: US17/064,676
Authority: US
Inventors: Alexander M. Cheng; Jeffrey R. Rego; J. Seth Randle
Original assignee: RetailMeNot Inc
Current assignee: RetailMeNot Inc
Priority date: 2014-03-22
Filing date: 2020-10-07
Publication date: 2021-05-20
Also published as: US20190172097A1; WO2015148213A1; US20150269624A1; EP3123432A4; EP3123432A1; AU2015236575A1; US10229434B2; CA2943118A1; US10984451B2

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.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

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

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

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

The following is a non-exhaustive listing of some aspects of the present techniques. These and other aspects are described in the following disclosure.
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.
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.
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

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:

FIG. 1 shows an embodiment of an offer distribution system and consumer mobile devices configured to distribute and predictively cache geolocated offers;

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;

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;

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;

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;

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;

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

FIG. 8 shows an example of a computer system that may be used to implement some or all of the components described herein.

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

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™) 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.
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.
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.
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.
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.
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™ 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™ 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.
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.
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.
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.
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.
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).
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.
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.
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.
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²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²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²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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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™ interface for identifiers of Bluetooth™ 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.
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.
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.
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.
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™ 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™ 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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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.
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.
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.
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.
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.
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.
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.
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™, 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.
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.
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™ 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™ connections before the threshold.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.)
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.
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.
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.
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™ connection, a Wi-Fi Connection™, 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Computing system 1000 may include one or more processors (e.g., processors 1010 a-1010 n) 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 1010 a), or a multi-processor system including any number of suitable processors (e.g., 1010 a-1010 n). 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.
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.
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.
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 1010 a-1010 n) 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.
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 1010 a-1010 n) 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).
I/O interface 1050 may be configured to coordinate I/O traffic between processors 1010 a-1010 n, 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 1010 a-1010 n). 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.

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:

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:

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

41. The system of claim 36, wherein selecting the offer comprises:

42. The system of claim 36, the operations comprising:

43. The system of claim 36, sending the selected offer comprises:

associating a description of each API request with the respective response; and

44. The system of claim 36, wherein:

the operations comprise:

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.