LOCALIZED FACILITY-SPECIFIC PRESENTATION OF DIGITAL TEMPORARY OFFER DATA AND DETAILS

A portion of the disclosure of this patent document contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent document or the patent disclosure, as it appears in the Patent and Trademark Office patent file or records, but otherwise reserves all copyright or rights whatsoever. © 2020-2021 Quotient Technology Inc.

TECHNICAL FIELD

One technical field of the present disclosure is computer-implemented selection and presentation of digital data based upon automatically determined selection criteria. Another technical field is the selection and presentation of digital data to mobile computing devices based upon location and time.

BACKGROUND

The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.

In some domains, the vast amount of available digitally stored data poses acute challenges in determining what data to select and present to a particular end-user since human capabilities for managing the data are limited. Large, complex, and feature-rich distributed computer systems and software have been developed to solve the problem of selecting digital data that is relevant to a particular end-user, end-user account, or end-user computer that is located in a particular place at a particular time.

For example, advertising technology or adtech is the technical field of storing large datasets relating to products or services available for consumer purchase, receiving orders asserting how to present selected data, selecting a small subset of the data for presentation to a particular end-user, end-user account, or end-user computer, and transmitting the selected data. Although adtech indirectly achieves certain business goals, such as inducing consumer purchases of a particular product, the means that are used are purely technical. Deployment of adtech in practical applications to solve data selection and presentation problems has required the practical application of mathematics and computer science to programming of complex distributed computer systems to achieve real-time response, conduct searches of large data repositories, collect digitally stored data, and transform the data into new datasets that have not previously existed.

Some of the data stored in the repositories may state or represent temporary price reduction (TPR) offers of manufacturers, sellers, or brands of consumer packaged goods (CPGs). TPR offers differ from other digital offers in having at least three limitations; they relate to a subset of brands or products; they are offered for a limited time; and they apply to a limited geographical area, typically selected physical or online retail sites. Existing adtech systems are unable to process digital TPR offers or have serious limits in distributing them. There is a need for a fully automated, computer-implemented, scalable system that is capable of selecting and presenting TPR offers to a particular end-user, end-user account, or end-user computer, and transmitting the selected offers in real-time in response to a transaction or other event and based upon automatically determined constraints.

SUMMARY

The appended claims may serve as a summary of the invention.

BRIEF DESCRIPTION OF THE DRAWINGS

In the drawings:

FIG. 1A illustrates a distributed computer system showing the context of use and principal functional elements with which one embodiment could be implemented.

FIG. 1B illustrates one embodiment of a process of selecting and transmitting TPR offers.

FIG. 2 illustrates one embodiment of algorithms for defining and transmitting TPR offers.

FIG. 3A illustrates further details of a campaign assembly algorithm and ad serving algorithm, according to one embodiment.

FIG. 3B illustrates data values that may serve as input, and may be calculated, to create a campaign in one embodiment.

FIG. 3C illustrates the interoperation of the databases, files and mappings shown in FIG. 1 at different stages of processing as described above.

FIG. 4A illustrates data parameters that may be stored in a campaign definition (FIG. 1) for the specified example.

FIG. 4B graphically illustrates the delivery of flights of TPR offers and the corresponding impact on budget consumption.

FIG. 5 illustrates an example set of digital images that may be used in an embodiment.

FIG. 6 illustrates an example creative area that may be used in an embodiment.

FIG. 7 illustrates an example set of creative areas that may be used with dynamic price integration in an embodiment.

FIG. 8 illustrates an example creative area that may be used in an embodiment.

FIG. 9 illustrates an example creative area that may be used with dynamic price integration in an embodiment.

FIG. 10 illustrates a computer-implemented process with which one embodiment could be implemented without dynamic price integration.

FIG. 11 illustrates a computer system with which one embodiment could be implemented.

DETAILED DESCRIPTION

In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.

The text of this disclosure, in combination with the drawing figures, is intended to state in prose the algorithms that are necessary to program a computer to implement the claimed inventions, at the same level of detail that is used by people of skill in the arts to which this disclosure pertains to communicate with one another concerning functions to be programmed, inputs, transformations, outputs and other aspects of programming. That is, the level of detail set forth in this disclosure is the same level of detail that persons of skill in the art normally use to communicate with one another as a starting point to express algorithms to be programmed or the structure and function of programs to implement the inventions claimed herein.

FIG. 1A, and the other drawing figures and all of the description and claims in this disclosure, are intended to present, disclose and claim a technical system and technical methods in which specially programmed computers, using a special-purpose distributed computer system design, execute functions that have not been available before to provide a practical application of computing technology to the problem of TPR offer definition, selection, and transmission. In this manner, the disclosure presents a technical solution to a technical problem, and any interpretation of the disclosure or claims to cover any judicial exception to patent eligibility, such as an abstract idea, mental process, method of organizing human activity or mathematical algorithm, has no support in this disclosure and is erroneous.

FIG. 1B, FIG. 2 and each other flow diagram herein is intended as an illustration at the functional level at which skilled persons, in the art to which this disclosure pertains, communicate with one another to describe and implement algorithms using programming. The flow diagrams are not intended to illustrate every instruction, method object or sub-step that would be needed to program every aspect of a working program, but are provided at the same functional level of illustration that is normally used at the high level of skill in this art to communicate the basis of developing working programs.

Embodiments are described in sections below according to the following outline:

1. General Overview

2. Structural & Functional Overview

- 2.1 Example Distributed Computer System
- 2.2 Overview of Selecting and Transmitting TPR Offers
- 2.3 Campaign Assembly; Ad Serving

3. Implementation Example—Hardware Overview

1. General Overview

In one embodiment, a computer-implemented method comprises, by an offer server computer system: receiving and digitally storing a first digital image file; receiving and digitally storing a first mapping of product code values to audience segment identifiers; receiving and digitally storing a temporary price reduction (TPR) offer dataset; programmatically mapping a target identifier, which is associated with an end-user computing device that is associated with a prospective consumer, to an audience segment identifier; in response to determining, based on the audience segment identifier, that the TPR offer dataset comprises a particular record that includes a particular product code and a particular retailer identifier that map to the audience segment identifier, and includes an effective date value that includes a current date value corresponding to a current date, and that the particular retailer identifier corresponds to a retailer location that is within a specified geographical distance of a then-current location of the end-user computing device: creating and storing a digital offer dataset comprising both the first digital image file and a second digital image file that presents one or more data elements of the TPR offer dataset; causing transmission of the digital offer dataset toward the end-user computing device.

In one feature, the method further comprises receiving device location data specifying a then-current location of the end-user computing device and determining that the device location data is within a specified physical radius of a particular retailer that is identified in the TPR offer dataset. In another feature, the method further comprises executing the determining, the creating and storing, and the transmitting only in response to determining that the location data is within a specified geographical radius of a particular retailer having opening hours that include a then-current time of day that is local to the end-user computing device. In a further feature, the method comprises executing the determining, the creating and storing, and the transmitting only in response to determining that the location data is within a specified geographical radius of a particular retailer for which local weather conditions match specified conditions of use of the particular product in the TPR offer dataset.

In yet another feature, the audience segment identifiers are generated based on a plurality of digital data received from one or more retailers and identifying particular products that were previously purchased at points of sale in association with purchaser identifiers. In another feature, the TPR offer dataset comprises a plurality of digital records of offers, each of the digital records comprising an association of at least location data specifying a location of a retailer, a start date value and an end date value of an effective period, a product identifier, and a temporarily reduced price.

