Techniques for mitigating errors associated with software applications

Abstract

To provide a method for mitigating errors tied to software applications and a server device.SOLUTION: The method includes the steps of: identifying a user having an invalid payment credential associated with a software application; identifying at least one client device associated with the user and on which the software application is installed; providing at least one client device with an indication of at least one error to cause the software application to, in conjunction with being loaded and / or displayed on at least one client device, display a user interface including information derived from the indication, and sandboxing the user interface from the software application so as to prevent the software application from observing activity that occurs within the user interface.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] The described embodiments describe techniques for mitigating errors associated with software applications. For example, the techniques provide a framework for notifying users of a software application when their payment credentials become invalid and allowing the users to update their payment credentials to mitigate the invalidity. [Background technology]

[0002] Recent years have shown a rapid increase in the number of individuals who own and operate computing devices (e.g., wearables, smartphones, tablets, etc.). Typically, individuals use computing devices to perform various activities throughout the day, such as making phone calls, sending and receiving electronic messages, and accessing the Internet. In some cases, the operating system installed on the computing device (particularly the native software applications pre-installed on the operating system) may enable the user to perform the aforementioned activities. However, third-party software applications may also be installed to enable the user to perform additional / enhanced activities. For example, these software applications may include social networking software applications, photography software applications, gaming software applications, etc.

[0003] A common approach for making software applications available to users of computing devices involves providing a software application store, referred to herein as an “app store,” which allows users to download software applications to their computing devices. Specifically, app stores allow software application developers to upload their software applications to the app store along with descriptions, pricing information, screenshots, etc. Users can then utilize the app store to search for and install software applications that are useful / interesting to them. For example, a user can submit a search query with specific keywords for software applications they are interested in downloading, see all software applications that belong to a particular category of interest (e.g., games), etc. In another example, an app store can display software applications ranked according to various criteria (e.g., top downloaded software applications, top ranked software applications, etc.) to allow users to identify software applications that are currently popular among all users.

[0004] To maximize user satisfaction, it is important that software applications perform without problems. In particular, payment structures for software applications vary widely depending on their design, their intended users, etc. For example, some software applications are free to use, some offer "in-app purchases," some require upfront and / or subscription payments, etc. In this regard, maintaining valid customer billing information is important for maintaining the on-time and successful completion of software application payments. Such billing information may include, for example, a valid credit or debit card number, a valid expiration date, and a valid billing address. Without valid billing information, payments cannot be processed, which can strain revenue streams and potentially block access to functionality expected by users. Additionally, when billing issues arise, it can be difficult to notify users in an effective and non-intrusive manner. In this regard, software developers may not know the most efficient techniques for notifying users of billing issues and recommending / facilitating remediation. Summary of the Invention

[0005] The described embodiments describe techniques for mitigating errors associated with software applications. For example, the techniques provide a framework for notifying users of a software application when their payment credentials become invalid and allowing the users to update their payment credentials to mitigate the invalidity.

[0006] Embodiments describe a method for mitigating an error associated with a software application. According to some embodiments, the method may be implemented on a server device and includes: (1) identifying at least one error associated with a user of the software application; (2) identifying at least one client device associated with the user and on which the software application is installed; and (3) providing an indication of the at least one error to the at least one client device to cause the software application to display a user interface including information derived from the indication in conjunction with being loaded and / or displayed on the at least one client device, wherein the user interface is sandboxed from the software application to prevent the software application from observing activity occurring within the user interface.

[0007] Another embodiment describes a method for mitigating errors associated with a software application. According to some embodiments, the method may be implemented on a client device and includes: (1) receiving, from a server device, an indication of at least one error associated with a software application installed on the client device; (2) storing the indication; (3) detecting launch and / or display of the software application; (4) prompting the software application for permission to display information associated with the indication of the at least one error; and (5) in response to receiving permission from the software application, causing the software application to display a user interface including the information, wherein the user interface is sandboxed from the software application to prevent the software application from observing activity occurring within the user interface.

[0008] Other embodiments include a non-transitory computer-readable storage medium configured to store instructions that, when executed by a processor included in the computing device, cause the computing device to perform various steps of any of the aforementioned methods. Further embodiments include a computing device configured to perform various steps of any of the aforementioned methods.

[0009] Other aspects and advantages of the present embodiments described herein will become apparent from the following detailed description, taken in conjunction with the accompanying drawings, which illustrate, by way of example, the principles of the described embodiments.

