Local contextual display

A service provider system remembers feedback by a user when the user selects an offer, a presented option, or other content from a page or display on a user device. The user is then taken to a new page or screen with details about the offer, option, or other content. When the user goes back to the original page or screen, the page is revised based on the user feedback. For example, a dialog box may pop up over the selected offer to ask the user whether the user accepted the offer or is not interested in the offer. If so, the offer disappears and subsequent pages may not show the selected offer again.

BACKGROUND

Technical Field

The present application generally relates to online displays.

Related Art

Users of consumer devices, such as smart phones, PCs, and computing tablets, typically navigate through different screens on the device to achieve a desired goal, such as performing a transaction or obtaining information. A user may select rows, links or buttons that redirect the user to another screen for additional information or for the next step in a transaction. This continues until the user is satisfied with the information, completes the transaction, or otherwise ends the session.

DETAILED DESCRIPTION

In one embodiment, a service provider system remembers what was selected by a user when the user selects an offer, a presented option, or other content from a page or display on a user device. The user is then taken to a new page or screen with details about the offer, option, or other content. When the user goes back to the original page or screen, the page is revised based on the user selection. For example, a dialog box may pop up over the selected offer to ask the user whether the user accepted the offer or is not interested in the offer. If so, the offer disappears and subsequent pages may not show the selected offer again. The request to the user may also be shown as part of the interface, e.g., it changes the content of the row item from when the user was there last.

Thus, the user is provided pages that show contextual content or dialog based on what the user had previously selected or is not interested in, e.g., an inline (and/or in-flow) feedback loop that provides necessary feedback to the business, as well as enabling a more focused display of content based on that user feedback. This also enables a slicker and more user-friendly navigation for the user that eliminates content already seen or not liked by the user, resulting in a more relevant display and more efficient use of display size.

FIG. 1is a flowchart100showing a process a service or payment provider makes in presenting contextual display to a user according to one embodiment. At step102, the service provider displays a list of offers to a user on a user device. Offers may include incentives, coupons, discounts, gift cards, points, rewards, and the like. The user device may be a smart phone, PC, computing tablet, or other computing/communication device. In other embodiments, different content may be provided and is not limited to offers. For example, the user may be presented with ads, content related to a financial transaction, non-purchase related content (e.g., purely informational content), and the like. The offers may be presented when the user opens or launches an app on a user device or otherwise accesses a service provider site. The offers may be customized for the user, such as based on purchase history, preferences, previous actions, and/or current location. In one embodiment, the offers are presented before the user is authenticated by the service provider, e.g., simply launching the app without entering a password or PIN.

The offers may be presented as a list or an array, with a summary of the offer, such as merchant name and/or location, what the offer is (e.g., 30% off next purchase with the merchant), and expiration date. The user may be allowed to select the offer to view more details, such as by tapping, selecting a corresponding box, or otherwise selecting the offer from the user device. The selection is then communicated to the service provider, such as to a service provider server. The user may also or alternatively be allowed to communicate feedback on the offer. For example, the user may be able to select a button or link that indicates the user is not interested in the offer or that the user is interested in the offer. This information may be valuable if the user is interested in the offer, but not able to select the offer at the time the offer is presented. This can occur if the user does not have time to view the offer or is not a position to view the offer.

Once received, the selected offer is displayed to the user, at step104, on the user device. The displayed offer may be on a new screen or page of the user device and contain details of the offer. Details may include conditions of use, expiration date, how to use or accept the offer, terms of the offer, and locations where the offer can be redeemed in person. These and other information may be viewed by the user in another screen or display, such as by the user selecting a button, tab, or link associated with the desired information. An offer details page may also enable the user to accept the offer, such as by selecting an appropriate link, button, or tab. Once selected, the offer may be stored with the user's digital wallet or account to be applied or used when the corresponding purchase is made. The user may also communicate other information about the offer, such as whether the user is interested in the offer, not interested in the offer, not interested in offers from same merchant, not interested in similar offers from other merchants, etc. The information may be communicated with a button or link associated with the offer. The offer or ad may also be used manually, offline, or not through an app, such as by the user showing the offer to a merchant, who processes the offer accordingly, such as manually or through a scan.