In still another feature, the method further comprises reading, from the particular record of the TPR offer dataset, a particular reduced-price value of the particular product; obtaining, from a local retail price data source, a then-current local price value of the same particular product; performing the creating and storing, and the transmitting, only when the particular reduced-price value is less than the then-current local price value. In another feature, the product codes comprise any of UPC values or GTIN values. In yet another feature, the target identifier comprises a loyalty identifier that is obtained at a point of sale computer and transmitted to the offer server computer system.

Other aspects, features, and embodiments will become apparent from the other description, drawings, and claims of this disclosure.

2. Structural & Functional Overview

2.1 Example Distributed Computer System

FIG. 1A illustrates a distributed computer system showing principal data sources and data flows with which one embodiment could be implemented. In an embodiment, an offer server computer system 100 is coupled directly or indirectly via one or more networks 140 to any number of end-user computing devices 150 and any number of point of sale computers or systems 160. Offer server computer system 100 may be implemented as a single-processor computer, multiple computers, a cluster, and/or one or more virtual computing instances in a private datacenter or a third-party cloud computing system or datacenter.

Digitally stored data sources that support the embodiments described herein generally include a product master database to enable confirming the existence of a particular product; a TPR offer list received from a retailer and specifying product codes, offer time ranges, and product descriptions; a mapping of product codes to product category to an audience identifier; and, in some embodiments, a mapping of retailers to targeting list identifiers for use in demand-side platforms (DSPs).

Accordingly, in one embodiment, the offer server computer system 100 comprises a master product database 102, TPR offer file 104, product code audience mapping 106, retailer target mapping 108, campaign definition 110, campaign assembly instructions 120, data transmitting instructions 130, and POS transaction logs 162. Each of the master product database 102, TPR offer file 104, product code audience mapping 106, retailer target mapping 108, campaign definition 110, and POS transaction logs 162 comprises a digitally stored data in one or more tables, files, mappings, or other digital data structures. Each of the campaign assembly instructions 120 and data transmitting instructions 130 comprises stored program instructions for CPUs or other hardware processors of the offer server computer system 100. In some embodiments, one or more of master product database 102, TPR offer file 104, product code audience mapping 106, retailer target mapping 108, campaign definition 110 may be stored in or managed by other systems to which the offer server computer system 100 is communicatively coupled. For example, the master product database 102 may be part of an external system.

In an embodiment, the master product database 102 is a digital data storage repository that stores records of individual products, such as consumer packaged goods (CPG) items in which a product identifier is a key or column attribute that can be searched using queries or programmatic calls that are submitted to the database. The terms product identifier and product code are interchangeable, and examples include Universal Price Code (UPC) values or Global Trade Item Number (GTIN) values. In an embodiment, as further described in other sections, to confirm the validity of a particular product identifier that is identified in a record of the TPR offer file, and for other purposes, one or more of the campaign assembly instructions 120 and data transmitting instructions 130 may be programmed to query the master product database 102 to confirm the existence of the referenced product. In some embodiments, one or more of the campaign assembly instructions 120 and data transmitting instructions 130 may be programmed to, in response to failure to confirm the product identifier in the product code audience mapping 106, to query whether the product identifier exists based on the master product database 102 and to update the product code audience mapping.

In one embodiment, a TPR offer dataset comprising a plurality of digital records of offers, each of the digital records comprising an association of at least location data specifying a location of a retailer, a start date value and an end date value of an effective period of a temporary price reduction, a product identifier for the product subject to a TPR, and a temporarily reduced price value. In an embodiment, TPR offer file 104 comprises a plurality of rows each having column values for product identifiers, offer time range such as start and end dates, a product description suitable for communication to a consumer in an offer, and a sell price. Other embodiments may include other column values or attributes.

The TPR offer file 104 comprises a dataset of records that identify TPR offers that is prepared externally at computers associated with retailers or brands and transmitted over an internetwork to the offer server computer system 100 for local storage and use. The TPR offer file 104 may be received periodically, such as weekly, to replace any prior copy or version of the file.

TPR offer file 104 comprises an association of data that has been unavailable in prior systems. TPR offers usually have a short duration, are different in each retailer, are dependent upon inventory available at the retailer, dependent upon the geography, and have different prices based on any of the foregoing attributes. Using TPR offer files 104 having the data attributes described herein, campaign assembly instructions 120 and data transmitting instructions 130 may be programmed to generate and output digital offer files that specify, at a specific time and place, a reduced price for a specific product that is accurately available at a particular local retailer. Importantly, specific offers can be generated and transmitted only during a specific limited period of time. Furthermore, the resulting digital offer files that can be transmitted to mobile devices are different than previously available ad units or other digital offers because they reflect time-limited TPR offers for specific products and identify a particular retailer, local to the end-user device to which the unit or offer is served, at which the TPR is known to be in effect.

In an embodiment, product code audience mapping 106 comprises a digitally stored association of data that maps product identifiers to product category values to audience identifiers. In an embodiment, the audience identifiers specify an audience segment that has been created and managed in a separate programmatic advertising placement system. A commercial example of the programmatic advertising placement system is UBIMO, but other embodiments may use other demand-side platforms.

In an embodiment, the retailer target mapping 108 comprises a digitally stored association of data that maps retailer identifiers to targeting list identifiers of the programmatic advertising placement system.

In an embodiment, campaign definition 110 is an association of digitally stored values that define instructions to transmit offers to end-users, end-user computers or accounts in a specified manner. In this context, a “campaign” may refer to a long-term agreement to request and pay for advertising units defined by digitally stored data specifying products, audience, scale of reach, publishers, timing and frequency, and creative elements. Other embodiments may define a campaign using other sets of stored data elements.

Campaigns may be divided into orders, flights or other sub-units that are effective for shorter periods of time, such as a few weeks, and represented in discrete digital datasets for each unit. In one example, a campaign object or campaign row in the campaign definition 110 comprises a product identifier, a budget value, a time value specifying an estimated number weeks during which the offer is available, a start date and end date, and one or more digital image files or network references such as a URLs specifying one or more digital images to serve in advertising units. In one embodiment, the digital image files comprise both a product image and a retailer image such as a store banner to specifically identify a retailer that is local to the target end-user, account, or computer.

POS transaction logs 162 may be received asynchronously with respect to any of the processes described herein from any number of point of sale computers or systems 160. POS transaction logs 162 report basket-level product identifier, for specific products and transactions of end-users as identified by loyalty card identifiers, phone numbers, or other user identifiers that retailers collect voluntarily from end-users or consumers. POS transaction logs 162 provide a basis for mapping loyalty identifiers to audience segment identifiers and thus determine the particular product codes that relate to audience segments identifiers.

Network 140 broadly represents one or more local area networks, wide area networks, and/or internetworks using any of terrestrial or satellite, wired or wireless links. Communications over network 140 may use internetworking protocols such as HTTPS over TCP/IP. At the application layer, communications between the functional units of FIG. 1 may use OpenRTB, app-based protocols, and/or parameterized HTTPS.

The end-user computing devices 150 may comprise smartphones, tablet computers, laptop computers, or other computing devices associated with consumer or end-user accounts. Typically an end-user computing device 150 includes one or more wireless transceivers such as GPS receivers, Wi-Fi transceivers or short-distance RF transceivers and location software as part of an app or mobile device operating system that automatically periodically determines a then-current geo-location of the device and transmits location data to specified servers via network 140.

Embodiments of the techniques herein may interoperate with any number of devices 150 based on the computing capacity of the offer server computer system 100 and the bandwidth of network 140. Use of high-capacity computers and high-throughput networks to serve millions of concurrent devices 150 is specifically contemplated and the techniques herein place no limits on the utilization of such devices. For example, offer server computer system 100 may use load balancing routers, multiple app servers, queues, worker threads, and parallelism to achieve higher throughput.