[0010] The included drawings are for illustrative purposes and merely serve to present examples of possible structures and configurations of the disclosed inventive apparatus and method for providing a wireless computing device. These drawings in no way limit any changes in form and detail that may be made to the present embodiments by one skilled in the art without departing from the spirit and scope of the present embodiments. The present embodiments can be readily understood by reading the following "Detailed Description" in conjunction with the accompanying drawings, in which like reference numerals refer to like structural elements. [Brief explanation of the drawings]

[0011] [Figure 1] FIG. 1 illustrates a block diagram of different components of a system that may be configured to implement various techniques described herein, according to some embodiments.

[0012] [Figure 2] 1 illustrates a detailed sequence diagram of a technique for mitigating errors associated with software applications, according to some embodiments.

[0013] [Figure 3A] 1 illustrates a method for mitigating errors associated with a software application, according to some embodiments. [Figure 3B]1 illustrates a method for mitigating errors associated with a software application, according to some embodiments.

[0014] [Figure 4A] 1 illustrates a conceptual diagram of an exemplary user interface that may be displayed on a client computing device according to some embodiments. [Figure 4B] 1 illustrates a conceptual diagram of an exemplary user interface that may be displayed on a client computing device according to some embodiments.

[0015] [Figure 5] FIG. 1 shows a detailed diagram of a computing device that can be used to execute various components described herein, according to some embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0016] Representative applications of the apparatus and methods according to the embodiments described herein are presented in this section. These examples are provided solely to add context and to aid in understanding the described embodiments. Thus, it will be apparent to one of ordinary skill in the art that the embodiments described herein can be practiced without some or all of these specific details. In other instances, well-known process steps have not been described in detail to avoid unnecessarily obscuring the embodiments described herein. Other applications are possible, and therefore the following examples should not be construed as limiting.

[0017] The described embodiments describe techniques for mitigating errors associated with software applications. For example, the techniques provide a framework for notifying users of a software application when their payment credentials become invalid and allowing the users to update their payment credentials to mitigate the invalidity.

[0018] It should be noted that while the following disclosure focuses primarily on payment-related errors associated with software applications, the embodiments are by no means limited in scope as such. On the contrary, the embodiments are applicable to all possible errors, problems, etc. that may arise in connection with software applications, such as errors, problems related to user accounts, billing, configuration, etc.

[0019] FIG. 1 illustrates a block diagram of different components of a system 100 capable of implementing various techniques described herein, according to some embodiments. As shown in FIG. 1, the system 100 may include one or more server computing devices 102 that enable users of client computing devices 114, e.g., smartphones, tablets, laptops, desktops, etc., to access a software application store (not shown in FIG. 1 ) hosted by the server computing device 102. In some embodiments, the software application store may allow software developers to upload software applications 104 that are made available through the software application store. Conversely, the client computing devices 114 may execute corresponding software applications (not shown in FIG. 1 ), referred to herein as software application store clients, that enable the client computing devices 114 to interface with the software application store implemented by the server computing device 102. For example, the software application store clients (executing on a given client computing device 114) may allow users to browse for software applications 104 that they may be interested in downloading and installing, e.g., productivity software applications, social networking software applications, gaming software applications, etc. Then, when a user identifies a particular software application 104 of interest, the software application store client can cause the client computing device 114 to seamlessly download and install the software application 104 onto the client computing device 114. The user can then access the software application 104 on their client computing device 114.

[0020] Briefly, it should be noted that the embodiments disclosed herein are not limited to the aforementioned architectures including a software application store / software application store client. Conversely, the server computing device 102 may be configured to provide various functionality described herein that is independent of, or not present in, a software application store implementation. For example, the server computing device 102 may be configured to help identify and mitigate payment credential issues that arise in connection with the use of a software application 104 on the client computing device 114. Furthermore, the client computing device 114 may be configured to provide various functionality described herein that is independent of, or not present in, a software application store client implementation. For example, the client computing device 114 may be configured to install, load, display, etc., a software application 104 without interfacing with a software application store (commonly referred to as “sideloading”) and may be configured to interface with the server computing device 102 to benefit from the payment credential issue identification / mitigation techniques described herein.

[0021] In either case, as shown in FIG. 1 , each client computing device 114 may have any number of software applications 104 installed and may implement a software application manager 116 configured to facilitate the installation, execution (e.g., loading, displaying, etc.) of the software applications 104. Each client computing device 114 may also be associated with a user profile 106. Such an association may be established, for example, when a user of the client computing device 114 provides the information necessary to create, log in, etc. the user profile 106 using the client computing device 114. According to some embodiments, a user's user profile 106 may include username / password information, contact information associated with the user, demographic information associated with the user, etc. Note that the foregoing examples are not intended to be limiting, and the user profile 106 may store any user-related (or other) information at any level of granularity without departing from the scope of the present disclosure. The user profile 106 may also include one or more payment credentials 108 associated with the user, which may include credit card information, gift card information, debit card information, bank account information, etc. It should be noted that the foregoing examples are not intended to be limiting, and payment credentials 108 may store any payment-related (or other) information at any level of granularity without departing from the scope of this disclosure.