Once the user is finished viewing the selected offer or indicates the offer is not of interest, the user may desire to go back to the original list of offers page, such as by selecting a “back” or “home” button or link. This electronically communicates a request of the user to the service provider, who receives the request at step106.

The service provider then processes the request, but instead of displaying the original page of step102, displays a revised list or page, at step108, based on the user's navigation and/or selection of step104. The service provider remembers the user's selected offer and any relevant information received about the offer (such as a non-interest indication) and revises the page accordingly. For example, the selected offer may have a dialog or pop-up box asking whether the user accepted or used the offer. Other examples include whether the user wishes to see the offer again or wishes to see similar offers from the same merchant or similar merchants. One or more boxes, links, or tabs may be included that enable the user to select the desired answer(s), such as by tapping or clicking on the appropriate box, link or tab.

At step110, the service provider receives the user response and displays an updated display, at step112, if appropriate. For example, if the user did not use or accept the offer, the display may remain unchanged from the list of step102, especially if the user had indicated that the user is interested in the offer or wants to keep receiving the offer. However, if the user response indicated that the user used/accepted the offer or otherwise does not want to see the offer again, the updated display would not include the offer. As such, the user is provided a less cluttered and more relevant display, responsive to one or more user actions.

The information received from the user, such as at step110, may be used by the service provider to dynamically change the offer display in the future. This enables the service provider to provide current and up-to-date relevant ads for the user and to provide displays that accurately reflect a user interest in an offer. Ads can include offers and not just awareness. For example, an ad from a specific merchant or a type of ad may have been of interest at one point, but is no longer of interest. In that case, the user will not want to go back to a page or screen and see the same or similar ads any more. By changing the offer display page and “back” page based on current user actions, the user is presented with more relevant displays.

Note that one or more steps described herein may be omitted, combined, or performed in a different sequence as desired.

FIGS. 2A-2Hare exemplary screen shots a user may see during a sequence of displays on a smart phone according to one embodiment. InFIG. 2A, a list of offers is presented on a display of a user device, such as when the user logs into the user account with the service provider, accesses the app of the service provider, a home screen widget, or simply turns on the display for the user device. The offers are sorted by date (expiration date), but can be sorted by other criteria, such as proximity to user, value of offer, favorite merchants of user, etc. As seen, the offers include merchant names, a brief description of the offer, and an expiration date of the offer. InFIG. 2A, the user selects the first offer from Store A by tapping on the offer.

FIG. 2Bshows the next screen with more details of the offer, including a box the user can select to apply the offer to the next qualifying purchase. Details include the offer ($5 off) and conditions of the offer (minimum purchase of $25 at Store A), expiration date, ability to use automatically with next qualifying purchase (by checking a corresponding box), and instructions on how the offer is used. The screen also includes tabs at the bottom for additional details of Terms, Offer, and Locations. Note that the Offer tab is highlighted as the currently selected or displayed tab.

FIG. 2Cis a screen the user sees when the user selects, such as by tapping, the “Terms” tab. The terms screen provides terms and conditions for the offer, including an expiration or “use by” date.

FIG. 2Dshows a screen of merchant locations or locations the offer can be used at, when the user selects the “Locations” tab. The list of locations is shown with the nearest location at the top and additional locations underneath. Other ways to display or order locations can also be used, such as on a map, ordered by distance from the current user location (such as determined by the user device location), ordered by distance from the user home address, ordered by distance from the expected user location (based on a user specified location), ordered by distance from the user work address, etc. The location information includes address, city, and phone number. The list may include an address, phone number and corresponding map, as well as store hours.