In an embodiment, the offer server computer system 100 comprises components that are implemented at least partially by hardware at one or more computing devices, such as one or more hardware processors executing stored program instructions stored in one or more memories for performing the functions that are described herein. In other words, all functions described herein are intended to indicate operations that are performed using programming in a special-purpose computer or general-purpose computer, in various embodiments. FIG. 1A illustrates only one of many possible arrangements of components configured to execute the programming described herein. Other arrangements may include fewer or different components, and the division of work between the components may vary depending on the arrangement.

2.2 Overview of Selecting and Transmitting TPR Offers

FIG. 1B illustrates one embodiment of a process of selecting and transmitting TPR offers. In an embodiment, at block 170, a computer-implemented method executed using an offer server computer system comprises receiving and digitally storing a first digital image file. In one embodiment, a set of static images of CPGs is received and digitally stored for later use in dynamically generated ad units. At block 172, the process is programmed for receiving and digitally storing a first mapping of product code values to audience segment identifiers.

At block 174, the process is programmed for receiving and digitally storing a temporary price reduction (TPR) offer dataset. In some embodiments, the TPR offer dataset comprises a plurality of digital records of offers, each of the digital records comprising an association of at least location data specifying a location of a retailer, a start date value and an end date value of an effective period, a product identifier, and a temporarily reduced price.

At block 176, the process is programmed for programmatically mapping a target identifier, which is associated with an end-user computing device that is associated with a prospective consumer, to an audience segment identifier. Block 176 may be performed, for example, in response to mobile device application, a web browser or other client application, executed at the end-user computing device, requests placement of an ad unit within a space in the app or in a web page that has been previously allocated for the placement of an ad unit. As an example, an end-user computing device may be executing a particular retailer's mobile device app which executes an app function to request a promotional offer to display in-app.

Block 176 may form a part of larger, multi-step process of receiving bids for ad placement and determining a winning bid and is not intended to represent all sub steps of a bid request or bid selection process. For example, bid selection can include receiving device location data specifying a then-current location of the end-user computing device and determining that the device location data is within a specified physical radius of a particular retailer that is identified in the TPR offer dataset.

At block 178, the process is programmed to determine, based on the audience segment identifier, that the TPR offer dataset comprises a particular record that includes a particular product code and a particular retailer identifier that map to the audience segment identifier, and includes an effective date value that includes a current date value corresponding to a current date, and that the particular retailer identifier corresponds to a retailer location that is within a specified geographical distance of a then-current location of the end-user computing device.

In some embodiments, winning bids may be subject to price checks. For example, the process may be programmed for reading, from the particular record of the TPR offer dataset, a particular reduced-price value of the particular product; obtaining, from a local retail price data source, a then-current local price value of the same particular product; performing the creating and storing, and the transmitting, only when the particular reduced-price value is less than the then-current local price value.

Based on the determination of block 178, a dynamic ad unit to offer a TPR may be created. At block 180, in response to block 178, the process is programmed for creating and storing a digital offer dataset comprising both the first digital image file and a second digital image file that presents one or more data elements of the TPR offer dataset. At block 182, the process is programmed further for causing transmission of the digital offer dataset toward the end-user computing device. Actual delivery of the ad unit to a display of the end-user computing device may involve intermediary ad networks, servers, and the browser. The foregoing process description is intended to explain the principal functions of an inventive solution but not to exhaustively describe every sub step to implement the functions since the skilled audience to which this disclosure is directed will be aware of how to program those sub steps.

Optional functions and features can be implemented in various embodiments. For example, the process can be programmed to execute the previously described determining, creating and storing, and transmitting functions only in response to determining that the location data is within a specified geographical radius of a particular retailer having opening hours that include a then-current time of day that is local to the end-user computing device. Or, the process can be programmed to execute the determining, creating and storing, and transmitting only in response to determining that the location data is within a specified geographical radius of a particular retailer for which local weather conditions match specified conditions of use of the particular product in the TPR offer dataset.

Typically, the audience segment identifiers will have been generated before execution of the process just described, based on a plurality of digital data received from one or more retailers and identifying particular products that were previously purchased at points of sale in association with purchaser identifiers. The product codes can be UPC values or GTIN values. The target identifier can be a loyalty identifier that is obtained at a point of sale computer and transmitted to the offer server computer system.

2.3 Campaign Assembly; Ad Serving

As detailed in other sections herein, functional operation of the distributed system of FIG. 1A and the process of FIG. 1B may be organized in two flows or stages comprising a campaign assembly flow and an ad serving flow.

In general, campaign assembly functions as an intake or configuration stage to receive several digital datasets and define campaigns. Each campaign is an organized framework for automatically transmitting digital offers to digital computing devices or accounts according to specified constraints. In an embodiment, campaign assembly comprises periodically receiving a TPR dataset, for example on a weekly basis. Data in the TPR dataset is matched against advertising orders that have been previously stored in an order management system. In response to detecting a match, a minimal campaign dataset or campaign shell is created and stored, in the offer server computer system 100 or in a separate system or sub system that manages programmatic offer delivery. Digital images depicting specific products may be received, retrieved, obtained, and stored, alone or in combination based on templates for specific ordering, arrangement, and presentation of creative elements of an offer. As a result, a campaign becomes fully populated with the data necessary for serving specific offers or flights and can be marked live in the system. Each campaign typically is associated with a total budget value representing the total available amount for spending on serving ads, and which may be divided into a plurality of per-week budgets for particular calendar weeks of the campaign.

Ad serving constitutes the execution of campaigns to cause transmitting the digital offers when input data at a particular time and place matches campaign data. The ad serving flow may execute, for example, in response to the offer server computer system 100 receiving a request to serve an ad within a web page that is viewed by a particular end-user computing device and that has ad space available. In an embodiment, in general, bid requests for filling the available ad space are transmitted and specify one or more retailer loyalty segment identifiers, which specify audience segments that are associated with loyalty to a particular brand or product code, and that are within a geographical region of retailers at which a TPR for the particular brand or product code is offered. Winning bids result in retrieving data elements such as end-user device identifiers and geo-location identifiers such as lat-long values; these elements are used to determine pricing for the closest retailer, local weather conditions, or other localized values that may constrain whether an offer should be actually presented to a specific end-user device.

If favorable data values are determined to exist, then a particular ad unit is created and transiently stored in computer memory. Creating the particular ad unit may include retrieving a product-specific image from a database coupled to the offer server computer system 100, ordered based on the highest-affinity TPR product for the end-user associated with the particular end-user device, retrieving a digital image that identifies a retailer that is local to the particular end-user device, and confirming that the TPR price to be shown in the particular ad unit is actually lower than otherwise locally available for a particular location or retailer. Ad serving in this manner may be repeated until a previously stored budget for a period of the campaign, such as the then-current calendar week, is exhausted. An ad unit is not required to show the TPR price but can specify an offer name, a percentage off, or other data, information, or call to action.

FIG. 2 illustrates one embodiment of algorithms for defining and transmitting TPR offers. In an embodiment, FIG. 2 reflects two asynchronous processes comprising a campaign assembly process and a data transmitting process, which may be initiated and executed independently at any time depending on the state of digitally stored data in the system. In an embodiment, campaign assembly instructions 120 may be programmed to execute the campaign assembly process and the data transmitting instructions 130 may be programmed to execute the data transmitting process.