[0022] As shown in FIG. 1 , the server computing device 102 can associate any number of user profiles 106 with a given software application 104. Such an association may be formed, for example, between a given software application 104 and a user profile 106 of a user who has installed the software application 104 on at least one client computing device 114. Although not shown in FIG. 1 , the server computing device 102 can manage information that enables a given user to use different payment credentials 108 for different software applications 104. For example, a user may prefer to utilize a first payment credential 108 to provide payment for a first software application 104 and a second payment credential 108 to provide payment for a second software application 104. In this regard, the server computing device 102 can store, for each user profile 106 associated with a given software application 104, information indicating the user's preferred payment credential 108 for the software application 104, e.g., along with the software application 104, the user profile 106, etc.

[0023] Additionally, the server computing device 102 can be configured to implement a payment credential manager 110 that evaluates the validity of the payment credentials 108 associated with the user profile 106. In some cases, the payment credential manager 110 can self-determine the validity of a given payment credential 108. For example, if the current date exceeds the expiration date of the payment credential 108, the payment credential manager 110 can reliably conclude that the payment credential 108 is invalid. In another example, if an available credit limit, credit limit, or the like is insufficient to cover an upcoming payment (e.g., an upcoming subscription fee to be paid), the payment credential manager 110 can reliably conclude that the payment credential is invalid.

[0024] In other cases, the payment credential manager 110 may interface with the payment processor 112 to determine whether a payment credential is valid. For example, the payment credential manager 110 may provide a given payment credential 108 to the payment processor 112 and receive an indication regarding the validity of the payment credential 108. Such provision of the payment credential 108 may be performed, for example, periodically, conditionally, etc. In another example, the payment credential manager 110 may be notified by the payment processor 112 when a given payment credential 108 becomes invalid. Such notification may occur, for example, when the payment credential manager 110 attempts to facilitate a transaction using a payment credential 108 that is invalid according to the payment processor 112. It should be noted that the foregoing examples are not meant to be limiting, and any technique may be utilized by the server computing device 102 to effectively identify an invalid payment credential 108.

[0025] According to some embodiments, upon identifying that a given payment credential 108 is invalid, the payment credential manager 110 can take any number of actions to correct the problem. As shown in FIG. 1 , such actions can include providing one or more invalid payment credential indications 118, if appropriate. For example, the server computing device 102 can identify one or more software applications 104 affected by the invalid payment credential 108. The identified one or more software applications 104 can include, for example, those with subscription fees, renewal fees, upgrade fees, etc., that are due within a threshold period and rely on the payment credential 108 for payment. The server computing device 102 can then identify one or more client computing devices 114 on which the one or more software applications 104 are installed. The server computing device 102 can then provide the invalid payment credential indications 118 to the software application manager 116 on the identified one or more client computing devices 114. In this manner, the software application manager 116 can effectively notify users of the problem as well as provide a means for resolving the problem, as described in more detail herein.

[0026] It should be understood that the various components of the computing devices shown in FIG. 1 are presented at a high level for simplicity. For example, although not shown in FIG. 1, it should be understood that the various computing devices may include common hardware / software components that enable the software entities described above to be implemented. For example, each of the computing devices may include one or more processors, in conjunction with one or more volatile memories (e.g., dynamic random access memories (DRAMs)) and one or more storage devices (e.g., hard drives, solid-state drives (SSDs), etc.), that enable the various software entities described herein to be executed. Furthermore, each of the computing devices may include communications components that enable the computing devices to transmit information between each other (e.g., using the Internet).

[0027] A more detailed description of these hardware components is provided below in connection with Figure 5. It should be further understood that a computing device may include additional entities that enable implementation of the various techniques described herein without departing from the scope of the present disclosure. In addition, it should be understood that the entities described herein may be combined or divided into additional entities without departing from the scope of the present disclosure. It should be further understood that the various entities described herein may be implemented using software-based or hardware-based techniques without departing from the scope of the present disclosure.

[0028] 1 thus provides an overview of the manner in which system 100, and in particular server computing device 102 and client computing device 114, may implement various techniques described herein, according to some embodiments. A more detailed breakdown of how these techniques may be implemented is then provided below in connection with FIGS. 2, 3A-3B, and 4A-4B.