Once the user is finished with the offer, the user selects a “back” or “home” button (shown as a back arrow on the upper portion of the display inFIG. 2D, which takes the user back to the list of offers, which may be the immediate previous screen or several screens back, depending on how many pages or screens the user viewed after selecting the offer.

FIG. 2Eshows the revised screen with an inline form requesting feedback regarding the offer. This could also be achieved with a pop-up or dialog box as the interactive element. The pop-up appears over the previously selected offer, which may be highlighted if desired. The pop-up includes a box the user can tap. In this case, there is a “Yes” button. In other embodiments, there may be a “No”, an “Ignore” and/or other responses as appropriate to the question asked of the user. The button could be substituted with a check box, radio buttons, etc. The question may be different, such as whether the user is interested in this offer, other offers by the same merchant, or similar offers by other merchants.

FIG. 2Fshows a screen where the user ignores the question (or indicates interest in the offer, but has not accepted or used the offer) and scrolls through other offers. This results in the selected offer remaining on the offers list page. Even though not selected or used, the selected offer may be highlighted or visually identified as an offer the user has already viewed, which can save the user time by not viewing the offer again at a later time thinking that it is a new offer.FIG. 2Falso shows that moving the selected offer off screen dismisses or removes the inline feedback form or pop-up.

FIG. 2Gshows a screen where the user selects, by tapping, the “Yes” box to indicate that the offer was used. If the user moves the selected Store A offer off the display (e.g. by tapping “Yes”), such as to view more offers on the list, the request disappears. In one embodiment, the request reappears when the user scrolls to place or move the selected offer back on the screen or display since the user indicated that they had used the offer, the offer no longer appears within the list. It is assumed in this case that the offer was a “one time use” offer.

FIG. 2Hshows a screen where the previously selected offer is removed from the list and no longer shown to the user because the user has already used the offer. Responses to other questions may also result in the offer being removed, such as an indication the user is not interested in the offer or the offer has expired.

FIG. 3is a block diagram of a networked system300configured for displaying content, such as offers, as described above, in accordance with an embodiment of the invention. System300includes a user device310and a payment provider server370in communication over a network360. Payment provider server370may be maintained by a payment provider, such as PayPal, Inc. of San Jose, Calif. Although a payment provider device is shown, the server may be managed or controlled any suitable service provider that requires authentication as a human before communicating information. A user305utilizes user device310to view account information and perform transactions using payment provider server370. Note that transaction, as used herein, refers to any suitable action performed using the user device, including payments, transfer of information, display of information, etc. Although only one server is shown, a plurality of servers may be utilized. Exemplary servers may include, for example, stand-alone and enterprise-class servers operating a server OS such as a MICROSOFT® OS, a UNIX® OS, a LINUX® OS, or other suitable server-based OS. One or more servers may be operated and/or maintained by the same or different entities.

Network360may be implemented as a single network or a combination of multiple networks. For example, in various embodiments, network360may include the Internet or one or more intranets, landline networks, wireless networks, and/or other appropriate types of networks.

User device310may be implemented using any appropriate hardware and software configured for wired and/or wireless communication over network360. For example, in one embodiment, the user device may be implemented as a personal computer (PC), a smart phone, personal digital assistant (PDA), laptop computer, and/or other types of computing devices capable of transmitting and/or receiving data, such as an iPad™ from Apple™.

User device310may include one or more browser applications315which may be used, for example, to provide a convenient interface to permit user305to browse information available over network360. For example, in one embodiment, browser application315may be implemented as a web browser configured to view information available over the Internet, such as offers presented by the payment provider. User device310may also include one or more toolbar applications320which may be used, for example, to provide client-side processing for performing desired tasks in response to operations selected by user305. In one embodiment, toolbar application320may display a user interface in connection with browser application315.

User device310may further include other applications325as may be desired in particular embodiments to provide desired features to user device310. For example, other applications325may include security applications for implementing client-side security features, programmatic client applications for interfacing with appropriate application programming interfaces (APIs) over network360, or other types of applications. Applications325may also include email, texting, voice and IM applications that allow user305to send and receive emails, calls, and texts through network360, as well as applications that enable the user to communicate and transfer information through and with the payment provider as discussed above. User device310includes one or more user identifiers330which may be implemented, for example, as operating system registry entries, cookies associated with browser application315, identifiers associated with hardware of user device310, or other appropriate identifiers, such as used for payment/user/device authentication. In one embodiment, user identifier330may be used by a payment service provider to associate user305with a particular account maintained by the payment provider. A communications application322, with associated interfaces, enables user device310to communicate within system300.

Payment provider server370may be maintained, for example, by an online payment service provider which may provide information to and receive information from user305, such as for making payments, viewing offers, and responding to offers. In this regard, payment provider server370includes one or more payment applications375which may be configured to interact with user device310over network360to facilitate offer transactions with user305of user device310.

Payment provider server370also maintains a plurality of user accounts380, each of which may include account information385associated with consumers, merchants, and funding sources, such as credit card companies. For example, account information385may include private financial information of users of devices such as account numbers, passwords, device identifiers, user names, phone numbers, credit card information, bank information, identification cards, photos, offers available to the user, or other information which may be used to facilitate transactions by user305.

A transaction processing application390, which may be part of payment application375or separate, may be configured to receive information from a user device for processing and storage in a payment database395. Transaction processing application390may include one or more applications to process information from user305for processing a payment or transfer using various selected funding instruments or cards. As such, transaction processing application390may store details of payment transfer from individual users, including funding source(s) used, offers, credit options available, etc. to other individuals or entities. Payment application375may be further configured to determine the existence of and to manage accounts for user305, as well as create new accounts if necessary, such as the set up and management payments by the user.

FIG. 4is a block diagram of a computer system400suitable for implementing one or more embodiments of the present disclosure. In various implementations, the user device may comprise a personal computing device (e.g., smart phone, a computing tablet, a personal computer, laptop, PDA, Bluetooth device, key FOB, badge, etc.) capable of communicating with the network. The payment provider may utilize a network computing device (e.g., a network server) capable of communicating with the network. It should be appreciated that each of the devices utilized by users and payment providers may be implemented as computer system400in a manner as follows.

Computer system400includes a bus402or other communication mechanism for communicating information data, signals, and information between various components of computer system400. Components include an input/output (I/O) component404that processes a user action, such as selecting keys from a keypad/keyboard, selecting one or more buttons, image, or links, and/or moving one or more images, etc., and sends a corresponding signal to bus402. I/O component404may also include an output component, such as a display411and a cursor control413(such as a keyboard, keypad, mouse, etc.). An optional audio input/output component405may also be included to allow a user to use voice for inputting information by converting audio signals. Audio I/O component405may allow the user to hear audio. A transceiver or network interface406transmits and receives signals between computer system400and other devices, such as another user device, a merchant server, or a payment provider server via network360. In one embodiment, the transmission is wireless, although other transmission mediums and methods may also be suitable. One or more processors412, which can be a micro-controller, digital signal processor (DSP), or other processing component, processes these various signals, such as for display on computer system400or transmission to other devices via a communication link418. Processor(s)412may also control transmission of information, such as cookies or IP addresses, to other devices.

Components of computer system400also include a system memory component414(e.g., RAM), a static storage component416(e.g., ROM), and/or a disk drive417. Computer system400performs specific operations by processor(s)412and other components by executing one or more sequences of instructions contained in system memory component414. Logic may be encoded in a computer readable medium, which may refer to any medium that participates in providing instructions to processor(s)412for execution. Such a medium may take many forms, including but not limited to, non-volatile media, volatile media, and transmission media. In various implementations, non-volatile media includes optical or magnetic disks, volatile media includes dynamic memory, such as system memory component414, and transmission media includes coaxial cables, copper wire, and fiber optics, including wires that comprise bus402. In one embodiment, the logic is encoded in non-transitory computer readable medium. In one example, transmission media may take the form of acoustic or light waves, such as those generated during radio wave, optical, and infrared data communications.

In various embodiments of the present disclosure, execution of instruction sequences to practice the present disclosure may be performed by computer system400. In various other embodiments of the present disclosure, a plurality of computer systems400coupled by communication link418to the network (e.g., such as a LAN, WLAN, PTSN, and/or various other wired or wireless networks, including telecommunications, mobile, and cellular phone networks) may perform instruction sequences to practice the present disclosure in coordination with one another.