Referring first to the campaign assembly process, in an embodiment, at block 202, a campaign is added to storage of offer server computer system 100 (FIG. 1A). For example, campaign definition 110 is created or received, programmatically or by other data entry. In an embodiment, block 202 is programmed to check the validity of each UPC or GTIN value specified in the campaign definition 110 by forming and transmitting queries to master product database 102 and testing whether a result set of the query is a null set or contains data. Furthermore, block 202 is programmed to test a validity of the timeframe specified in the campaign definition 110 and the validity of the minimum and maximum spend values specified in the definition. For example, the maximum spend value must be greater than the minimum spend value, the minimum spend value must be greater than a threshold system minimum that can be used or placed. Other programmed validity rules may be applied to the data of campaign definition 110. If a validity error is determined, then block 202 may be programmed to generate and transmit a notification, error, or warning, form and store a log file record in a log file, suspend operation of the process, or execute other error modes.

At block 204, digital data for basic elements of an insertion order (10) are transmitted to the programmatic system. In an embodiment, to create an anchor in the programmatic system to which flights can be pushed later, an API call or other programmatic request is transmitted to the programmatic system to cause creating an empty IO/campaign with minimal information such as name, dates and frequency capacity. Line items are not pushed at this time. Base elements also may include digital image files to be displayed when an offer is presented, dates during which the order is effective, and budget. In an embodiment, a unique campaign identifier is assigned and stored in the programmatic system in response and provided in a response to the process after block 204.

At block 206, an analysis phase is executed comprising reading the TPR offer file 104 and determining whether offers are present in the file that match parameters of a specified campaign definition 110. If one or more matching offers are present, then a line item is formed for each matching offer and queued, at block 208, to a work queue system as further described in connection with FIG. 3A.

Turning now to the data transmitting process of FIG. 2, in an embodiment, on a scheduled periodic basis or when manually invoked, the offer server computer system 100 is programmed to analyze new TPR offer database and pull reporting. At block 210, pull reporting is inspected to check campaign and line item delivery, and to adjust the campaign budget for future planning. At block 212, the process is programmed to analyze all campaigns and all line items. The offer database is inspected for new offers to be converted to line items. A line item budget is calculated for each and tactics or audiences are determined.

At block 214, newly created line items are added to the queue. Thus, after inspecting all configured campaigns, the queue is updated with the latest changes that are needed. At block 216, the queue is executed.

FIG. 3A illustrates further details of a campaign assembly algorithm and ad serving algorithm, according to one embodiment. FIG. 3A shows, for one embodiment, a campaign configuration process 300A and an ad placement process 300B. Referring first to process 300A, in an embodiment, at block 302, a TPR data feed is received on a periodic basis. For example, the offer server computer system 100 (FIG. 1) is programmed to receive TPR offer file 104 periodically and, in response, to match advertiser orders against one or more newly listed TPR records in the offer file.

At block 304, in response, a new ad campaign is created in a demand ad server or DSP platform such as the programmatic system discussed in connection with FIG. 2. FIG. 3B illustrates data values that may serve as input, and may be calculated, to create a campaign in one embodiment.

FIG. 3B illustrates a first table 320 that summarizes preferred field values for input to create a campaign, and a second table 330 that specifies field values that may be derived, under stored program control, or obtained from other systems or input. In an embodiment, first table 320 comprises a first row 322 that specifies labels of data fields or attributes; the same labels may be used as column names, attribute names, or variable names in programming an embodiment or configuring the schema of the database 102. A second row 324 specifies example values for an example that is also referenced in other sections herein. A third row 326 describes optional programming of offer server computer system 100 that may be implemented in one or more embodiments.

Second table 330 similarly comprises a first row 332 that specifies labels of data fields or attributes; the same labels may be used as column names, attribute names, or variable names in programming an embodiment or configuring the schema of the database 102. A second row 334 specifies example values for an example that is also referenced in other sections herein. A third row 336 describes optional programming of offer server computer system 100 that may be implemented in one or more embodiments.

At block 306, the process is programmed to request one or more product image files from a database, such as master product database 102 (FIG. 1) or another repositor of UPC product data, and to apply a creative template to the image files. The result is a completed campaign capable of placement or delivery, which is marked as live in the programmatic system at block 308.

Process 300B is described next. In an embodiment, before process 300B initiates execution, at block 310, consumer point-of-sale (POS) transaction data and product affinity score data is received from third-party sources, analyzed, and formed as a set of retailer loyalty segment identifiers. In general, the retailer loyalty segment identifiers specify attributes of consumers who may be interested in particular products or brands based upon past actual purchases at retail points of sale. The POS transaction data provides specific product identifiers from a basket of purchased products with a loyalty card identifier or a device identifier that is associated with the consumer.

At block 312, one or more advertisement bid requests are received. In an embodiment, bid requests conform to message protocols defined as part of OpenRTB Real-time Bidding (RTB) and specifically include a retailer loyalty segment identifier value and one or more location values. In an embodiment, location values are specified as latitude-longitude (lat/long) values and a radius value.

At block 314, in real time in response to a request to place a digital offer in a particular resource, such as a web page, app, or other digital facility, the process is programmed to determine one or more winning bids on audience segments for a particular brand, category, and verified retail shoppers. When a winning bid is selected, and data elements of the winning bid match a campaign or flight that has been formed based on the TPR offer file 104 in the campaign assembly process, then at block 316 a dynamic ad unit will be formed to include a TPR offer.

In an embodiment, calculating the winning bid is based in part on obtaining a device identifier from the audience segment information, the lat/long values for the purpose of linking pricing to the closed store for co-branding, and using the lat/long values to retrieve third-party weather data. For example, the product identified in a TPR record must be relevant to a given audience segment for a winning bid to be declared. The bid must include location data to enable verifying that the price of a given product at a local retailer is not lower than the TPR for the same geo-location specified in records of TPR offer file 104.

Thus, in an embodiment, a winning bid should have high location accuracy because useful offer of a TPR should reference local retailer that actually is offering the TPR for a specified product. In some cases, values that constrain or affect bids to win may be derived or obtained from other systems and do not appear in the bid request. For example, mappings 106, 108 may enrich a bid and these values and sources may influence the calculation of a winning bid according to several different programmed rules.

For example, a TPR record could specify a brand of outdoor cooking charcoal as having reduced prices because the brand owner knew at the time of forming the TPR offer file 104 that local weather had been poor for several days, and the lat/long values and third-party weather data may indicate that the shopper's device is within a location for which rain is forecast or occurring. In such a case, programmed rules may bias the winning bid calculation against that TPR record.

Time of day data for the shopper device's location also may bias the calculation. For example, if the time of day at the shopper device's location is 7:00 μm and based on the lat/long values the closest retailer to the shopper device location is closed at that hour, then the programmed rules may bias the winning bid calculation against that TPR record. Weather and time of day values also may be used to alter the appearance of a dynamic ad unit at block 316, for example, by rendering the ad unit using darker colors if the current time is night, adding summer theme graphical elements if the weather is hot, and so forth.

Applying the programmed rules will result in identifying one or more winning bids. In response, at block 316, in real time, a set of digital offer or advertising data is automatically created and stored in memory, forming a dynamically generated digital advertisement. In an embodiment, block 316 is programmed to select and use a digital image file for the highest affinity product that is associated with a TPR, and to use a banner or other digital image associated with the closest local retailer that sells the product subject to the TPR.

Further, in an embodiment, block 316 is programmed to confirm that the TPR price is materially lower than the average price for the product at the closest local retailer. This programmed rule is intended to prevent creation and presentation of offers where, for example, the TPR price of a product is minimally less than the current available regular price for the item at the closest retailer. The specific mechanism for confirming that a TPR price is lower is not critical. As an example, the process could receive and store a separate digital file that specifies undiscounted current pricing for a set of items and retailers, or calculates average price for a particular product across several retailers, and block 316 could be programmed to match the item of the dynamic offer to the records in the separate digital file and to compare price values.