[0029] 2 shows a detailed sequence diagram of a technique for mitigating errors tied to a software application, according to some embodiments. As shown in FIG. 2, the sequence diagram begins at step 202, where a server computing device 102, e.g., a payment credential manager 110 running on the server computing device 102, determines that a user's payment credential 108 associated with the software application 104 is invalid. The payment credential manager 110 can make this determination using any of the techniques described herein, for example, by self-determining the invalidity, or by receiving instructions from a payment processor 112.

[0030] In step 204, the payment credential manager 110 provides an indication of the invalid payment credential 108 to a software application manager 116 running on the client computing device 114 on which the software application 104 is installed. According to some embodiments, the indication may be associated with a unique identifier that is also associated with the software application 104. Briefly, it should be noted that for simplicity, the embodiments and examples described herein primarily describe the server computing device 102 / payment credential manager 110 interacting with a single client computing device 114. However, as discussed above in connection with FIG. 1 , the payment credential manager 110 can provide an indication to other software application managers 116 on other client computing devices 114 on which the software application 104 is also installed. This can be useful when the software application 104 is installed on more than one client computing device 114 of the same user, in that it can notify the user of a problem (described below) on whichever client computing device 114 the user happens to be operating.

[0031] In step 206, the software application manager 116 receives the instructions from the payment credential manager 110 and stores the instructions in storage accessible to the client computing device 114 (e.g., local storage, network storage, cloud storage, etc.). Again, when the instructions are sent to multiple client computing devices 114, each client computing device 114 may store the instructions using the techniques described above (or an alternative technique appropriate to the configuration of the client computing device 114).

[0032] At step 208, the software application 104 is loaded and / or displayed on the client computing device 114. As shown in FIG. 2, the loading and / or displaying of the software application 104 may involve both the software application 104 and the software application manager 116. For example, the software application manager 116 may receive a request to load and / or display the software application 104 (e.g., through selection of an icon associated with the software application 104) and then take appropriate action to process the request. The request may be issued, for example, when a user of the client computing device 114 utilizes a user interface to load and / or display the software application 104 for the first time (since the last reset of the client computing device 114) and (after being loaded). In this regard, as described in more detail below, the software application manager 116 may identify, based on instructions stored in connection with step 206, whether additional action should be taken in response to the software application 104 being loaded and / or displayed.

[0033] In step 210, the software application manager 116 identifies the instructions (received / stored in step 206) in conjunction with the loading and / or display of the software application 104. Identification may be accomplished, for example, by determining whether a unique identifier associated with the software application 104 matches a unique identifier of any of the instructions stored on the client computing device 114. Then, in response to identifying the instructions with a matching identifier, the software application manager 116 issues a request for payment credential revocation information to the payment credential manager 110.

[0034] At step 212, the payment credential manager 110 provides the invalid payment credential information to the software application manager 116. The invalid payment credential information can encompass any information at any level of granularity effective for informing a user of the nature of the problem with the payment credential 108. For example, the invalid payment credential information can include a uniform resource locator (URL) to a web page that, when rendered on the client computing device 114, effectively communicates the nature of the problem with the payment credential 108. In another example, the invalid payment credential information can include hypertext markup language (HTML) code that, when rendered on the client computing device 114, constitutes a web page that effectively communicates the nature of the problem with the payment credential 108. In yet another example, the invalid payment credential information can include binary (e.g., blob) information that, when rendered on the client computing device 114, constitutes an image, video, interactive user interface, etc. that, when rendered on the client computing device 114, effectively communicates the nature of the problem with the payment credential 108. It should be noted that the above examples are not intended to be limiting, and the payment credential invalidation information may take any form effective in communicating the nature of the problem with the payment credential without departing from the scope of this disclosure.

[0035] Additionally, the invalid payment credential information can encompass any information at any level of granularity effective to enable a user to mitigate issues with a payment credential. For example, the invalid payment credential information can include a URL to a web page that, when rendered on the client computing device 114, enables a user to update the payment credential 108, provide new payment credential 108, etc. In another example, the invalid payment credential information can include HTML code that, when rendered on the client computing device 114, configures a web page that, when rendered on the client computing device 114, enables a user to update the payment credential 108, provide new payment credential 108, etc. In yet another example, the invalid payment credential information can include binary (e.g., blob) information that, when rendered on the client computing device 114, configures an interactive user interface that, when rendered on the client computing device 114, enables a user to update the payment credential 108, provide new payment credential 108, etc. It should be noted that the foregoing examples are not intended to be limiting, and the invalid payment credential information can take any form that can be used to effectively enable a user to mitigate issues with a payment credential 108 without departing from the scope of this disclosure.

