Abstract:
A computer system processes a message from a user mobile device by receiving the message from the user mobile device, wherein the message comprises a purchase request, and then determining a matching purchase offer in a database containing a plurality of purchase offers, wherein the matching purchase offer corresponds to an offer identified in the purchase request. The system then transmits a purchase request to a purchase agent at a third party provider that is associated with the matching purchase offer, and processing a purchase transaction received from the purchase agent at the third party provider.

Description:
CROSS-REFERENCE TO RELATED APPLICATIONS 
       [0001]    This application claims priority of co-pending U.S. Provisional Patent Application Ser. No. 61/664,743 entitled “Offers System” by Jeremy Handcock, Benjamin Goldfarb, Damon Lanphear, Rodrick Megraw, Preethi Ramani, Dan Yi, Curtis Allred, filed Jun. 26, 2012. Priority of the filing date of Jun. 26, 2012 is hereby claimed, and the disclosure of the Provisional Patent Application is hereby incorporated by reference. 
     
    
     BACKGROUND 
       [0002]    It is known to deliver commercial offers, such as discount offers or coupons, to mobile users. For example, Groupon, Inc. (“Groupon”) provides an application that may be installed on mobile platforms such as tablet computers and smart telephones. In cooperation with merchants and affiliates, the Groupon application sends discount offers to subscribers of the application. 
         [0003]    The merchants and affiliates develop offers and coupons with Groupon for sending to the Groupon subscribers. A subscriber provides Groupon with information such as geographic location, gender, and age, as well as email address. From this information, Groupon can determine which offers should be sent to the subscribed user according to a user&#39;s location, gender, and/or age. Further information is available over the Internet at the Web site of groupon.com. Other applications for mobile platforms may push offers and coupons to subscribers, including applications such as The Dealmap, ShopSavvy, Tipper, Living Social, Nextag, Deal Force, and the like. 
         [0004]    The mobile applications provide links to commercial offers, which is a convenient means for users to be kept abreast of current opportunities for special purchases, but checking multiple sources of commercial offers can be inconvenient and cumbersome. Some services purport to aggregate multiple commercial offers from multiple sources, but typically redirect users to the various Websites of the respective vendors of the commercial offers. 
         [0005]    Although such applications are convenient for pushing out offers and coupons to subscribers of their respective applications, greater flexibility and customization are desirable. The present invention addresses this need. 
       SUMMARY 
       [0006]    Offers and coupons are accumulated and stored in a database for sending to registered users. Preferences are indicated by each user during the registration process and may be modified by the user afterwards. The offers and coupons to be pushed to users are determined in accordance with such self-reported preferences. For example, a user may prefer to receive offers that would otherwise be directed to persons not in the same geographic location, gender, or age group as the user. The offers and coupons may be accessed by third party network contacts. Thus, any application installed on a mobile platform that can access the database will be capable of pushing offers and coupons to registered users. Such in-application delivery increases the flexibility of delivering offers and coupons to a much wider audience. Such third party access may be achieved, for example, through an Application Program Interface (API). 
         [0007]    Other features and advantages of the present invention should be apparent from the following description of the preferred embodiments, which illustrate, by way of example, the principles of the invention. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0008]      FIG. 1  is a block diagram of an offers system constructed in accordance with this disclosure. 
           [0009]      FIG. 2  is an object model of the classes implemented to perform a transaction using the offers system illustrated in  FIG. 1 . 
           [0010]      FIG. 3  is a flow diagram that shows the purchase process performed by the  FIG. 1  system. 
           [0011]      FIG. 4  is a flow diagram that shows the purchase fulfillment process performed by the  FIG. 1  system. 
           [0012]      FIG. 5  is a block diagram that shows a data architectural overview of the offers system illustrated in  FIG. 1 . 
       
    
    
     DETAILED DESCRIPTION 
       [0013]      FIG. 1  shows an offers system as disclosed herein. The offers system  100  includes a common database (RDS)  102  that is accessed by multiple Offers Web Service nodes (OWS)  104 . The OWS nodes communicate with third party offers services. Several of the OWS nodes are identified with exemplary names such as Groupon, Tipper, Living Social, and BuyWithMe, for purposes of illustration only. These offers services sell the offer purchases that are bought by users, as described herein. The offers system  100  comprises a computer application that executes on a computer apparatus to manage data processing by the illustrated components of the system. Those skilled in the art will understand details of how an application may be executed on an operating system of a host computer apparatus. A purchase by a user is initiated by a user through a mobile device  106  that sends a purchase request that is identified as a “purchase()” request  108 , which is shown as being received at the offers system  100 . The user purchase request  108  is sent over a mobile communications network  110  and may comprise a message or other communication that is generated by a browser or similar network application executing on the user&#39;s mobile device  106 . Each of the respective OWS nodes  104  is responsible for placing the received purchase request  108  into a queue for processing and for executing a purchase in response to the purchase request. A “purchase order state” data record is stored in the database  102 . As the purchase request is processed, the purchase order state may be checked periodically, and updated, by any one of the OWS nodes. Each of the OWS nodes has access to the database  102 . The checking and updating of a purchase request need not be performed by the same OWS node that initiated the purchase request processing. The purchase request may be received at the offers system  100  by a load balancer  112  that functions as a network interface and will have knowledge of the processing workloads of the various OWS nodes  104 , and will direct a received purchase request  108  in accordance with rules for balancing the workloads of the OWS nodes. 
         [0014]    Processing of the offers system  100  ( FIG. 1 ) will be described with reference to  FIG. 2  and  FIG. 3 .  FIG. 2  is a class diagram that shows the object classes of the offers system application  100  ( FIG. 1 ) as implemented by the operating system of the offers system to perform a purchase transaction.  FIG. 3  shows a combined block diagram and flow diagram that illustrates the purchase process performed by the  FIG. 1  system. 
         [0015]    The PurchaseRequest object class  202  refers to the purchase request  108  ( FIG. 1 ) received from a user. A PurchaseAgent is an interface that the offers system uses to purchase an offer, as requested by a user. That is, a user who wants to utilize a “special offer” or other commercial offer of the system  100  must purchase the special offer to obtain the special circumstances. The PurchaseAgent Implementation  312  ( FIG. 3 ) is the class of object that performs the purchase of the special offer. The PurchaseAgent Implementation also checks on the fulfillment status of an offer purchase. The PurchaseAgent Implementation interface defines common inputs and outputs for two operations that are used uniformly regardless of the offer provider. 
         [0016]    The first operation is called “ExecutePurchase” and receives inputs comprising details on the offer being purchased, as well as user purchase card information, the item quantity for the offer purchase, and the user&#39;s account information at the remote provider (e.g., username, email address). The remote provider is typically a third party offers provider, such as the services  105  indicated in  FIG. 1  and noted as a service  314  in  FIG. 3 . The ExecutePurchase operation is a method of the PurchaseAgent Implementation class  312  in  FIG. 3 . The output of the ExecutePurchase operation is the status of the purchase transaction. If the purchase transaction is unsuccessful (e.g, due to a credit card being declined), then a message such as user-friendly error information is provided. 
         [0017]    The second operation of the PurchaseAgent is called “CheckFulfillment” and receives input comprising information to uniquely identify the user&#39;s offer purchase at the remote provider. The CheckFulfillment operation is a method of the PurchaseAgent Implementation class  312  in  FIG. 3 . The output of the CheckFulfillment operation is the status of the offer purchase fulfillment. If the purchase is successful, then the CheckFulfillment operation stores the voucher(s) issued by the offer provider so the user may redeem them in the mobile application via the API of the offers system. The user is notified in the mobile application that the offer is ready to be redeemed via the system&#39;s API. If the CheckFulfillment operation is unsuccessful, then a message such as a user-friendly error information is provided. 
         [0018]    The offers system application also includes a PurchaseAgentSource class, which provides an interface for creating an instance of a PurchaseAgent for a specific offer provider. The PurchaseAgentSource receives input of an identifier for a specific offer provider (e.g., ‘Tipp’) and produces output of an instance of PurchaseAgent for the requested provider. A User Registration process provides a method to create a new user. 
         [0019]    In  FIG. 2 , the PurchaseOrder  204  is an object that represents an order from a user to purchase an offer. The PurchaseOrder object contains information about the state of the purchase and fulfillment of the purchase, as well as a reference to the vouchers for this purchase. 
         [0020]    The Voucher object  206  is an object that can be used to redeem an offer. A voucher is issued by a third party remote offer provider and is stored in the offers database  102 . The StoredOfferSet  208  is an object that represents a collection of purchased offers that forms a “wallet” of the user. The StoredOffer object  210  represents a single wallet entry, and contains a reference to the Offer that was purchased and contains a reference to the PurchaseOrder object. The Offer object contains metadata about an offer from a third party remote offer provider. Exemplary fields of the Offer object include offer title, price, description, redemption locations, expiration date, redemption instructions, and details on the merchant making the offer. 
         [0021]      FIG. 3  shows a combined block diagram and flow diagram that illustrates the purchase process performed by the  FIG. 1  offers system. All of the operations illustrated in  FIG. 3  are performed at the offers system, comprising one or more computers performing the functions disclosed herein. The databases  301  indicated as being accessed by the Purchase Initiator  304  and Purchase Transactor  308  components can be located externally to the offers system computer, connected via computer networks. The process flows are numbered in  FIG. 3  according to the order in which the respective processes are performed. Thus, a user&#39;s request to purchase an offer (indicated by the “purchase()” method in  FIG. 3 ) is received by the system&#39;s HTTP API at the process marked “ 10 : Purchase Request” and the request  10  is eventually dispatched to the appropriate PurchaseAgent. The PurchaseAgent completes the purchase transaction and periodically checks the purchase fulfillment status at the 3rd-party offer provider  105  ( FIG. 1 ). The state of the purchase and its fulfillment is maintained in the database  102  ( FIG. 1 ). 
         [0022]    After the receiving of the purchase request at  10  at the Purchase Resource  302 , the next process occurs when the PurchaseResource  302  creates a PurchaseRequest data record at  20 , calls the Purchaselnitiator  304  for a submitPurchaseOrder( )method on the database to create a PurchaseOrder  25 , and the Purchaselnitiator creates and persists a StoredOffer  40  containing a new PurchaseOrder and null Voucher. Next, the Purchase Initiator  304  creates and persists a PurchaseTracker object  30  with state=NEW and sets timestamps accordingly. The PurchaseInitiator creates a PurchaseQueue.Entry  35  using the PurchaseRequest  10  and a PurchaseTracker ID from the Purchase Initiator  304 , placing an entry on a processing queue in the database. At the process  40 , the StoredOffer containing the PurchaseOrder is generated by the Purchase Initiator  304  and is returned to the Purchase Resource  302 . A PurchaseResource.purchase()method  55  of the Purchase Resource then returns the StoredOffer to the user. That process  55  concludes the acceptance and queuing process for the offer purchase request. 
         [0023]    At processing for dispatching a purchase task, a PurchaseQueue component  306  retrieves a next purchase queue entry  60  from the database  102 . If a queue entry exists, then the PurchaseQueue  306  creates a PurchaseTask  60  and submits it to a thread pool at the PurchaseTransactor  308 . If there is no queue entry, then the PurchaseQueue enters an idle state in which it “sleeps” or otherwise halts request processing for a predetermined time. This processing is repeated until the purchase queue is empty. 
         [0024]    Next, a PurchaseAgentRepository  310  requests processing by a PurchaseAgent from the PurchaseTransactor  308 . The requested PurchaseAgent will have a provider-specific implementation. At the process  70 , the PurchaseTracker state is updated to “IN_PROGRESS” and a corresponding timestamp is updated by the PurchaseTransactor  308 . At the process  80 , a PurchaseRequest is sent to a provider-specific Purchase Implementation  312 , which may retrieve the appropriately configured PurchaseAgent from a third party Website service  314 . At the process  90 , a response is received from the purchaser (i.e., the user). The next processing performed will depend on the results of sending the purchase request. At the process  100 , the entry is removed from the queue, to allow for a persistent queue with crash-safety plus retries of requests. At the process  110 , the PurchaseTracker is updated with purchase data and the PurchaseOrder state is updated to SUCCESS or FAILURE, depending on the outcome of processing, and the fulfillment state is updated to PENDING. At the process  120 , a FulfilimentTracker object is created with state set to PENDING if the purchase was successful. A voucher check period is also set, as well as a “next check time” for checking the PurchaseOrder status and a “give-up time” to limit the number of retries and provide a fail indication. 
         [0025]    The purchase requests are received at the offers system (e.g., Medio Systems) from a mobile application. The database is maintained at Medio Systems. A user of the mobile application  106  initiates the action to purchase the offer within the application, which creates a purchase()request to Medio Systems. The PurchaseAgent Implementation  312  makes an off-site request to the third-party  314  to purchase the offer on behalf of the user (who initiated the action to purchase the offer within the mobile application). 
         [0026]      FIG. 4  shows a combined block diagram and flow diagram that illustrates the purchase fulfillment (delivery) process performed by the  FIG. 1  system. All of the operations illustrated in  FIG. 4  are performed at the offers system, comprising one or more computers performing the functions disclosed herein. An entity database  401  is accessed by a Fulfillment Task Dispatcher component  402  and can be located externally to the offers system computer, connected via computer networks. The process flows are numbered in  FIG. 4  according to the order in which the respective processes are performed. Thus, a query for a voucher is generated by the Fulfillment Task Dispatcher  402  at the process  10  in  FIG. 4  and is stored in the database  401 . For each transaction being processed, a voucher query will be generated so that a voucher in the database having a state that is “PENDING” will be selected. A limited number of pending vouchers may be retrieved, for example, one at a time. 
         [0027]    A query for a voucher is performed in a Worker Task process created by the Fulfillment Task Dispatcher  402 , and contains a reference to a PurchaseOrder object. The PurchaseOrder object contains all of the information needed to associate a voucher query with a purchase request from a user. If the Worker Task returns a voucher from the third party remote offer provider  408 , the Fulfillment Task Dispatcher  402  will save the voucher information in a Voucher object. If a retrieved voucher matches a purchase request the FulfillmentTrackerState is updated to “IN_PROGRESS” and the StatusCheckTime value is set to the current time. If the remote offer provider  408  does not return a voucher (e.g., because the voucher has not yet been issued), then the Fulfillment Task Dispatcher  402  will stop its query operations and will go to a sleep state for a predetermined time before querying again. 
         [0028]    For processing a Worker Task, the start of the offers system processing is indicated at  30 , where a provider-specific implementation of a PurchaseAgent is retrieved from a Purchase Agent Repository  404  and is generated by a Purchase Agent Implementation  406 . The voucher status is checked by a Third Party Web Site  408  at the process  40  to invoke a check.PurchaseFulfillment( )method of the PurchaseAgent on the provider implementation. At the process  50 , the state of the voucher in the database is updated by the Fulfillment Task Dispatcher  402 . The state of the voucher will be set to READY is the voucher is ready for processing. The state will be set to PENDING if the voucher is not ready (i.e., a transaction error has occurred). The state will be set to ERROR if there has been a third party fulfillment error or it a predetermined time period for being in the PENDING state has lapsed. Processing then repeats for a next query. 
         [0029]    All the illustrated operations are performed at the offers system (e.g., Medio Systems) using the “Entity” database. The PurchaseAgent Implementation  406  issues an off-site request to the third-party  408  to purchase the offer on behalf of the user. The Entity DB is at Medio Systems. The only part of  FIG. 4  that occurs off-site is the request to the third-party  408  to purchase the offer on behalf of the user. 
         [0030]      FIG. 5  is a block diagram that shows a data architectural overview of the offers system illustrated in  FIG. 1 . The diagram shows the components of the system, and is similar to the depiction illustrated in  FIG. 1 . The system  500  shows third party offer providers  502  in which the PurchaseAgents and the Content Aggregator described above use the third party remote offer providers to collect information about the offers that are available and to execute purchases on those offers. 
         [0031]    The Medio Analytics Platform  504  shows that a Classifier takes offers collected by a Content Aggregation component and automatically labels the offers with appropriate categories by examining text data in each offer, such as the title and description. These category labels are used by a Real Time Predictive Analytics Engine to match offers to users using an Offer Relevance Ranking component, which takes into account user category preferences. The Local/Location Targeting component ranks offers according to how far they may be redeemed from the user&#39;s current location. The Location Targeting component takes into account the fact that some categories of offers may be “location sensitive”, meaning that the attractiveness or desirability of the offer may depend on user geographic location. For example, users may be willing to travel long distances to take advantage of a hotel offer, but they may only consider restaurant offers for a restaurant that is within a few miles from their current location. In this situation, offers geographically closer to the user are shown to the user before those that are further away. User activity events from the connected devices (e.g., clicks on offers, “Like” actions on offers, “buy” clicks on offers, purchases of offers, and the like) are provided to a User Activity Store to generate a User Profile for each user. The Real Time Predictive Analytics Engine uses the User Profile to determine what offers to show a given user and in what order to show the offers. 
         [0032]      FIG. 5  shows an Application Stack that comprises the Offers Web Service that is described further above, as is the Purchase Integration system. The Application Stack includes an Offer Presentation Layer, which is the HTTP API that sits on top of the Offers Web Service, as described in further detail above. 
         [0033]      FIG. 5  also shows Connected Devices, which may include any device that accesses the offers system via the API, as will be known to those skilled in the art from the description herein. The devices may include, for example, mobile devices that use an operating system such as “Android” by Google Inc., or the “iOS” client application by Apple Inc. The Offer Creation Web Console is described in further detail above. The Medio Client SDK is used to capture and log user activity events for processing and inclusion in the User Activity Store. 
         [0034]    The Offers Distributed System described herein delivers commercial offers, which may be coupons or pre-paid discount opportunities, to software applications on mobile devices from multiple heterogeneous sources. The offers may come from one or more providers of offers that are external to the system itself. The offers are aggregate and grouped according to their applicability to individual end-users according to the preferences, both implicit and explicit, of the users. One or more applications on mobile devices place requests to the system for new offers, specifying the user&#39;s identity. The system uses the user&#39;s identity to lookup the user&#39;s preferences and then requests a set of offers that are appropriate for that user from the universe of available offers according to algorithmically determined criteria. The offers are then presented to the user within the application. Once presented, the user may signal their disposition to the offer by purchasing, ignoring, rating, or sharing the offer. 
         [0035]    The system functions by integrating offers from two types of sources. The first is through an offer management system that allows business owners to create coupons of their own, along with a set of distinguishing properties such as store locations, target locations, discount amount, time limits, et al. The second is through a system of software agents that are configured to request the most recent offers from external offer providers. These offer providers have their own mechanisms for sourcing or creating offers. Once the offers are in the system that are also recorded for posterity and future analysis in a data storage mechanism designed to support batch processing of the offer data. The offers are also stored in a database that has been designed to support the targeting of offers to users according to user preferences. 
         [0036]    Users register to the system. At registration time each user is given a unique identifier. The users are also asked to complete a survey that allows them to specify their preferences, age, location, and gender. This information is stored in a database that is designed to retain user information. 
         [0037]    The system provides an Application Programming Interface (API) which is accessible via HTTP. This interface may be queried from any application in which offers may be embedded. The interface is designed specifically, however, for integration in mobile clients taking into account the need for efficient use of network bandwidth, the availability of the users&#39; locations and other mobile-specific considerations when mobile applications communicate with the API. 
         [0038]    A mobile client application has been designed and implemented that calls the API via HTTP to register the user and retrieve offers. The system selects offers that are most relevant for the user based on the user&#39;s location, interests, as well as attributes of the offer that determine the offer&#39;s popularity. The user is presented the offers in a format that supports the rapid viewing and inspection of the details of each offer. Offers may contain both text and images to describe the offer. Some offers may also be presented through rich media, such as video or audio. 
         [0039]    Users are provided the ability to rate an offer, purchase an offer, or ignore an offer. Each of these actions are recorded and used in the analysis of user disposition to an offer which in turn will influence the relevancy ranking of offers returned to users on subsequent requests to the system. If the user elects to purchase or keep an offer then the system will conduct the purchase transaction on behalf of the user and store the offer in a “wallet” that is maintained on the server side of the system. 
         [0040]    When the user is ready to use the offer at a point of sale the user the user can use the same mobile application to present a stored offer to the cashier. The use of the offer is likewise recorded by the system. 
         [0041]    Finally, the system supports reporting on the performance and aggregate user disposition towards offers. 
         [0042]    Problems Solved in the Present Invention Not Addressed in the Prior Art 
         [0043]    The following features represent solutions to difficulties experienced with many conventional offers processing systems. 
         [0044]    1. Automated collection of offers from multiple remote offer providers. 
         [0045]    2. Long term storage of collected offers for use in analysis. 
         [0046]    3. The ability to search and browse the collected offers based on multiple facets. 
         [0047]    4. Automated classification of offers using unstructured text in the offer. 
         [0048]    5. Targeting of offers to individuals based on configured preferences. 
         [0049]    6. Storage and management of offers in a wallet managed by individual users. 
         [0050]    7. The ability to integrate offers submitted to the system editorially alongside offers collected from remote providers. 
         [0051]    8. The ability to target offers by location and differentiate between the current location and home location of the user. 
         [0052]    9. Integration with mobile devices. 
         [0053]    10. The ability to integrate offers via an Application Programming Interface (API) to any application. 
         [0054]    11. Usage of an offer stored in a mobile wallet at a point of sale. 
         [0055]    12. The ability to transact on the offer within the mobile application. 
         [0056]    13. The ability to signal the disposition toward the offer, whether positive, negative or a rating to the service for use in future targeting. 
         [0057]    14. The ability to target offers based on user disposition gathered from previous presentation of an offer. 
         [0058]    15. The ability to report on and analyze the performance and user disposition toward offers. 
         [0059]    16. The ability to classify arbitrary offers from 3rd parties into a common set of categories. 
         [0060]    17. The ability to target offers based on user demographic attributes. 
         [0061]    18. The ability to target offers based on user&#39;s current location and long-term location. 
         [0062]    19. The ability to deliver different offers to different users for the purposes of multivariate testing 
         [0063]    20. The ability to report results of multivariate tests in real time. 
         [0064]    21. The ability to target offers based on collaborative filtering. 
         [0065]    22. Location-driven targeting that takes into account the sensitivity of distance to redemption location by offer category. 
         [0066]    23. Purchase transaction processing and fulfillment of offers from multiple remote providers. 
         [0067]    24. Analytically-driven targeting that uses a combination of gender-based popularity, overall popularity, and velocity-based popularity. 
         [0068]    This disclosure includes the attached appendix entitled “Offers Purchase Transaction Design”, the contents of which are incorporated by reference.