In an embodiment, the dynamic offer that was created at block 316 is served, at block 318, as part of the selected campaign line items until the set budget is expended.

An example of placement is now provided involving two (2) UPC values and a single unified budget. Assume that the brand Universal Exports has contracted with an operator of offer server computer system 100 to advertise upcoming promotions for two (2) stock keeping units (SKUs) of underwater cameras in all DraxBuy stores throughout the upcoming ten weeks, knowing that the UPCs and offers will only be live for six of the ten weeks, with a budget of $60,000. FIG. 4A illustrates data parameters that may be stored in campaign definition 110 (FIG. 1) for the specified example.

In an embodiment, each week, a new TPR offer list is uploaded to offer server computer system 100 as TPR offer file 104. Since the campaign is using a combined budget pool and estimated weeks allocation, flight budgets are equally divided and calculated as $60,000 DIV 2 UPCs DIV 6 weeks each=$5,000 per flight per UPC. Each week, data transmitting instructions 130 automatically push the flights to the programmatic system until the budget has been depleted. FIG. 4B graphically illustrates the delivery of flights of TPR offers and the corresponding impact on budget consumption. The budget for a line item may be calculated as:

$LI Budget = \frac{(Total Budget - Spent Budget)}{(Estimated Weeks - Line Item Count Live)}$

FIG. 3C illustrates the interoperation of the databases, files and mappings shown in FIG. 1 at different stages of processing as described above. For example, offer server computer system 100 may be programmed to receive a product code value such as a UPC or GTIN value as input, then query the master product database 102 to determine if the product code value exists; if a result set is received that is not null, then the product code is confirmed, and a return value or other programmatic response may be passed to other elements of the system. Or, if both a product code and audience segment value are received, then the product code may be validated as just described, and the product code audience mapping 106 may be used to retrieve a valid programmatic audience ID, then compared to the TPR offer file 104 to calculate and set a new line item under a campaign.

Further, if a retailer ID is received, then offer server computer system 100 may be programmed to use retailer target mapping 108 to yield a programmatic geographic identifier for use in location comparisons as previously described.

Unlike prior techniques, the ad units that are created and transmitted in the foregoing manner may be closely adapted to local retailers based on audience segment identifier and the geography of the available retailers and the geo-location the target end-user device. Winning bids for ads comprise accurate location values that correspond to the geo-location data of at least one record in the TPR data file 104 for a region containing retailers at which the TPR is offered or available. Ad units are compiled using not only a digital image of a specific product subject to the TPR as identified in the TPR data file, but a further digital image that identifies a particular retailer that offers the TPR and is local to the end-user computing device to which the ad unit is delivered. Furthermore, a particular TPR price may be included in the ad unit and is confirmed as a significantly or materially lower price than an average or typical price for the same product within the same geography as the retailer to be featured.

In an embodiment, one main Promo Amplification Advertiser data object is created and defined in the programmatic system noted above, for each Retailer group, to enable reporting on performance or delivery in a flexible manner. Each campaign results in creating one insertion order (10) in the programmatic system. Each UPC ad unit is pushed as a separate creative in the programmatic system. Further, for each product code and each unit of advertising delivery, termed a flight, a corresponding line item is created in the programmatic system. Each line item has multiple tactics assigned for delivery; examples include, and are not limited to, audience segments and geo-targeting.

In an embodiment, after the IO has been pushed to the programmatic system, campaign assembly instructions 120 are programmed to upload a creative tag for each product code that is identified in a campaign. Each such creative push comprises an engagement tag, a plurality of digital image files, optional associated data, and version identifiers. Examples of digital images that could be concurrently transmitted as part of a push may include a basic creative image, network links or URLs to be associated with particular image versions, images with specific TPR messages, and a campaign identifier. Alternative digital images may be used to enable better adaptation to different geographic locations or to permit customization of ad units for particular audience segments or brand identities.

FIG. 5 illustrates an example set of digital images that may be used in an embodiment. For the example of FIG. 5, a set of pushed creative 502 comprises a basic creative image 504 and a second image 506 with a specific TPR message. In one embodiment, a CPG or brand forms the basic creative image 504 and transmits it offline to the offer server computer system 100. In an embodiment, multiple different copies of second image 506 may be associated in the same creative push and may specify different retailers, slogans, or other content, and may be associated with different URLs for consumer action. The IO and creative identifiers may be stored in master product database 102 or another database for reference in other steps. In various embodiments, creative 502 may include images and copy for the product, the retailer's banner logo and a suggestion that the product is currently on price promotion.

The creative 502 may include a hyperlink such that computer input, such as a tap or click, on the ad banner is programmed to cause showing the product's promotional price and type (e.g. certain amount off one product, BOGO, etc.) directly on the first page of the landing experience on the retailer's website. In some embodiments, input on an ad unit may be programmed to cause, on a receiving server, activation of other offers, loyalty points, rebates, or other benefits in response to the end-user driving to a store, using a shopping list or store locator, or adding an item to an online shopping cart.

The embodiments thus described provide numerous technical benefits in comparison to past techniques. The distributed computer systems and programmed processes described herein enable computers associated with CPG brands to transmit instructions for temporary price reductions that are read, interpreted, and applied to generate dynamic digital offers to end-user devices within a specified geography and time. Prior systems have been unable to process, form, or transmit offers with these parameters and constraints.

2.4 Dynamic Price Integration

In some embodiments, areas of an offer such as the second image 506 may comprise a specific price, rather than a generalized statement relating to a reduced-price offer, the specific price being derived or extracted from the TPR offer file 104 alone, or in combination with other data such as location data identifying the location to which the pushed creative 502 is to be served.

FIG. 6 illustrates an example creative area that may be used in an embodiment. In the example of FIG. 6, a set of pushed creative 602 comprises a basic creative image 604 and a second image region 606 that is capable of receiving specific price data. Creative 602 is typically formatted as a 320 pixel by 50 pixel banner image capable of effective display on mobile computing devices, such as in a portion of a smartphone screen display. In one embodiment, the CPG creative image 604 is 240×50 pixel proportions to occupy 75% of the total and the second image region appears in 25% of the total. The foregoing pixel dimensions are for one example and other embodiments may use other dimensions.

In one embodiment, a CPG or brand forms the basic creative image 604 and transmits it offline to the offer server computer system 100. In an embodiment, the second image 606 may be formed dynamically at the time that an offer is to be served, by reading the TPR offer file 104 to extract a specific reduced price value, and/or by reading the TPR offer file to obtain a reduced price value and then localizing the reduced price value based upon other data, such as the location of a client computer to which the offer is served, the location of the client computer in combination is other data specifying prices of retail outlets in proximity to the client computer, or other data. The second image 606 may be associated with different URLs for consumer action.

The IO and creative identifiers may be stored in master product database 102 or another database for reference in other steps. In various embodiments, creative 602 may include images and copy for the product, the retailer's banner logo and a suggestion that the product is currently on price promotion. The creative 602 may include a hyperlink such that computer input, such as a tap or click, on the ad banner is programmed to cause showing the product's promotional price and type (e.g. certain amount off one product, BOGO, etc.) directly on the first page of the landing experience on the retailer's website. In some embodiments, input on an ad unit may be programmed to cause, on a receiving server, activation of other offers, loyalty points, rebates, or other benefits in response to the end-user driving to a store, using a shopping list or store locator, or adding an item to an online shopping cart.