[0036] It should be noted that the payment credential invalidation information may be formatted using any technique without departing from the scope of the present disclosure. For example, each software application 104 may be associated with an individual template in which the payment credential invalidation information may be formatted. In another example, a particular template may be used for a particular type of software application 104; for example, a first template may be used for subscription-based software applications 104, a second template may be used for software applications 104 that offer in-app purchases, etc. It should be noted that the foregoing examples are not intended to be limiting, and the server computing device 102 may utilize any number of templates (and the like) at any level of granularity / specificity without departing from the scope of the present disclosure.

[0037] Briefly, although not shown in FIG. 2 , the payment credential manager 110 can redundantly determine whether the payment credential 108 is still invalid (e.g., by re-executing step 202) before providing the payment credential invalid information. This can be useful in scenarios where the payment credential 108 transitions from invalid to valid at any time between steps 202 and 210. Such a transition can occur, for example, when an account freeze is lifted, a gift card balance is increased, an available credit limit is increased, etc. When this occurs / whenever this occurs, the payment credential manager 110 can instead provide an indication in step 212 that the payment credential 108 is valid. The software application manager 116 can then delete the indication from storage, and the remaining steps in the sequence diagram of FIG. 2 can be ignored.

[0038] Returning now to FIG. 2 , at step 214, the software application manager 116 issues a request to the software application 104 for permission to display the invalid payment credential information. The request may be provided to the software application 104 using any technique effective for enabling software entities on the client computing device 114 to communicate with each other. For example, the software application manager 116 / software application 104 may implement a software development kit (SDK), application programming interface (API), etc. that enables (1) the software application manager 116 to send the request to the software application 104, and (2) the software application 104 to receive / interpret the request. Beneficially, such a request may provide an authorized entity (e.g., developer, distributor, etc.) associated with the software application 104 with the ability to suppress the display of the invalid payment credential information. This may be useful, for example, when the authorized entity plans to enhance the software application 104's features, its pricing, etc., and prompting the user for payment after the update is made is likely to result in the user updating their payment credentials 108 so that payment can be made.

[0039] Next, in step 216, the software application 104 grants permission to the software application manager 116. According to some embodiments, the software application 104 may grant permission using the same (or a different) technique as used to send the request described above in connection with step 214. It should be noted that when the software application 104 denies permission, the software application manager 116 may take a variety of actions. In one example, the software application manager 116 may maintain instructions in storage such that steps 210-214 are performed each time step 208 is performed. In another example, the software application manager 116 may choose to prompt the software application 104 periodically (e.g., every time, every other time, etc.) each time the software application 104 is loaded / displayed in light of the permission denial. It should be noted that the foregoing examples are not meant to be limiting, and the software application manager 116 may take any action in any form in response to receiving a denial from the software application 104 without departing from the scope of the present disclosure.

[0040] In step 218, the software application manager 116 instructs the software application 104 to display the payment credential invalid information. This step may be implemented using the same (or a different) technique used to send the request / authorization described above in connection with steps 214 / 216, respectively.

[0041] In step 220, the software application manager 116 / software application 104 displays (1) the payment credential invalidity information and (2) techniques (i.e., mechanisms) for mitigating the invalidity from the software application 104 via a sandboxed user interface. Briefly, as described herein, sandboxing a user interface from the software application 104 involves prohibiting the software application 104 from viewing activities occurring within the user interface. Such activities may include, for example, displaying the payment credential invalidity information, receiving input (e.g., updated payment credentials), etc. In this manner, the software application 104 may understand (e.g., via steps 214 and 216) that a billing issue has occurred but remain blind to the specific nature of the billing issue and any remedial measures pursued via the user interface.

[0042] To achieve the sandboxing restrictions described herein, a first exemplary approach may include displaying the invalid payment credential information within a window (e.g., as an overlay) of the software application 104's user interface. This may be achieved, for example, by instructing the software application 104 (e.g., through an API, SDK, etc. described herein) to allow the software application 104 to display windows to which the software application 104 does not have access. In another example, step 220 may include displaying the invalid payment credential information within a user interface separate and distinct from the software application 104, such as a user interface controlled by the software application manager 116, the operating system of the client computing device 114, etc. Under this approach, the software application 104 would naturally be prohibited from accessing a user interface if the user interface is managed outside of the software application 104's scope. It should be noted that the foregoing example is not meant to be limiting, and any approach may be utilized to effectively display the invalid payment credential information to a user of the client computing device 114.

[0043] In step 222, the software application manager 116 provides updated payment credential information to the payment credential manager 110. According to some embodiments, step 222 may be performed in response to the software application manager 116 receiving the updated payment credential information through a user interface displayed in conjunction with step 220. Note, however, that the sequence diagram of FIG. 2 can be modified when the user interface of 220 displays a web page linked to a URL. Under such an approach, the updated payment credential is received by an alternative entity, thereby eliminating the need for step 222 to be implemented. Instead, the payment credential manager 110 can receive the updated payment credential from the alternative entity and perform the remaining steps of the sequence diagram of FIG. 2, as appropriate.

[0044] In step 224, the payment credential manager 110 interfaces with one or more payment processors 112 to verify that the updated payment credentials are valid. As described herein, this step may include, for example, attempting to charge due payments against the updated payment credentials, requesting confirmation that the updated payment credentials are valid for future due payments, etc. Note that the foregoing examples are not meant to be limiting, and any technique may be used to validate updated payment credentials for the context of a billing issue without departing from the scope of the present disclosure.

[0045] In step 226, the payment credential manager 110 provides an indication to the software application manager 116 that the updated payment credential information is valid. Then, in step 228, the payment credential manager 110 / software application 104 displays a notification in the user interface (described above in connection with step 220) that the updated payment credential information is valid. In step 230, the software application manager 116 deletes the instructions stored in connection with step 206. Note that when the instructions provided in step 204 are provided to more than one client computing device 114, deleting the instructions on one client computing device 114 may cause the other client computing devices 114 to also remove the instructions (e.g., through direct communication, through the server computing device 102, etc.). In this way, the software application 104 is not incorrectly notified of a billing problem when subsequent loading and / or display of the software application 104 occurs.

[0046] Further, it should be noted that if the payment credential manager 110 receives an indication from the payment processor 112 that the updated payment credentials are invalid, it can implement appropriate adjustments to steps 226-228. In particular, in step 226, the payment credential manager 110 can provide an indication to the software application manager 116 that the updated payment credentials are invalid. Then, in step 228, the payment credential manager 110 / software application 104 can also display a notification in the user interface (described above in connection with step 220) that the updated payment credentials are invalid so that an appropriate correction can be provided. When such a correction is provided, steps 222-228 can be re-executed until valid updated payment credentials are obtained. Then, in step 230, the software application manager 116 can delete the instruction stored in connection with step 206, as described herein.

[0047] Accordingly, Figure 2 shows a detailed sequence diagram of a technique for mitigating errors tied to software applications, according to some embodiments. Figure 3, described below, shows a high-level method diagram of steps that may be implemented by the server computing device 102 / payment credential manager 110, according to some embodiments. Figure 4, also described below, shows a high-level method diagram of steps that may be implemented by the client computing device 114 / software application manager 116, according to some embodiments. Finally, Figures 4A-4B show conceptual diagrams of example user interfaces that may be implemented in accordance with the techniques described herein, according to some embodiments.

[0048] 3A illustrates a method 300 for mitigating errors associated with a software application, according to some embodiments. As shown in FIG. 3, method 300 begins at step 302, where a server computing device 102 (e.g., a payment credential manager 110 executing thereon) identifies a user of the software application who has invalid payment credentials for processing payments associated with the software application (e.g., according to the techniques described above in connection with step 202 of FIG. 2). As described herein, the server device may identify the invalid payment credentials by self-detecting at least one problem, by interfacing with a payment processor to detect at least one problem, etc. In step 304, the server computing device 102 identifies at least one client device associated with the user and on which the software application is installed (e.g., according to the techniques described above in connection with step 202 of FIG. 2).

[0049] At step 306, the server computing device 102 provides an indication of the invalid payment credentials to at least one client device (e.g., according to the techniques described above in connection with step 204 of FIG. 2). According to some embodiments, the instructions cause the software application to cache the instructions until the software application is loaded and / or displayed. As described herein, the instructions, in connection with ultimately being loaded and / or displayed on the at least one client device, can cause the software application to display a user interface including information derived from the instructions, where the user interface is sandboxed from the software application to prevent the software application from observing activity occurring within the user interface (e.g., according to the techniques described above in connection with steps 208 through 220 of FIG. 2).

[0050] According to some embodiments, the information describes at least one problem associated with the invalid payment credential, the at least one problem including at least one of invalid billing information, insufficient funds, or insufficient available credits associated with the invalid payment credential. According to some embodiments, the user interface allows a user to replace the invalid payment credential with a valid payment credential by providing valid payment credential information, and the activity includes the user providing the valid payment credential information.