FIG. 7 illustrates an example set of creative areas that may be used with dynamic price integration in an embodiment. FIG. 7 illustrates three (3) discrete example offer images 702-1, 702-2, 702-3 each comprising the creative 602 of FIG. 6 in combination with a merchant-specific field 704 having a merchant identifier 710 and a call to action widget 712. In various embodiments, example offer images 702-1, 702-2, 702-3 may comprise a price image 706-1, 706-2, 706-3, respectively. The contents of the price image 706-1, 706-2, 706-3 may vary in different embodiments. For example, price image 706-1 is expressed in terms of a reduction in value in a particular currency (“$1 OFF”). The price image 706-2 is expressed as a percentage discount and the price image 706-3 is expressed as a quantity deal (“2 FOR $5”).

In some embodiments, offer images 702-1, 702-2, 702-3 may comprise a validity period image 708-1, 708-2, 708-3, the contents of which may be dynamically formed based upon data in the TPR offer file 104. For example, validity period image 708-1 states a first validity period (“VALID THRU 6/22”) and validity period image 708-2 states a second, different validity period (“VALID THRU 6/15”).

In an embodiment, the merchant identifier 710 is determined and formed in a graphic image dynamically based upon data in the TPR offer file 104. In some embodiments, the image for the call to action widget 712 is the visually the same for all instances of offer images 702-1, 702-2, 702-3, but is associated with a different, parameterized hyperlink for each of the offer images, to enable an analytics server to determine which offer image was selected.

Thus, based upon the TPR offer file 104, the offer server computer 100 is programmed to generate current offer details and an expiration date and modify the creative to include graphic image segments or portions that contain that information. Furthermore, when a new TPR is detected with a different offer, the offer details are updated in real-time and reflected in the creative image. As a specific example, with the 320×50 specifications of FIG. 7, the left 75% of the 320×50 banner (240×50 pixels) is reserved for advertiser brand and product images, as well as offer details text, and the advertiser transmits digital messages to the offer server computer 100 for three components of the left 75%: 240×50 background—Dynamic offer text font color is white, and the background normally contrasts with the offer text; Brand logo—The brand logo will be the left most image of the creative. Suggested width is 70 to 75 pixels to utilize the left half of the 145×50 creative area; Product images—Product images will be placed to the right of the brand logo. Suggested width is also 70 to 75 pixels to utilize the right half of the 145×50 creative area. The offer server computer 100 is programmed to dynamically inject offer text details within the 95×50 copy area.

FIG. 8 illustrates an example creative area that may be used in an embodiment. In an embodiment, a graphic image 800 comprises a first CPG image 802 occupying about one-half of the total image, a second CPG image 804 that occupies about 25%, and a dynamic image area 806 that occupies another 25%. In one embodiment, graphic image 800 is formatted as 300 pixels by 250 pixels. FIG. 9 illustrates an example creative area that may be used with dynamic price integration in an embodiment. The example of FIG. 9 shows images 800, 802, 804, 806, as in FIG. 8, combined with a merchant identifier 910 and a call to action widget 912.

For the 300×250 specifications of FIG. 8, FIG. 9, the top 75% of the 300×250 banner (300×200) is reserved for advertiser brand and product images, as well as offer details text and the advertiser transmits digital messages to the offer server computer 100 for three components of the left 75%: 300×200 background—Dynamic offer text font color is white, and normally the background contrasts with the offer text; Brand logo—The brand logo will be the top right quarter of the creative and the brand logo is appropriately sized for the brand logo area of 170×100; Product image(s)—Product image(s) will be placed in the left half of the creative and the product image is appropriately sized for the product shot area of 130×200. The offer server computer 100 is programmed to dynamically inject offer text details within the 170×100 copy area.

Using images of the formats of FIG. 7, FIG. 8, FIG. 9, the computer system of FIG. 1 may be programmed to execute a workflow with which one embodiment could be implemented with dynamic price integration. FIG. 10 illustrates a computer-implemented process with which one embodiment could be implemented without dynamic price integration. In one embodiment, one or more of campaign assembly instructions 120 and data transmitting instructions of offer server 100 are programmed to execute a method 1000 starting at step 1002, at which the TPR offer file 104 is analyzed to identify one or more upcoming sales for promoted products at specified retailers. For example, database queries may be served against the offer file to retrieve records that match particular products or retailers for which a sale is scheduled in a specified period. If a matching sale is found, then the record for the sale is retrieved and core data points are extracted from the record. In one embodiment, relevant data points are: UPC, Store ID, offer start/end dates, Offer details. In an embodiment, offer details include a specific price, amount of discount, or other offer terms that are to be offered for the corresponding Store ID.

In an embodiment, at step 1004, the process is programmed to log the data points that were extracted, for example, by saving an association of the data points as part of a campaign definition 110 for a new campaign. Step 1004 may also involve automatically activating a new campaign, as defined in the campaign definition 110, by retrieving in real-time one or more dynamic creative templates. In one embodiment, step 1004 comprises loading, from one of the storage sources described for FIG. 1, graphic images files of the form shown in FIG. 7, FIG. 9, as templates for modification with dynamically supplied price data.

At step 1006, the process is programmed to identify a location of end-user device or account 150 (FIG. 1), to find the closest retail store for that device. For example, location data received or obtained from device or account 150, via network 140 or point of sale system 160, may be mapped to retailer target mapping 108 or retailer location data in records of TPR offer file 104, to determine which retail store ID is closest to the then-current location of the device or account. Any of a plurality of different algorithms for calculating the nearest location or store may be used. Campaign assembly instructions 120, data transmitting instructions 130, or an independent ad server process may execute step 1006, in various embodiments.

Further, as part of step 1006, in an embodiment, the method is programmed to retrieve the current price offer and end date to populate in the creative. These values may be those that were extracted from a matching record at step 1004 and may be read from the campaign definition 110. At step 1008, the creative image template that was retrieved earlier is modified by adding a logo for the retailer associated with the Store ID. Adding a logo for a retailer may comprise retrieving, from master product database 102 or other storage (FIG. 1), digital image files corresponding to image elements 710 (FIG. 7) or 910 (FIG. 9) and updating the retrieved image template file with those elements.

Step 1008 also is programmed to add offer details to a template graphic image. Step 1008 may be hard-coded with logic that differentially updates the graphic image template based upon different values of the offer details. For example, the offer details may be expressed in the TPR offer file 104 in a format that requires parsing or transformation to a different expression of particular characters, different typeface, typeface size, or other formatting, to yield graphic image elements like 706-1, 706-2, 706-3, 708-1, 708-2, 708-3, 710, 712 (FIG. 7), or elements 804, 806, 910, 912 (FIG. 9). As one example, the “Amount of Discount” field in the TPR offer file 104 could specify “1”, “25%”, or “2 for $5” and different coding could be required to transform those values from the file into the specific graphics shown for elements 706-1, 706-2, 706-3 (FIG. 7). As another example, each record of the TPR offer file 104 may specify a “Start Date” and “End Date” for an offer, but step 1008 may be programmed to determine that the then-current date is after the Start Date, and to transform the End Date value into characters such as “VALID THRU 6/22” or “VALID THRU 6/22/21” or “EXPIRES JUNE 22” or any other format that is useful.

At step 1010, the completed creative is served to the end-user device or account 150. Step 1010 may comprise returning a completed creative graphic image file to the point of sale system 160, transmitting the completed creative graphic image file to a compatible browser or application that the end-user device or account 150 executes, programmatically calling an ad server or other ad delivery platform, or other mechanics. The particular mechanism of delivering the completed creative graphic image to an end-user device or account is not critical and any programmatically executed mechanism known in advertising technology may be used.