[0051] According to some embodiments, although not shown in FIG. 3A, method 300 may include additional steps that allow the software application to suppress the user interface for a specific period of time that, when elapsed, causes the software application to display the user interface.

[0052] 3B illustrates a method 350 for mitigating errors associated with a software application, according to some embodiments. As shown in FIG. 3, method 350 begins at step 352, where a client computing device 114 (e.g., a software application manager 116 executing thereon) receives from a server device an indication of invalid payment credentials associated with a software application installed on the client device (e.g., according to the techniques described above in connection with step 204 of FIG. 2).

[0053] In step 354, the client computing device 114 stores the instructions (e.g., according to the techniques described above in connection with step 206 of FIG. 2). In step 356, the client computing device 114 detects the launch and / or display of the software application (e.g., according to the techniques described above in connection with step 208 of FIG. 2).

[0054] At step 358, the client computing device 114 prompts the software application for permission to display information associated with the indication of the invalid payment credentials (e.g., according to the techniques described above in connection with step 214 of FIG. 2). At step 360, the client computing device 114 determines whether permission has been received (e.g., according to the techniques described above in connection with steps 214 and 216 of FIG. 2). If at step 360 the client computing device 114 determines that permission has been received, the method 350 proceeds to step 362 (e.g., according to the techniques described above in connection with steps 214 and 216 of FIG. 2). Otherwise, the method 350 returns to step 356 (e.g., according to the techniques described above in connection with steps 214 and 216 of FIG. 2).

[0055] In step 362, the client computing device 114 causes the software application to display a user interface including the information, where the user interface is sandboxed from the software application to prevent the software application from observing activity occurring within the user interface (e.g., by the techniques described above in connection with step 220 of FIG. 2). Additionally, although not shown in FIG. 3B, method 350 may include (1) receiving a second indication from the server device that the invalid payment credentials have been replaced with valid payment credentials, and (2) removing the indication from the cache (e.g., by the techniques described above in connection with steps 226-230 of FIG. 2).

[0056] 4A-4B illustrate a conceptual diagram 400 of an exemplary user interface that may be displayed on a client computing device 114, according to some embodiments. In particular, user interface 402 may be displayed at the client computing device 114 in conjunction with implementing step 208 of FIG. 2 . In turn, user interface 404 may be displayed at the client computing device 114 in conjunction with implementing steps 202-220 of FIG. 2 . Furthermore, user interface 406 may be displayed at the client computing device 114 in conjunction with implementing steps 222 and 224 of FIG. 2 . Furthermore, user interface 408 may be displayed at the client computing device 114 in conjunction with implementing steps 228 and 230 of FIG. 2 . It should be noted that the user interfaces illustrated in FIGS. 4A-4B are not meant to be limiting, and the user interfaces described herein may be implemented using any technique to display any form of information without departing from the scope of the present disclosure.

[0057] 5 shows a detailed diagram of a computing device 500 that can be used to execute various components described herein, according to some embodiments. In particular, the detailed diagram shows various components that may be included in the server computing device 102, payment processor 112, and client computing device 114 described above in connection with FIG.

[0058] As shown in FIG. 5, computing device 500 may include a processor 502, which represents a microprocessor or controller for controlling the overall operation of computing device 500. Computing device 500 may also include a user input device 508 that allows a user of computing device 500 to interact with computing device 500. For example, user input device 508 may take various forms, such as buttons, keypads, dials, a touchscreen, input in the form of an audio input interface, a visual / image capture input interface, sensor data, etc. Additionally, computing device 500 may include a display 510 (screen display) that may be controlled by processor 502 to display information to the user. A data bus 516 may facilitate data transfer between at least storage device 540, processor 502, and controller 513. Controller 513 may be used to interface with and control different devices via device control bus 514. Computing device 500 may also include a network / bus interface 511 that couples to a data link 512. In the case of wireless connectivity, network / bus interface 511 may include a wireless transceiver.

[0059] The computing device 500 also includes a storage device 540, which may include a disk(s) (e.g., SSD) and includes a storage management module that manages one or more partitions within the storage device 540. In some embodiments, the storage device 540 may include flash memory, semiconductor (solid-state) memory, or the like. The computing device 500 may also include random access memory (RAM) 520 and read-only memory (ROM) 522. The ROM 522 may store programs, utilities, or processes to be executed in a non-volatile manner. The RAM 520 provides volatile data storage and may store instructions related to the operation of the computing device as described herein.