In this manner, brands may deliver graphic images or creatives that depict only product images and product-related messaging, but without retailer information or logos, calls to action, messaging about TPRs. Instead, the retailer information or logos, calls to action, and messaging about TPRs are determined, in real-time at the time that an offer is served, based upon the TPR offer file 104, automatically generated and inserted into a final image, which is served to a mobile device or other computing device as the final offer. Furthermore, offers are localized based upon obtaining then-current device location information, which allows the TPR offer file 104 to store a plurality of different offer details for the same CPG or product for different retail store IDs, retailers, or geographic locations.

In some embodiments, the process of FIG. 10 is triggered in real-time, at the time that end-user device or account 150 appears at a point of sale that is associated with the point of sale system 160, in response to a query from point of sale system 160 to offer server computer system 100. Or, the offer server computer system 100 may periodically read the POS transaction logs 162 to parse records of past transactions to identify end-user device or account 150 and determine which offer of TPR offer file 104 to serve to that device or account, after dynamically updating a graphic image template file as previously described.

3. Implementation Example—Hardware Overview

According to one embodiment, the techniques described herein are implemented by at least one computing device. The techniques may be implemented in whole or in part using a combination of at least one server computer and/or other computing devices that are coupled using a network, such as a packet data network. The computing devices may be hard-wired to perform the techniques, or may include digital electronic devices such as at least one application-specific integrated circuit (ASIC) or field programmable gate array (FPGA) that is persistently programmed to perform the techniques, or may include at least one general purpose hardware processor programmed to perform the techniques pursuant to program instructions in firmware, memory, other storage, or a combination. Such computing devices may also combine custom hard-wired logic, ASICs, or FPGAs with custom programming to accomplish the described techniques. The computing devices may be server computers, workstations, personal computers, portable computer systems, handheld devices, mobile computing devices, wearable devices, body mounted or implantable devices, smartphones, smart appliances, internetworking devices, autonomous or semi-autonomous devices such as robots or unmanned ground or aerial vehicles, any other electronic device that incorporates hard-wired and/or program logic to implement the described techniques, one or more virtual computing machines or instances in a data center, and/or a network of server computers and/or personal computers.

FIG. 11 is a block diagram that illustrates an example computer system with which an embodiment may be implemented. In the example of FIG. 11, a computer system 1100 and instructions for implementing the disclosed technologies in hardware, software, or a combination of hardware and software, are represented schematically, for example as boxes and circles, at the same level of detail that is commonly used by persons of ordinary skill in the art to which this disclosure pertains for communicating about computer architecture and computer systems implementations.

Computer system 1100 includes an input/output (I/O) subsystem 1102 which may include a bus and/or other communication mechanism(s) for communicating information and/or instructions between the components of the computer system 1100 over electronic signal paths. The I/O subsystem 1102 may include an I/O controller, a memory controller and at least one I/O port. The electronic signal paths are represented schematically in the drawings, for example as lines, unidirectional arrows, or bidirectional arrows.

At least one hardware processor 1104 is coupled to I/O subsystem 1102 for processing information and instructions. Hardware processor 1104 may include, for example, a general-purpose microprocessor or microcontroller and/or a special-purpose microprocessor such as an embedded system or a graphics processing unit (GPU) or a digital signal processor or ARM processor. Processor 1104 may comprise an integrated arithmetic logic unit (ALU) or may be coupled to a separate ALU.

Computer system 1100 includes one or more units of memory 1106, such as a main memory, which is coupled to I/O subsystem 1102 for electronically digitally storing data and instructions to be executed by processor 1104. Memory 1106 may include volatile memory such as various forms of random-access memory (RAM) or other dynamic storage device. Memory 1106 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 1104. Such instructions, when stored in non-transitory computer-readable storage media accessible to processor 1104, can render computer system 1100 into a special-purpose machine that is customized to perform the operations specified in the instructions.

Computer system 1100 further includes non-volatile memory such as read only memory (ROM) 1108 or other static storage device coupled to I/O subsystem 1102 for storing information and instructions for processor 1104. The ROM 1108 may include various forms of programmable ROM (PROM) such as erasable PROM (EPROM) or electrically erasable PROM (EEPROM). A unit of persistent storage 1110 may include various forms of non-volatile RAM (NVRAM), such as FLASH memory, or solid-state storage, magnetic disk, or optical disk such as CD-ROM or DVD-ROM and may be coupled to I/O subsystem 1102 for storing information and instructions. Storage 1110 is an example of a non-transitory computer-readable medium that may be used to store instructions and data which when executed by the processor 1104 cause performing computer-implemented methods to execute the techniques herein.

The instructions in memory 1106, ROM 1108 or storage 1110 may comprise one or more sets of instructions that are organized as modules, methods, objects, functions, routines, or calls. The instructions may be organized as one or more computer programs, operating system services, or application programs including mobile apps. The instructions may comprise an operating system and/or system software; one or more libraries to support multimedia, programming or other functions; data protocol instructions or stacks to implement TCP/IP, HTTP or other communication protocols; file format processing instructions to parse or render files coded using HTML, XML, JPEG, MPEG or PNG; user interface instructions to render or interpret commands for a graphical user interface (GUI), command-line interface or text user interface; application software such as an office suite, internet access applications, design and manufacturing applications, graphics applications, audio applications, software engineering applications, educational applications, games or miscellaneous applications. The instructions may implement a web server, web application server or web client. The instructions may be organized as a presentation layer, application layer and data storage layer such as a relational database system using structured query language (SQL) or no SQL, an object store, a graph database, a flat file system or other data storage.

Computer system 1100 may be coupled via I/O subsystem 1102 to at least one output device 1112. In one embodiment, output device 1112 is a digital computer display. Examples of a display that may be used in various embodiments include a touch screen display or a light-emitting diode (LED) display or a liquid crystal display (LCD) or an e-paper display. Computer system 1100 may include other type(s) of output devices 1112, alternatively or in addition to a display device. Examples of other output devices 1112 include printers, ticket printers, plotters, projectors, sound cards or video cards, speakers, buzzers or piezoelectric devices or other audible devices, lamps or LED or LCD indicators, haptic devices, actuators, or servos.

At least one input device 1114 is coupled to I/O subsystem 1102 for communicating signals, data, command selections or gestures to processor 1104. Examples of input devices 1114 include touch screens, microphones, still and video digital cameras, alphanumeric and other keys, keypads, keyboards, graphics tablets, image scanners, joysticks, clocks, switches, buttons, dials, slides, and/or various types of sensors such as force sensors, motion sensors, heat sensors, accelerometers, gyroscopes, and inertial measurement unit (IMU) sensors and/or various types of transceivers such as wireless, such as cellular or Wi-Fi, radio frequency (RF) or infrared (IR) transceivers and Global Positioning System (GPS) transceivers.

Another type of input device is a control device 1116, which may perform cursor control or other automated control functions such as navigation in a graphical interface on a display screen, alternatively or in addition to input functions. Control device 1116 may be a touchpad, a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 1104 and for controlling cursor movement on display 1112. The input device may have at least two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane. Another type of input device is a wired, wireless, or optical control device such as a joystick, wand, console, steering wheel, pedal, gearshift mechanism or other type of control device. An input device 1114 may include a combination of multiple different input devices, such as a video camera and a depth sensor.

In another embodiment, computer system 1100 may comprise an internet of things (IoT) device in which one or more of the output device 1112, input device 1114, and control device 1116 are omitted. Or, in such an embodiment, the input device 1114 may comprise one or more cameras, motion detectors, thermometers, microphones, seismic detectors, other sensors or detectors, measurement devices or encoders and the output device 1112 may comprise a special-purpose display such as a single-line LED or LCD display, one or more indicators, a display panel, a meter, a valve, a solenoid, an actuator or a servo.