[0060] Various aspects, embodiments, implementations, or features of the described embodiments can be used individually or in any combination. Various aspects of the described embodiments can be implemented by software, hardware, or a combination of hardware and software. The described embodiments can also be embodied as computer-readable code on a computer-readable medium. The computer-readable medium is any data storage device that can store data that can be read by a computer system. Examples of computer-readable media include read-only memory, random-access memory, CD-ROMs, DVDs, magnetic tape, hard disk drives, solid-state drives, and optical data storage devices. The computer-readable medium can also be distributed across network-coupled computer systems so that the computer-readable code is stored and executed in a distributed fashion.

[0061] In the foregoing description, for purposes of explanation, specific terminology was used to provide a thorough understanding of the described embodiments. However, it will be apparent to those skilled in the art that specific details are not required to practice the described embodiments. Thus, the descriptions of the specific embodiments set forth above are presented for purposes of illustration and description. They are not intended to be exhaustive or to limit the described embodiments to the precise forms disclosed. It will be apparent to those skilled in the art that numerous modifications and variations are possible in light of the above teachings.

Claims

1. 1. A method for mitigating errors associated with a software application, the method comprising: identifying at least one error associated with a user of the software application; identifying at least one client device associated with the user and on which the software application is installed; providing an indication of the at least one error to the at least one client device, causing the software application in conjunction with being loaded and / or displayed on the at least one client device: and displaying a user interface including information derived from the instructions, wherein the user interface is sandboxed from the software application so as to prevent the software application from observing activity occurring within the user interface.

2. The method of claim 1 , wherein the information describes at least one problem associated with the at least one error.

3. The at least one problem is Invalid credentials associated with the user and / or the software application; or The method of claim 2 , including at least one of invalid configuration information associated with the user and / or the software application.

4. The method of claim 2 , wherein the server device identifies the at least one error by detecting the at least one problem.

5. the user interface allows the user to provide input to mitigate the at least one error; the activity includes the user providing the input; The method of claim 1 , comprising:

6. enabling the software application to suppress the user interface for a specified period of time, after which the software application displays the user interface; The method of claim 1 further comprising:

7. The method of claim 1 , wherein the instructions cause the software application to cache the instructions until the software application is loaded and / or displayed.

8. 1. A server device configured to mitigate errors associated with a software application, the server device comprising at least one processor, the processor causing the server device to: identifying at least one error associated with a user of the software application; identifying at least one client device associated with the user and on which the software application is installed; providing an indication of the at least one error to the at least one client device, causing the software application in conjunction with being loaded and / or displayed on the at least one client device: and displaying a user interface including information derived from the instructions, wherein the user interface is sandboxed from the software application to prevent the software application from observing activity occurring within the user interface.

9. The server device of claim 8 , wherein the information describes at least one problem associated with the at least one error.

10. The at least one problem is Invalid credentials associated with the user and / or the software application; or The server device of claim 9 , comprising at least one of invalid configuration information associated with the user and / or the software application.

11. The server device of claim 9 , wherein the server device identifies the at least one error by detecting the at least one problem.

12. the user interface allows the user to provide input to mitigate the at least one error; the activity includes the user providing the input; The server device of claim 8 , comprising:

13. The steps include:

9. The server device of claim 8, further comprising the step of: allowing the software application to suppress the user interface for a specified period of time, after which the software application displays the user interface.

14. The server device of claim 8 , wherein the instructions cause the software application to cache the instructions until the software application is loaded and / or displayed.

15. 1. A method for mitigating errors associated with a software application, the method comprising: receiving, from a server device, an indication of at least one error associated with a software application installed on the client device; storing the instructions; and Detecting the activation and / or display of the software application; prompting the software application for permission to display information associated with the indication of the at least one error; In response to receiving authorization from the software application, causing the software application to display a user interface including the information, the user interface being sandboxed from the software application so as to prevent the software application from observing activity occurring within the user interface.

16. The method is performed by a software application manager executing on the client device; the software application manager enables execution of multiple software applications; the plurality of software applications includes the software application 16. The method of claim 15.

17. The method of claim 15 , wherein storing the instructions comprises storing the instructions in a cache accessible to the client device.

18. receiving a second indication from the server device that the at least one error has been mitigated; and removing the indication from the cache; 20. The method of claim 17, further comprising:

19. The method of claim 15 , wherein the information describes at least one problem associated with the at least one error.

20. The user interface includes: enabling valid credentials associated with a user of the client device to be provided; or The method of claim 15 , wherein the method enables valid configuration information associated with the user and / or the software application to be provided.

Images