When computer system 1100 is a mobile computing device, input device 1114 may comprise a global positioning system (GPS) receiver coupled to a GPS module that is capable of triangulating to a plurality of GPS satellites, determining and generating geo-location or position data such as latitude-longitude values for a geophysical location of the computer system 1100. Output device 1112 may include hardware, software, firmware and interfaces for generating position reporting packets, notifications, pulse or heartbeat signals, or other recurring data transmissions that specify a position of the computer system 1100, alone or in combination with other application-specific data, directed toward host 1124 or server 1130.

Computer system 1100 may implement the techniques described herein using customized hard-wired logic, at least one ASIC or FPGA, firmware and/or program instructions or logic which when loaded and used or executed in combination with the computer system causes or programs the computer system to operate as a special-purpose machine. According to one embodiment, the techniques herein are performed by computer system 1100 in response to processor 1104 executing at least one sequence of at least one instruction contained in main memory 1106. Such instructions may be read into main memory 1106 from another storage medium, such as storage 1110. Execution of the sequences of instructions contained in main memory 1106 causes processor 1104 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions.

The term “storage media” as used herein refers to any non-transitory media that store data and/or instructions that cause a machine to operation in a specific fashion. Such storage media may comprise non-volatile media and/or volatile media. Non-volatile media includes, for example, optical or magnetic disks, such as storage 1110. Volatile media includes dynamic memory, such as memory 1106. Common forms of storage media include, for example, a hard disk, solid state drive, flash drive, magnetic data storage medium, any optical or physical data storage medium, memory chip, or the like.

Storage media is distinct from but may be used in conjunction with transmission media. Transmission media participates in transferring information between storage media. For example, transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise a bus of I/O subsystem 1102. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.

Various forms of media may be involved in carrying at least one sequence of at least one instruction to processor 1104 for execution. For example, the instructions may initially be carried on a magnetic disk or solid-state drive of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a communication link such as a fiber optic or coaxial cable or telephone line using a modem. A modem or router local to computer system 1100 can receive the data on the communication link and convert the data to a format that can be read by computer system 1100. For instance, a receiver such as a radio frequency antenna or an infrared detector can receive the data carried in a wireless or optical signal and appropriate circuitry can provide the data to I/O subsystem 1102 such as place the data on a bus. I/O subsystem 1102 carries the data to memory 1106, from which processor 1104 retrieves and executes the instructions. The instructions received by memory 1106 may optionally be stored on storage 1110 either before or after execution by processor 1104.

Computer system 1100 also includes a communication interface 1118 coupled to bus 1102. Communication interface 1118 provides a two-way data communication coupling to network link(s) 1120 that are directly or indirectly connected to at least one communication networks, such as a network 1122 or a public or private cloud on the Internet. For example, communication interface 1118 may be an Ethernet networking interface, integrated-services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of communications line, for example an Ethernet cable or a metal cable of any kind or a fiber-optic line or a telephone line. Network 1122 broadly represents a local area network (LAN), wide-area network (WAN), campus network, internetwork, or any combination thereof. Communication interface 1118 may comprise a LAN card to provide a data communication connection to a compatible LAN, or a cellular radiotelephone interface that is wired to send or receive cellular data according to cellular radiotelephone wireless networking standards, or a satellite radio interface that is wired to send or receive digital data according to satellite wireless networking standards. In any such implementation, communication interface 1118 sends and receives electrical, electromagnetic, or optical signals over signal paths that carry digital data streams representing various types of information.

Network link 1120 typically provides electrical, electromagnetic, or optical data communication directly or through at least one network to other data devices, using, for example, satellite, cellular, Wi-Fi, or BLUETOOTH technology. For example, network link 1120 may provide a connection through a network 1122 to a host computer 1124.

Furthermore, network link 1120 may provide a connection through network 1122 or to other computing devices via internetworking devices and/or computers that are operated by an Internet Service Provider (ISP) 1126. ISP 1126 provides data communication services through a worldwide packet data communication network represented as internet 1128. A server computer 1130 may be coupled to internet 1128. Server 1130 broadly represents any computer, data center, virtual machine, or virtual computing instance with or without a hypervisor, or computer executing a containerized program system such as DOCKER or KUBERNETES. Server 1130 may represent an electronic digital service that is implemented using more than one computer or instance and that is accessed and used by transmitting web services requests, uniform resource locator (URL) strings with parameters in HTTP payloads, API calls, app services calls, or other service calls. Computer system 1100 and server 1130 may form elements of a distributed computing system that includes other computers, a processing cluster, server farm or other organization of computers that cooperate to perform tasks or execute applications or services. Server 1130 may comprise one or more sets of instructions that are organized as modules, methods, objects, functions, routines, or calls. The instructions may be organized as one or more computer programs, operating system services, or application programs including mobile apps. The instructions may comprise an operating system and/or system software; one or more libraries to support multimedia, programming or other functions; data protocol instructions or stacks to implement TCP/IP, HTTP or other communication protocols; file format processing instructions to parse or render files coded using HTML, XML, JPEG, MPEG or PNG; user interface instructions to render or interpret commands for a graphical user interface (GUI), command-line interface or text user interface; application software such as an office suite, internet access applications, design and manufacturing applications, graphics applications, audio applications, software engineering applications, educational applications, games or miscellaneous applications. Server 1130 may comprise a web application server that hosts a presentation layer, application layer and data storage layer such as a relational database system using structured query language (SQL) or no SQL, an object store, a graph database, a flat file system or other data storage.

Computer system 1100 can send messages and receive data and instructions, including program code, through the network(s), network link 1120 and communication interface 1118. In the Internet example, a server 1130 might transmit a requested code for an application program through Internet 1128, ISP 1126, local network 1122 and communication interface 1118. The received code may be executed by processor 1104 as it is received, and/or stored in storage 1110, or other non-volatile storage for later execution.

The execution of instructions as described in this section may implement a process in the form of an instance of a computer program that is being executed and consisting of program code and its current activity. Depending on the operating system (OS), a process may be made up of multiple threads of execution that execute instructions concurrently. In this context, a computer program is a passive collection of instructions, while a process may be the actual execution of those instructions. Several processes may be associated with the same program; for example, opening up several instances of the same program often means more than one process is being executed. Multitasking may be implemented to allow multiple processes to share processor 1104. While each processor 1104 or core of the processor executes a single task at a time, computer system 1100 may be programmed to implement multitasking to allow each processor to switch between tasks that are being executed without having to wait for each task to finish. In an embodiment, switches may be performed when tasks perform input/output operations, when a task indicates that it can be switched, or on hardware interrupts. Time-sharing may be implemented to allow fast response for interactive user applications by rapidly performing context switches to provide the appearance of concurrent execution of multiple processes simultaneously. In an embodiment, for security and reliability, an operating system may prevent direct communication between independent processes, providing strictly mediated and controlled inter-process communication functionality.

In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may vary from implementation to implementation. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. The sole and exclusive indicator of the scope of the invention, and what is intended by the applicants to be the scope of the invention, is the literal and equivalent scope of the set of claims that issue from this application, in the specific form in which such claims issue, including any subsequent correction.

LOCALIZED FACILITY-SPECIFIC PRESENTATION OF DIGITAL TEMPORARY OFFER DATA AND DETAILS

Information

Publication Number

Date Filed

Date Published

Inventors

Original Assignees

CPC

International Classifications

Abstract

Description

Claims

BENEFIT CLAIM

Provisional Applications (1)