Integrating micro applications with applications and platforms using application programming interface (API) sets

Abstract

The computing system (100) includes at least one microapplication and a container application (204) configured to receive application output from the microapplication (202, 602) via an application programming interface. The computing system (100) can include at least one processor (112, 132) and at least one tangible, non-transitory computer-readable medium storing instructions that, when executed by the at least one processor (112, 132), cause the at least one processor (112, 132) to perform operations. The operations can include providing a navigation bar (302) for display within a first panel (304) in a user interface (306) based on data received from a container application (204); receiving, at the container application (204), the application output from the at least one microapplication (202) via the application programming interface; and providing data describing the application output for display within a second panel in the user interface (306).

Description

Technical Field

[0001] This disclosure generally relates to the integration and interaction between computer applications. More specifically, this disclosure relates to systems and methods for integrating micro-applications into container applications and / or platforms. Background Technology

[0002] Mobile applications are frequently used for financial transactions, such as sending and / or receiving funds, purchasing goods, and / or subscribing to services. However, using various different applications has several drawbacks. For example, users typically have separate credentials for each different application, which can be difficult for them to remember. Similarly, users generally need to create new accounts with associated credentials for each application downloaded and installed, which can be cumbersome. Furthermore, the use of different applications can pose security risks because a user's financial information (e.g., bank account information, credit card numbers, etc.) is shared with each application. Therefore, systems or platforms that integrate multiple applications in a way that addresses the aforementioned problems would be desirable in this field. Summary of the Invention

[0003] Aspects and advantages of embodiments of this disclosure will be set forth in part in the description which follows, or may be learned from the description or by practice of the embodiments.

[0004] An exemplary aspect of this disclosure relates to a computing system including at least one micro-application and a container application, the container application being configured to receive application output from the micro-application via an application programming interface (API). The computing system may include at least one processor and at least one tangible, non-transitory computer-readable medium storing instructions that, when executed by the at least one processor, cause the at least one processor to perform operations. These operations may include: providing a navigation bar based on data received from the container application for display in a first panel of a user interface; receiving the application output from the at least one micro-application via the API at the container application; and providing data describing the application output for display in a second panel of the user interface.

[0005] Another exemplary aspect of this disclosure relates to a computing system including a micro-application and a container application, the container application being configured to receive data describing a transaction from the micro-application via an application programming interface (API). The computing system may include at least one processor and at least one tangible, non-transitory computer-readable medium storing instructions that, when executed by the processor, cause the processor to perform operations. The operations may include: performing a transaction using the micro-application; receiving data describing the transaction from the micro-application at the container application via the API; and providing the data describing the transaction according to the API for display in a user interface. The API may include a template describing the arrangement of the data within the user interface, the data describing the transaction.

[0006] Another exemplary aspect of this disclosure relates to a computer implementation method for integrating micro-applications into a container application. The computer implementation method may include: providing a navigation bar, based on data received from the container application, for display within a first panel of a user interface by one or more computing devices, the container application being configured to receive application output from the at least one micro-application via an application programming interface; receiving the application output from the at least one micro-application at the container application via the application programming interface by the one or more computing devices; and providing data describing the application output by the one or more computing devices for display within a second panel of the user interface.

[0007] Another exemplary aspect of this disclosure relates to a computer implementation method for integrating microapplications into container applications. The computer implementation method may include: one or more computing devices executing a transaction using the microapplication; one or more computing devices receiving data describing the transaction from the microapplication at the container application via the application programming interface (API); and one or more computing devices providing the data describing the transaction according to the API for display in a user interface, wherein the API includes a template describing the arrangement of the data within the user interface, the data describing the transaction.

[0008] Other aspects of this disclosure relate to various systems, apparatuses, non-transitory computer-readable media, user interfaces, and electronic devices.

[0009] These and other features, aspects, and advantages of the various embodiments of this disclosure will be better understood by referring to the following description and the appended claims. The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate exemplary embodiments of the disclosure and, together with the description, serve to explain the relevant principles. Attached Figure Description

[0010] A detailed discussion of embodiments for those skilled in the art is set forth in the description with reference to the accompanying drawings, wherein:

[0011] Figure 1 A block diagram of an exemplary computing system according to an exemplary embodiment of the present disclosure is depicted.

[0012] Figure 2 A simplified schematic diagram of a micro-application integrated within a container application according to an exemplary embodiment of the present disclosure is depicted.

[0013] Figure 3 A user device is depicted displaying data received from a microapplication within the navigation bar of a container application, according to an exemplary embodiment of the present disclosure.

[0014] Figures 4A to 4C An exemplary navigation bar of a container application according to an exemplary embodiment of the present disclosure is depicted.

[0015] Figure 5A and Figure 5B An exemplary navigation bar with a notification providing additional information about a source indicator is depicted according to an exemplary embodiment of this disclosure.

[0016] Figure 6 An exemplary home screen of a container application according to an exemplary embodiment of the present disclosure is depicted, wherein a user can search for micro-applications and / or merchants.

[0017] Figures 7A to 7C A series of views of a user device are depicted in the navigation bar of a container application, according to an exemplary embodiment of the present disclosure, displaying data received from a microapplication.

[0018] Figure 8 A series of sequential views of a user device according to exemplary embodiments of the present disclosure are depicted, wherein a user can interact with and order services using micro-applications.

[0019] Figure 9 A series of sequential views of a user device according to exemplary embodiments of the present disclosure are depicted, wherein a user can interact with and order services using micro-applications.

[0020] Figure 10A and Figure 10B An exemplary view of a user interface that allows a user to search for micro-applications and / or merchants, according to an exemplary embodiment of the present disclosure, is depicted.

[0021] Figure 11A A container application is described that verifies the identity of the user of the computing device based on the user account of the user associated with the container application.

[0022] Figure 11BA display window according to various aspects of this disclosure is depicted, in which the user can control whether a microapplication can access the user's phone number.

[0023] Figure 11C A display window according to various aspects of this disclosure is depicted, in which the user can control whether a microapplication can access the user's location.

[0024] Figure 12A A user interface according to various aspects of this disclosure is depicted, in which prompts are displayed to remind the user to deposit funds into the user's account.

[0025] Figure 12B A user interface according to various aspects of this disclosure is depicted, in which messages are displayed to suggest that the user make a purchase.

[0026] Figure 13 A simplified schematic diagram of an "Order" API framework including several templates according to exemplary embodiments of the present disclosure is depicted.

[0027] Figure 14 Another simplified schematic diagram depicts an "order" API framework including several templates according to exemplary embodiments of the present disclosure.

[0028] Figure 15 A series of sequential views of a user device are depicted, illustrating an exemplary implementation of an “order” API according to aspects of this disclosure.

[0029] Figure 16 An exemplary predefined template is described for displaying electronic goods such as electronic passes (e.g., boarding passes, tickets, etc.).

[0030] Figure 17 It depicts additional views for user devices that display messages, buttons, and receipts based on the "Orders" API.

[0031] Figure 18 A flowchart is depicted illustrating an exemplary method for integrating microapplications into container applications according to aspects of this disclosure.

[0032] Figure 19 A flowchart is depicted for another exemplary method for integrating microapplications into container applications according to aspects of this disclosure.

[0033] The repeated reference numerals in the various figures are intended to identify the same features in the different embodiments. Detailed Implementation

[0034] Overview

[0035] Generally, this disclosure relates to systems and methods for integrating microapplications into container applications and / or platforms. A microapplication (referred to herein as a "microapplication") generally refers to a lightweight application for a mobile device, provided within or through another container application. For example, a container application, such as a traditional mobile device application, can invoke a microapplication to perform a specific task within the container application. Microapplications may have focusing functionality based on predefined guidelines established by the container application. In some aspects of this disclosure, predefined application programming interfaces (APIs) and / or software development kits (SDKs) can provide guidelines and / or tools to third-party microapplication developers to design microapplications that can be accessed within and / or through the container application. For example, a container application can securely store a user's banking information and facilitate purchases, payment requests, etc., using microapplications without sharing the user's banking information with those microapplications. This configuration provides improved security compared to sending and / or receiving funds directly through different third-party applications. Similarly, a container application can securely store other user information, such as a user's preferred delivery address and / or user preferences for specific goods and services, without sharing this information with microapplications. Therefore, the container applications / platforms described in this article can facilitate user interaction with third-party microapplications in a way that enhances security.

[0036] According to aspects of this application, APIs can be used to provide various functionalities and / or operations from micro-applications within a container application. Exemplary APIs include payments (e.g., requesting a payment), phone numbers (e.g., requesting a phone number), location (e.g., learning a user's location), orders (e.g., providing transaction details), identity (e.g., learning a user's identity), delivery (e.g., learning a user's delivery address), sharing (allowing a user to share), scanning (e.g., allowing a user to scan a QR code, barcode, etc.), proximity (e.g., learning a user's proximity to a store and / or beacon), shopping carts, messaging, etc. Specific implementations may include sending messages to user contacts, sharing completed payments, sending payment requests to user contacts (e.g., sharing payment for items), paying for goods or services on behalf of a specific user contact (e.g., as a gift for that user contact), and receiving notifications from a micro-application. Furthermore, APIs can be designed to facilitate various high-level operations (e.g., QR code recognition) rather than low-level operations (e.g., camera access). Therefore, APIs can encourage the development of micro-applications by making such development easier and more intuitive.

[0037] According to various aspects of this application, container applications and / or APIs can control various aspects of the user experience to improve the continuity of the user experience across multiple micro-applications. For example, a container application can control how notifications from micro-applications are presented to the user (e.g., how to allow specific notifications to "attention-grabbing"). A container application can select notification methods (e.g., as a banner, alert, silent notification, etc., visible only when accessing the container application) based on user preferences and / or device settings (e.g., silent, do not disturb, ring, etc.). Therefore, a container application can control how micro-applications present notifications to the user.

[0038] As another example, APIs can provide templates and / or predefined task flows to improve the continuity of the user experience across different micro-applications accessible from the container application. For instance, once an "order" (e.g., for a meal) is placed, the container application can control how and when updates (e.g., the status of meal preparation) are presented to the user. Finally, container applications can provide centralized control or settings dashboards where users can adjust settings or preferences applied to multiple micro-applications. Therefore, container applications can improve the user experience compared to directly accessing various different applications.

[0039] In some implementations, a navigation bar may be provided to display information about the micro-application and / or provide the user with controls about the micro-application. The navigation bar may be displayed within a first panel of the user interface. Data describing application output received from the micro-application via one or more APIs may be displayed in a second panel of the user interface. Controls may include an exit icon to allow the user to exit the micro-application (e.g., return to the container application's main menu). Controls may include share icons for users to share aspects of their experience with the micro-application (e.g., on social media, via text messages, via email, etc.). As another example, the navigation bar may provide the user with the ability to adjust settings for the specific micro-application being accessed and / or general settings for all micro-applications accessible through the container application / platform. Thus, the navigation bar may provide the user with controls about one or more micro-applications.

[0040] A navigation bar can display information about the micro-application being accessed. For example, it can display a source indicator describing the micro-application's origin (e.g., the company or brand associated with it). For instance, it could provide an icon or indicator describing whether the micro-application has the same origin as the container application (e.g., the same developer, the same company, etc.). In this case, the user might feel more trusting or comfortable with the micro-application because they might trust the container application's origin. Conversely, an indicator showing that the micro-application comes from a different origin than the container application can warn the user to be more cautious about that micro-application. Therefore, a navigation bar can provide information about micro-applications, including source indicators.

[0041] In some implementations, multiple micro-applications can be accessed from the container application. Users can navigate to the desired micro-application using a list or menu structure. For example, indicators corresponding to micro-applications and / or micro-application categories can be displayed within the user interface. Users can scroll through the indicators to locate the desired micro-application or category of micro-applications (e.g., based on the type of goods or services associated with the micro-application). Thus, the container application can provide users with the ability to navigate through multiple micro-applications to locate a specific desired micro-application.

[0042] In some implementations, container applications can locate nearby goods or services based on a user's location and / or preferences, and suggest relevant micro-applications to the user. The container application can provide a list of micro-applications corresponding to nearby services or stores. For example, when a user is near one of their favorite coffee shop locations, they can be notified to order coffee from that favorite coffee shop. The container application can suggest appropriate micro-applications, such as those posted by the coffee shop or more generally, coffee or food ordering micro-applications. Optional additional information about the service and / or store may be included, such as distance to the store and / or service location, available service times (e.g., movie showtimes, time from ordering until preparation, etc.). The user can select one of the micro-applications and complete a transaction form within the container application. Therefore, container applications can facilitate the identification of relevant micro-applications based on a user's location and / or preferences, engagement with the micro-application (e.g., selecting a product or service), and sending or receiving funds to place an order and / or complete a transaction via the container application.

[0043] In some implementations, container applications can authenticate the identity of users on computing devices based on user accounts associated with the container application. More specifically, users can have pre-existing accounts that can be accessed from the container application. The container application can authenticate users by accessing their pre-existing accounts to "log in the user" to selected micro-applications. Therefore, container applications can facilitate user identification and / or authentication, eliminating the need for users to create separate login credentials and / or accounts for each micro-application.

[0044] According to another aspect of this disclosure, users can communicate with other users or contacts through container applications. For example, users can share recently completed events, such as completed payments, payment requests, etc. Users can directly share recently completed events with their contacts and / or "post" completed events on social media, etc.

[0045] In some implementations, container applications can help users locate desired applications during the "discovery" phase. For example, a user can perform a search for a specific product or service within a container application. The search can return a list of micro-applications available to provide the requested product or service. The user can then select the desired micro-application to view its storefront.

[0046] Next, in the "Conversation" phase, users can interact with the micro-application to customize and place "orders" within the store. An "order" can refer to the purchase of goods or services involving subsequent delivery. A "Messaging" or "Conversation" interface can be displayed, where updates can be provided in the form of messages. The "Conversation" interface can provide an intuitive way to convey the history of a user's interactions with a specific micro-application (e.g., including previous orders, updates, etc.).

[0047] As mentioned above, container applications / platforms can provide developers with several dedicated APIs. As an example, the "Shell" API can be configured to control and / or organize how micro-applications are displayed and / or accessed within the container application. A "storefront" can be defined, where micro-applications can display available goods and services, offers, etc. Various status icons can be included to convey current information about one or more states of the micro-application, such as current settings, permissions, etc. Therefore, the "Shell" API can facilitate continuity in the "look and feel" of micro-applications accessible within the container application / platform. Furthermore, providing users with predictable access to settings and / or permissions (e.g., globally or individually for each micro-application) can improve user trust and comfort with the micro-applications.

[0048] As another example, an "Orders" API could be provided, which simplifies and standardizes the process of handling and presenting orders and / or supplies of goods and / or services to users within containerized applications and micro-applications. Before a transaction is completed, the "Orders" API can define an initial set of templates and / or rules regarding how supplies, messages, customer support messages, etc., can be presented to the user. Once the user has selected the goods, services, and / or customized options associated with them, the "Orders" API can facilitate the completion of the transaction. After the transaction is completed, the "Orders" API can control how the user stores, shares, or otherwise manipulates confirmations, status updates (e.g., tracking, delivery status, etc.), deliverables (e.g., trips, tickets, passes), etc. Therefore, when placing orders through a containerized application / platform, the "Orders" API can improve the continuity of the user experience across multiple micro-applications.

[0049] As another example, the "Payment" API can be configured to control how financial transactions are conducted through the container application and / or control aspects of the display of various information related to such financial transactions. The "Payment" API can control how, when, and where sensitive information, such as financial details (e.g., bank information) and / or personal information (e.g., phone number, email address, mailing address, etc.), is sent. For example, the container application can receive transaction destinations (e.g., data describing bank accounts, etc.) from micro-applications via the "Payment" API. The payment applicant can then send payments, payment requests, etc., to the transaction destination without sharing sensitive information with the micro-applications. Therefore, the "Payment" API can provide users with increased security compared to directly inputting a user's sensitive information into multiple applications outside the container application / platform. The "Payment" API can also include features for payments to share or split items and / or for paying for items on behalf of another user (e.g., as a gift to that user).

[0050] As another example, a sensor API can be included that controls, via a micro-application, access to and / or provision of characteristics of sensors on a user device, such as cameras, microphones, GPS sensors, etc. For example, the sensor API can control when and / or how a micro-application accesses sensors. Such control can be based on user-adjustable settings within the container application / platform. The sensor API can also include one or more utilities that can perform operations based on data received from the user device's sensors. As an example, the sensor API can include scanning utilities for visual codes (e.g., QR codes, barcodes, etc.) based on images received from the user device's camera. As another example, the sensor API can facilitate speech recognition or analysis of audio received from the user device's microphone. Additionally, the sensor API can selectively provide access to one or more sensors (e.g., cameras, microphones, etc.) based on received credentials, such as via Near Field Communication (NFC), Bluetooth, Wi-Fi, or other suitable types of communication. Similarly, the sensor API can selectively provide access to various communication devices based on the user device's location (such as that detected by GPS sensor data and / or transmitted via one or more of the aforementioned communication devices). For example, when near a specific location (e.g., an ATM, a merchant, etc.), NFC can be used to unlock access to a camera to complete a purchase or transaction. User computing devices can use GPS sensor data, connectivity with Wi-Fi, Bluetooth, etc., to determine their location. Therefore, sensor APIs can control and / or provide utilities or features for micro-applications related to the user device's sensors.

[0051] As another example, a connectivity API could be included that controls access to one or more types of communication, including near field communication (NFC), Bluetooth, Wi-Fi, or other suitable types of communication. The connectivity API can control or provide access to such communication devices based on the type of computer application, the location of the device, receiving credentials, etc.

[0052] In some implementations, container applications and / or platforms may leverage one or more machine learning models to help suggest micro-applications and / or perform related tasks for users. For example, a container application may suggest micro-applications based on user preferences, which may be learned based on user interactions with the container application and / or micro-applications with the user's consent.

[0053] Various aspects of this application also address providing feedback (e.g., in the form of reports or statistics) and / or facilitating troubleshooting for microapp developers with user consent. For example, container applications can collect information about how users interact with various microapps in different situations or scenarios. Microapp developers can use this information to improve their microapps. As another example, microapp developers can set up automated alerts for specific types of errors or user behaviors. For instance, "automatic checks" can be implemented to log every user interaction with a microapp (e.g., up to a level or stage in a predefined process or flowchart) without completing a financial action (e.g., a purchase, payment request, etc.). As yet another example, microapp developers can define specific user feedback issues and / or prompts to be presented within the microapp. These features can be provided within the developer portal for container applications. Therefore, various aspects of this application are aimed at improving the developer experience.

[0054] Another aspect of this disclosure addresses providing microapplication developers with the ability to develop microapplications in standard and / or non-proprietary programming languages. Microapplications can be created (e.g., assembled, written, coded, etc.) using publicly available and / or framework-agnostic authoring tools. For example, JavaScript (JSS) for Cascading Style Sheets (CSS) can be used to develop microapplications using HTML. Therefore, the platform described herein can provide more accessible microapplication development.

[0055] In some implementations, various software development kits (SDKs) may be provided, each corresponding to a specific "use case" or application, such as different types of goods, services, delivery models, etc. For example, different SDKs may correspond to food delivery applications, ticket / pass ordering (e.g., electronically deliverable goods and services), social media applications, etc. These various SDKs may have different sets of APIs, permissions, and / or settings pre-configured or predefined based on the intended application and / or use case.

[0056] Permissions and / or security settings for various SDKs can be pre-configured based on their intended use cases. For example, the "e-Goods" SDK can be designed for micro-applications that order and deliver electronic items such as e-tickets or e-passes. The "e-Goods" SDK could have preset permissions that prevent micro-applications from obtaining the user's current location, mailing address, etc., as this information is generally not necessary for purchasing and receiving e-tickets or e-passes. However, in this example, preset permissions could allow the collection of user preferences regarding movies, airlines, etc. (if the user has consented).

[0057] As another example, a "physical goods" SDK for delivering food, consumer goods, etc., might have the following preset permissions: it can collect geographic information about the user (e.g., physical location, home address, work address, etc.) with the user's consent, but it is prohibited from collecting the user's preferences regarding movies, airlines, etc. User preferences regarding movies, airlines, etc., are generally irrelevant to the delivery of physical goods such as food. Therefore, various SDKs can have different permissions depending on the intended use case associated with the respective SDK.

[0058] Similarly, various SDKs may include different sets of APIs suitable for the intended "use cases" or applications of the SDK. For example, the "Physical Goods" SDK example above may include "Sensor" APIs (also described above), such as for scanning product codes to purchase or learn more about physical products. Conversely, the "Electronic Goods" SDK may exclude "Sensor" APIs, as access to sensors (e.g., cameras and / or microphones) of a user's device may be useless or inappropriate when purchasing an electronic ticket. It should be understood that the above examples of use case SDKs are merely exemplary. More specific and / or more granular use cases (e.g., "Coffee Delivery" SDK, "Music Purchase" SDK, etc.) are contemplated within the scope of this disclosure.

[0059] Therefore, the aspects of this disclosure can improve microapplication developers' accessibility to the platform while still preventing unwanted microapplication features or activities (e.g., unwanted data collection and / or maliciously designed microapplications). More specifically, the aforementioned non-proprietary coding capabilities and / or compatibility can improve developer accessibility to the platform. Use-use specific SDKs can provide mechanisms for systematically protecting users by restricting the capabilities of microapplications (e.g., through permissions and / or APIs). Taken together, these features can provide a robust platform for the development of secure microapplications.

[0060] Container applications can aggregate and / or store data received from different micro-applications in a common location. As an example, data may include user interactions, order history, user preferences, etc. A common location may include on-device storage, network locations, cloud storage locations, etc. As another example, container applications can aggregate updates from various micro-applications and present them in a combined message or notification stream.

[0061] As an example, the systems and methods of this disclosure may be included within or otherwise employed in the context of an application, browser plugin, or other contexts. Therefore, in some embodiments, the model of this disclosure may be included in or otherwise stored and implemented by a user computing device such as a laptop computer, tablet computer, or smartphone. As yet another example, the model may be included in or otherwise stored and implemented by a server computing device that communicates with the user computing device according to a client-server relationship. For example, the model may be implemented by the server computing device as part of a web service (e.g., a web email service).

[0062] Exemplary embodiments of this disclosure will now be discussed in more detail with reference to the accompanying drawings.

[0063] Exemplary devices and systems

[0064] Figure 1 A block diagram of an exemplary computing system 100 for integrating micro-applications relative to container applications, according to exemplary embodiments of the present disclosure, is depicted. System 100 may include a user computing device 102 and a server computing system 130 communicatively coupled via a network 180.

[0065] User computing device 102 can be any type of computing device, such as a personal computing device (e.g., a laptop or desktop computer), a mobile computing device (e.g., a smartphone or tablet computer), a game console or controller, a wearable computing device, an embedded computing device, or any other type of computing device.

[0066] User computing device 102 includes one or more processors 112 and memory 114. The one or more processors 112 can be any suitable processing device (e.g., processor core, microprocessor, ASIC, FPGA, controller, microcontroller, etc.) and can be a single processor or multiple processors operatively connected. Memory 114 can include one or more non-transitory computer-readable storage media, such as RAM, ROM, EEPROM, EPROM, flash memory devices, disks, etc., and combinations thereof. Memory 114 can store data 116 and instructions 118 executed by processor 112 to cause user computing device 102 to perform operations.

[0067] User computing device 102 may also include one or more user input components 122 for receiving user input. For example, user input component 122 may be a touch-sensitive component (e.g., a touch-sensitive display or touchpad) sensitive to the touch of a user input object (e.g., a finger or stylus). Touch-sensitive components can be used to implement a virtual keyboard. Other exemplary user input components include a microphone, a conventional keyboard, or other devices through which the user can communicate with their input. User computing device 102 may also include one or more sensors 124, such as a microphone, camera, temperature sensor, accelerometer, etc.

[0068] Server computing system 130 includes one or more processors 132 and memory 134. The one or more processors 132 can be any suitable processing device (e.g., processor core, microprocessor, ASIC, FPGA, controller, microcontroller, etc.) and can be a single processor or multiple processors operatively connected. Memory 134 can include one or more non-transitory computer-readable storage media, such as RAM, ROM, EEPROM, EPROM, flash memory devices, disks, etc., and combinations thereof. Memory 134 can store data 136 and instructions 138 that are executed by processor 132 to cause server computing system 130 to perform operations.

[0069] In some embodiments, the server computing system 130 includes one or more server computing devices or is otherwise implemented by one or more server computing devices. Where the server computing system 130 includes multiple server computing devices, such server computing devices may operate according to a sequential computing architecture, a parallel computing architecture, or some combination thereof.

[0070] Network 180 can be any type of communication network, such as a local area network (e.g., intranet), a wide area network (e.g., the Internet), or some combination thereof, and can include any number of wired or wireless links. Generally, communication over Network 180 can be carried via any type of wired and / or wireless connection using a wide variety of communication protocols (e.g., TCP / IP, HTTP, SMTP, FTP), encodings or formats (e.g., HTML, XML), and / or protection schemes (e.g., VPN, Secure HTTP, SSL).

[0071] Exemplary embodiments

[0072] One or more APIs control how microapplications are integrated within a container application. As mentioned above, an exemplary API might include orders (e.g., to provide transaction details, for example, as shown in the following reference). Figures 13 to 17 The API can be configured to handle various functions, including: payment (e.g., requesting payment), phone number (e.g., requesting a phone number), location (e.g., learning the user's location), identity (e.g., learning the user's identity), delivery (e.g., learning the user's delivery address), sharing (allowing the user to share), scanning (e.g., allowing the user to scan QR codes, barcodes, etc.), proximity (e.g., learning the user's proximity to stores and / or beacons), shopping cart, messaging, etc. Specific implementations may include sending messages to user contacts, sharing completed payments, sending payment requests to user contacts (e.g., paying for shared items), paying for goods or services on behalf of a specific user contact (e.g., as a gift for that user contact), and receiving notifications from the micro-application. Furthermore, the API can be designed to facilitate various high-level operations (e.g., QR code recognition) rather than low-level operations (e.g., camera access). Therefore, APIs can encourage micro-application development by making such development easier and more intuitive.

[0073] Figure 2 A simplified schematic diagram of a micro-application 202, accessible from and / or integrated within a container application according to exemplary embodiments of this disclosure, is depicted, for example, based on a “shell” API. The “shell” API can be configured to control and / or organize how micro-applications are located, displayed, and / or accessed within a container application. Various status icons may be included to convey current information about one or more states of the micro-application, such as current settings, permissions, etc. Therefore, the “shell” API can facilitate continuity in the “look and feel” of micro-applications accessible within a container application / platform. Furthermore, providing users with predictable and intuitive access to settings and / or permissions (e.g., globally or individually for each micro-application) can improve user trust and comfort with the micro-applications.

[0074] refer to Figure 2A typical task flow may include a discovery phase 205, in which the user interacts with the container application 204 to locate a microapplication 202 that can provide the desired goods and / or services, for example, as shown in the following reference. Figure 6 , Figure 10A and Figure 10B As described above. Next, during dialogue phase 207, the user can interact with the selected micro-application 202, for example, as shown below. Figures 7A to 9 and Figures 13 to 17 As stated above.

[0075] For example, refer to Figure 2 In the "Discovery" phase 205, users can perform a search 208 for specific goods or services within the container application 204. The search can return a list of micro-applications 202 available to provide the requested goods or services. Users can select the desired micro-application 202 to view the storefront 210 of the selected micro-application 202.

[0076] Next, in the "Conversation" phase 207, the user can interact with the micro-application 202 to customize and place an "order" within the storefront 210. An "order" can refer to the purchase of goods or services involving subsequent delivery. A "messaging" or "conversation" interface may be displayed, where updates can be provided in the form of messages. The "conversation" interface can provide an intuitive way to convey the user's history of interactions with a particular micro-application (e.g., including previous orders, updates, etc.).

[0077] Microapplication 202 can interface with container application 204 using the "Orders" API. For example, the "Orders" API can include predefined "Order Card" templates or standards. Through these predefined templates or standards, microapplication 202 can collect and transmit order details via container application 204, as shown in the reference below. Figures 13 to 17 The container application 204 can control how and when updates (e.g., notifications 206) are presented to the user (e.g., regarding the status of an order). In some embodiments, a text box 214 or a navigation bar may be displayed to provide the user with controls and / or information about the microapplication 202.

[0078] In some embodiments, one or more additional access options or entry points, referred to as “primers” 216, may be provided for accessing micro-applications 202. Exemplary primers 216 may include links or codes from different computer applications. For example, different computer applications from a particular company may provide direct links to open the container application and navigate directly to the micro-application created by that company. Users may “scan” or photograph visual codes (e.g., barcodes or QR codes) associated with a product, service, and / or a specific micro-application to access a list of micro-applications associated with that product / service and / or to directly access the specific micro-application.

[0079] As described above, a “micro-application” 202 can be or is included within or provided through container application 204 as a lightweight application. Predefined guidelines established by container application 204 can provide focused functionality. For example, predefined application programming interfaces (APIs) and / or software development kits (SDKs) can guide and / or constrain developers of micro-application 202, enabling access to micro-application 202 within and / or through container application 204 in a predefined manner. This configuration provides improved security compared to sending and / or receiving funds directly through a separate and distinct third-party application from container application 204. Container application 204 can securely store user banking information and use micro-application 202 to facilitate purchases, payment requests, etc., as shown in the following references. Figures 7A to 9 As described above, without sharing the user's banking information with micro-application 202. Similarly, container application 204 can securely store other user information, such as the user's preferred delivery address and / or the user's preferences for specific goods and services, without sharing this information with micro-application 202. Therefore, the container application / platform described herein can facilitate user interaction with third-party micro-application 202 in a secure manner.

[0080] According to various aspects of this application, the container application 204 and / or the API can control various aspects of the user experience to improve the continuity of the user experience across multiple micro-applications 202. For example, the container application 204 can control how notifications 206 from micro-applications 202 are presented to the user (e.g., allowing specific notifications 206 to “attention”). The container application 204 can select notification methods (e.g., as banners, alerts, silent notifications, etc., visible only when accessing the container application) based on user preferences and / or device settings (e.g., silent, do not disturb, ring, etc.). As another example, the “order” API may include one or more templates that control the arrangement and selection of information that can be displayed to the user, for example, as referenced below. Figures 13 to 17Therefore, container application 204 can control how microapplication 202 presents notifications 206 and / or updates to the user. As another example, the API can provide templates and / or predefined task flows to improve the continuity of the user experience across different microapplications 202 accessible from container application 204, as referenced below. Figures 13 to 17 As mentioned above.

[0081] Figure 3 A user device 300 is depicted displaying data received from a microapplication within a navigation bar 302 of a container application, according to an exemplary embodiment of this disclosure. The navigation bar 302 may be provided to display information about the microapplication and / or to provide the user with controls about the microapplication and / or navigation through other microapplications. The navigation bar 302 may be displayed within a first panel 304 of a user interface 306. Data described as application output received from the microapplication via one or more APIs may be displayed in a second panel 308 of the user interface 306.

[0082] Controls may include an exit icon 310 to allow a user to exit the microapp (e.g., to return to the container app's main menu). Controls may include a share icon 312 to allow users to share aspects of their microapp experience (e.g., on social media, via text message, via email, etc.). As another example, navigation bar 302 may include an icon 314 for providing users with additional controls and / or options. For example, icon 314 may provide access to a settings panel to adjust settings for the specific microapp being accessed and / or general settings for all microapps accessible through the container app / platform. Thus, navigation bar 302 can provide users with controls regarding one or more microapps.

[0083] Navigation bar 302 can display various information about a specific micro-application being displayed via the container application. For example, navigation bar 302 can display the micro-application name 316 and / or icon 317 associated with the micro-application. Navigation bar 302 may include a source indicator 318 describing the micro-application's origin (e.g., the company or brand associated with the micro-application). For example, source indicator 318 can describe whether the micro-application has the same origin as the container application (e.g., the same developer, the same company, etc.). In this example, source indicator 318 indicates that the micro-application comes from a different source than the container application, which could warn the user to be more cautious about the micro-application. Conversely, source indicator 318 could indicate that the micro-application comes from the same source as the container application. In this case, the user may have more trust or comfort with the micro-application because the user may trust the origin of the container application. Therefore, navigation bar 302 can provide information about the micro-application, including name 316 and / or source indicator 318.

[0084] Figures 4A to 4CExemplary navigation bars 400, 402, and 404 according to exemplary embodiments of this disclosure are depicted. More specifically, in Figures 4A to 4C Example names and icons are shown below. References Figure 4A The navigation bar 400 can include the micro-application name 406 and icon 408. (See reference) Figure 4B Navigation bar 402 may include another example micro-application name 412 and icon 414. (See reference) Figure 4C Navigation bar 404 may include an example micro-application name 416 and an icon 418. The appearance of navigation bars 400, 402, and 404 can be varied to visually indicate which micro-application is being accessed. For example, icons 408, 414, and 418 may represent the corresponding micro-applications 406, 412, and 416. Furthermore, the color, texture, shape, or other visual attributes of navigation bars 400, 402, and 404 can be customized based on the micro-application.

[0085] refer to Figures 4A to 4C Navigation bars 400, 402, and 404 may include corresponding source indicators 420. The corresponding source indicator 420 may indicate that the corresponding micro-application comes from a different source (e.g., "external") of the container application's developer. Navigation bars 400, 402, and 404 may include corresponding exit icons 422 and "more" icons 424.

[0086] refer to Figure 5A and Figure 5B In some implementations, the computing system may provide a notification or explanation associated with the source indicator. More specifically, refer to... Figure 5A Notification 502 can provide additional information about the "External" indicator 504. (See reference) Figure 5B Notification 506 can provide additional information about the "Internal" indicator 508.

[0087] This disclosure addresses various aspects of providing microapplication developers with the ability to develop microapplications in standard and / or non-proprietary programming languages. Microapplications can be created (e.g., assembled, written, coded, etc.) using publicly available and / or framework-agnostic authoring tools. For example, JavaScript (JSS) for Cascading Style Sheets (CSS) can be used to develop microapplications using HTML. Therefore, the platform described herein can provide more accessible microapplication development.

[0088] In some implementations, various software development kits (SDKs) may be provided, each corresponding to a specific "use case" or application, such as different types of goods, services, delivery models, etc. For example, different SDKs may correspond to food delivery applications, ticket / pass ordering (e.g., electronically deliverable goods and services), social media applications, etc. These various SDKs may have different sets of APIs, permissions, and / or settings pre-configured or predefined based on the intended application and / or use case.

[0089] Permissions and / or security settings for various SDKs can be pre-configured based on their intended use cases. For example, the "e-Goods" SDK can be designed for micro-applications that order and deliver electronic items such as e-tickets or e-passes. The "e-Goods" SDK could have preset permissions that prevent micro-applications from obtaining the user's current location, mailing address, etc., as this information is generally not necessary for purchasing and receiving e-tickets or e-passes. However, in this example, preset permissions could allow the collection of user preferences regarding movies, airlines, etc. (if the user has consented).

[0090] As another example, a "physical goods" SDK for delivering food, consumer goods, etc., might have the following preset permissions: it can collect geographic information about the user (e.g., physical location, home address, work address, etc.) with the user's consent, but it is prohibited from collecting the user's preferences regarding movies, airlines, etc. User preferences regarding movies, airlines, etc., are generally irrelevant to the delivery of physical goods such as food. Therefore, various SDKs can have different permissions depending on the intended use case associated with the respective SDK.

[0091] Similarly, various SDKs may include different sets of APIs suitable for the intended "use cases" or applications of the SDK. For example, the "Physical Goods" SDK example above may include "Sensor" APIs (also described above), such as for scanning product codes to purchase or learn more about physical products. Conversely, the "Electronic Goods" SDK may exclude "Sensor" APIs, as access to sensors (e.g., cameras and / or microphones) of a user's device may be useless or inappropriate when purchasing an electronic ticket. It should be understood that the above examples of use case SDKs are merely exemplary. More specific and / or more granular use cases (e.g., "Coffee Delivery" SDK, "Music Purchase" SDK, etc.) are contemplated within the scope of this disclosure.

[0092] Therefore, the aspects of this disclosure can improve microapplication developers' accessibility to the platform while still preventing unwanted microapplication features or activities (e.g., unwanted data collection and / or maliciously designed microapplications). More specifically, the aforementioned non-proprietary coding capabilities and / or compatibility can improve developer accessibility to the platform. Use-use specific SDKs can provide mechanisms for systematically protecting users by restricting the capabilities of microapplications (e.g., through permissions and / or APIs). Taken together, these features can provide a robust platform for the development of secure microapplications.

[0093] Furthermore, different SDKs may include different preset permissions and / or security settings appropriate for their respective intended use cases. For example, the "e-goods" SDK could be designed for micro-applications used to order and deliver electronic items, such as e-tickets or e-passes, as referenced above. Figures 14 to 17 The “Electronic Goods” SDK may have preset permissions that prevent micro-applications from obtaining the user’s current location, mailing address, etc., as this information is generally not necessary for purchasing and electronically receiving e-tickets or e-passes. However, in this example, the preset permissions may allow the collection of user preferences regarding movies, airlines, etc. (if the user has consented).

[0094] As another example, a "physical goods" SDK for delivering food, consumer goods, etc., could have the following preset permissions: these permissions allow the collection of geographic information about the user (e.g., physical location, home address, work address, etc.) with the user's consent, but prohibit the collection of user preferences regarding movies, airlines, etc. User preferences regarding movies, airlines, etc., are generally unrelated to the delivery of physical goods such as food (as referenced above). Figures 6 to 7C (as described above). Therefore, depending on the intended use case associated with the respective SDK, various SDKs may have different permissions.

[0095] As an example, the "shell" API can be configured to control and / or organize how microapplications are located, displayed, and / or accessed within a container application, as shown in the reference above. Figure 2 As mentioned above.

[0096] As another example, the "Payments" API can be configured to control how financial transactions are conducted through the container application / platform and / or control aspects of the display of various information related to such financial transactions. The "Payments" API can control how, when, and where sensitive information, such as financial details (e.g., bank information) and / or personal information (e.g., phone number, email address, mailing address, etc.), is sent. For example, the container application can receive transaction destinations (e.g., data describing bank accounts, etc.) from micro-applications via the "Payments" API. The payment applicant can then send payments, payment requests, etc., to the transaction destination without sharing sensitive information with the micro-applications. Therefore, the "Payments" API can provide users with increased security compared to directly inputting a user's sensitive information into multiple applications outside the container application / platform. The "Payments" API can also include features for payments to share or split items and / or for paying for items on behalf of another user (e.g., as a gift to that user).

[0097] As another example, a sensor API could be included, which controls the sensor 124 on the user device via a microapplication. Figure 1 The sensor API allows access to and / or provision of information about the characteristics of sensors (such as cameras and / or microphones) on the user device. For example, a sensor API can control when and / or how a micro-application accesses sensors. Such control can be based on user-adjustable settings within the container application / platform (e.g., in the container application's control panel). The sensor API may also include one or more utilities that can perform actions based on data received from the user device's sensors. As an example, the sensor API may include scanning utilities for visual codes (e.g., QR codes, barcodes, etc.), where these visual codes are based on data received from the user device's sensors. Figure 1 ) camera ( Figure 1 The received image, for example, as shown in the reference above. Figure 2 The “primer” 216 is described. As another example, the sensor API can facilitate speech recognition or analysis of audio received from the microphone 124 of the user equipment 102. Thus, the sensor API can control and / or provide utilities or features for micro-applications targeting the sensor 124 of the user equipment 102.

[0098] As another example, a connectivity API may be included, which controls access to one or more types of wireless communication, including Near Field Communication (NFC), Bluetooth, Wi-Fi, or other suitable types of communication. The connectivity API may control or provide access to such a communication device based on the type of computer application, the location of device 102, receiving credentials, etc.

[0099] More specifically, Figure 6and Figures 7A to 7C The above reference describes how user devices interact with each other based on one or more APIs (e.g., shell API, order API, payment API, etc.). Figure 2 The description includes a series of views corresponding to the discovery and dialogue phases. More specifically, Figure 6 An exemplary home screen 600 of a container application according to an exemplary embodiment of the present disclosure is depicted, which can be referenced above. Figure 2 The description corresponds to the discovery phase. Multiple micro-applications can be accessed from the container application. Users can browse a list and / or menu structure from the main screen 600 to locate the desired micro-application. For example, the main screen 600 may suggest micro-applications 602 and / or suggest nearby merchants 604 that provide services that allow users to locate associated micro-applications. Users can scroll through indicators (e.g., as shown by arrow 606) to locate the desired micro-application or category of micro-applications (e.g., based on the type of goods or services associated with the micro-application). Therefore, the container application can provide users with the ability to navigate multiple micro-applications to locate a specific desired micro-application.

[0100] In some implementations, nearby merchants 604 and / or micro-apps 602 can be located based on the user's location and / or preferences. For example, when a user is near one of their favorite coffee shop locations, they can be notified to order coffee from that favorite coffee shop. The container app can suggest appropriate micro-apps, such as those posted by the coffee shop or more generally, coffee or food ordering micro-apps. Optional additional information about the service and / or shop can be included, such as distance to the shop and / or service location, available service times (e.g., movie showtimes, time from ordering until preparation, etc.). The user can select one of the micro-apps and complete the transaction form within the container app. Thus, the container app can help users search for and locate relevant micro-apps based on their location and / or preferences.

[0101] In some implementations, the home screen 600 may also provide a list 608 of the user's contacts and / or people the user may know. This list 608 may facilitate the social aspects of this disclosure, such as sharing completed transactions or paying for services on behalf of another user (e.g., as a gift).

[0102] Figures 7A to 7C This illustration depicts a series of views of a user device displaying data received from a micro-application using a navigation bar of a container application, according to an exemplary embodiment of this disclosure. (Reference) Figure 7A Once the user, for example, refers to the above... Figure 6 The described main screen 600, when a micro-application is selected, can display a welcome screen 702 based on data received from the micro-application. A navigation bar 704 or a "text box" can be displayed, as shown in the reference above. Figures 3 to 4BThe welcome screen 702 may include information describing the goods and / or services offered by the micro-application and / or the process for ordering such goods and / or services. Users can click the "continue" button 706 to access the offerings of goods and services within the micro-application.

[0103] Figure 7B The illustration shows a second view 708 of a user device, based on data received from a micro-application and displayed according to an API. In this example, the user can view food delivery items from various restaurants, including various details about the items. The user can scroll through the various items (e.g., as shown by arrows 707, 709).

[0104] Figure 7C The illustration shows a third view 710 of a user device displaying data received from a micro-application and a navigation bar 711, according to aspects of this disclosure. More specifically, the micro-application can provide updates 712, 714 regarding orders placed by the user (e.g., food orders), as described below with reference to the following references. Figures 13 to 17 The "Orders" API description states that the third view 710 of the user device may also include additional supplies 716 or supply categories from the microapplication.

[0105] Figure 8 A series of sequential views 800, 802, 804, and 806 of a user device according to exemplary embodiments of the present disclosure are depicted, wherein a user can interact with and order services using micro-applications. In view 800, a "messaging" or "conversation" interface may be displayed, wherein updates may be provided in the form of messages. The "conversation" interface can provide an intuitive way to convey the history of a user's interactions with a particular micro-application (e.g., including previous orders, updates, etc.).

[0106] In this example, a previous "conversation" with the ticketing micro-app is displayed. Previous messages 808 and 810 may indicate that the user previously purchased tickets for a specific movie. A list 812 of available supply categories is also displayed, including movies, sports, and concerts. If the user selects "Movies" 814 from list 812, currently available movie ticket supplies can be displayed in the "Storefront" view 802. This supply includes specific movies based on the user's previously purchased tickets to view that particular move. The user can select a specific movie to purchase tickets for that move again. Additional information such as showtimes and theater locations can be displayed along with the movie title.

[0107] In view 804, the panel may include details about the transaction, such as the purchase amount 816, the source of funds 818, and the user profile and / or micro-application associated with the transaction 820. The user can select payment using the "pay" button 822.

[0108] In view 806, additional messages 824 and 826 can be displayed, showing the order status and / or providing the option to "share" the order via the "share" button 828. For example, users can communicate with other users or contacts through the container application. For instance, users can share recently completed events, such as completed payments, payment requests, etc. Users can directly share recently completed events with their contacts and / or "post" completed events on social media, etc. The content and / or format of additional messages 824 and 826 can be based on a reference. Figures 13 to 17 The "Orders" API is described in the description.

[0109] Figure 9 A series of sequential views 900, 902, 904, 906 of a user device according to an exemplary embodiment of the present disclosure are depicted, wherein a user can interact with and order services using a micro-application. A second view 902 can be considered a "storefront" and the information displayed in the storefront can be controlled via one or more APIs. This exemplary view sequence 900, 902, 904, 906 is similar to... Figure 8 Besides with Figure 8 Compared to view 800, view 900 has no prior dialogue. Additionally, in this example, a "View QR" button 908 can be displayed in view 906. In response to the user selecting the "View QR" button 908, the user's device can display a QR code associated with the transaction. Another user can take a photo of the QR code and access the same micro-application, such as purchasing tickets for the same movie and time.

[0110] Figure 10A and Figure 10B Exemplary embodiments according to this disclosure are depicted, for example, corresponding to the foregoing reference. Figure 2 and Figure 6 The description includes exemplary views 1000 and 1002 of the user interface for the "discovery" phase, where users can search for micro-applications and / or merchants. More specifically, Figure 10A View 1000 shows an exemplary list 1004 of nearby merchants for which a user can order services through one or more micro-apps. Additional information such as promotional information for nearby merchants may be provided. Figure 10B View 1002 shows a list of user contacts 1006 and suggested merchants 1008. As mentioned above, suggestions 1004, 1006, and 1008 can be based on the user's location and / or preferences.

[0111] refer to Figure 11A Container applications can verify the identity of users on computing devices based on the user accounts associated with the container application. More specifically, in Figure 11A The document depicts a user interface 1100 where a user can "log in" to a pre-existing account accessible from the container application. The container application can authenticate the user by accessing their pre-existing account to "log in the user to" the selected micro-application. For example, a user can select "Continue as [username]" 1102 to log in using a pre-existing account. Therefore, the container application can facilitate user identification and / or authentication across multiple micro-applications, eliminating the need for users to create separate login credentials and / or accounts for each micro-application.

[0112] refer to Figure 11B and Figure 11C Container applications allow users to control what user information micro-applications can access. More specifically, a container application displays a settings panel 1104 prompting the user to indicate whether a specific micro-application is allowed to access the user's phone number and / or a settings panel 1106 prompting the user to indicate whether a specific micro-application is allowed to access the user's current location. Therefore, container applications facilitate user control over what user information the corresponding micro-applications can access.

[0113] refer to Figure 12A and Figure 12B In some implementations, container applications and / or microapplications (e.g., via container applications) can provide suggestions or reminders to the user. More specifically, see [link to relevant documentation]. Figure 12A The container application can remind the user of the balance in their account and provide a "top up" option 1202 or allow funds to be deposited into the user account. Additional options may include a button 1204 for accessing a website or a button 1206 for contacting customer service associated with the user account or microapp. (Reference) Figure 12B The container application can provide a message 1208 suggesting the purchase of items based on the user's previous purchases. For example, message 1208 could suggest purchasing the user's "usual" items (e.g., a previously ordered chocolate cake). Previous messages 1210 could include details about previous orders (e.g., the amount paid and the transaction date). The purchase suggestion message 1208 may have an "order" button 1212 and / or an "edit cart" button 1214, allowing the user to reorder previously ordered items and / or add them to the user's "cart." In some implementations, the container application and / or platform may utilize one or more machine learning models to help generate such suggestions or reminders.

[0114] As mentioned above, container applications / platforms can provide developers with several dedicated APIs. (Reference) Figure 13 As an example, an "Orders" API could be provided, which simplifies and standardizes the process of handling and presenting orders and / or supplies of goods and / or services to users within containerized applications and micro-applications. Before a transaction is completed, the "Orders" API can define an initial set of templates and / or rules regarding how supplies, messages, customer support messages, etc., can be presented to the user. Once the user has selected the goods, services, and / or customized options associated with them, the "Orders" API can facilitate the completion of the transaction. After the transaction is completed, the "Orders" API can control how the user stores, shares, or otherwise manipulates confirmations, status updates (e.g., tracking, delivery status, etc.), deliverables (e.g., trips, tickets, passes), etc. Therefore, when placing orders through a containerized application / platform, the "Orders" API can improve the continuity of the user experience across multiple micro-applications.

[0115] For example, refer to Figure 13 The first template 1300 is shown, in which various placeholders are provided. Placeholders may include desired attributes, optional attributes, and / or attachments for some or all items. Referring to the second template 1302, a first display of information can be predefined, including the position, arrangement, etc., of the information stored in the placeholders. The third template 1303 may define a second set of positions for buttons 1306 used to display such information and / or to perform actions related to the information in the placeholders.

[0116] refer to Figure 14 Table 1400 may include various predefined states, transaction metadata, footprints, card status, and / or verifications. For example, the predefined state 1402 of an order may include "delivering". Transaction metadata 1404 and / or footprint 1406 may include predefined templates for how data describing the predefined state 1402 (e.g., "order status") is displayed.

[0117] The "Orders" API can include rules (e.g., "Validation") that define how an order's status can change. For example, rules can specify which order statuses can and cannot follow other order statuses. In this example, the "Pending," "Waiting," and "Ready" statuses cannot follow the "Delivering" status. It should be understood that these are merely exemplary order statuses and exemplary rules regarding order statuses.

[0118] Additional predefined templates can be provided to display this information for a specific context. For example, predefined message template 1408 and / or predefined receipt template 1410 can be defined to display information.

[0119] Figure 15 A series of sequential views 1500, 1502, and 1504 of a user device implementing an exemplary "Order" API according to aspects of this disclosure are depicted. The first view 1500 shows order confirmation after the user completes a transaction. In the second view 1502, messages 1506 and 1508, a button 1510, and / or a notification 1512 may be displayed according to the "Order" API, such as as referenced above. Figure 13 and Figure 14 As described above. In the third view 1504, receipt 1508 can be displayed according to the "Orders" API (e.g., see above reference). Figure 14 The predefined receipt template described is 1410.

[0120] Figure 16 Exemplary predefined templates 1600 and 1602 are described for displaying electronic goods such as electronic passes (e.g., boarding passes, tickets, etc.). Such predefined templates 1600 and 1602 may be included in the "Orders" API and / or as a separate API (e.g., the "Electronic Goods" API). Figure 17 Additional views 1700 and 1702 of a user device are depicted, showing messages 1704 and 1706, button 1708, and receipt 1710 according to the "Orders" API.

[0121] As mentioned above, various software development kits (SDKs) can be provided corresponding to the respective "use cases" or applications. These SDKs may include different sets and / or different types of APIs suitable for the corresponding "use cases".

[0122] Various aspects of this application also address providing feedback (e.g., in the form of reports or statistics) and / or facilitating troubleshooting for microapp developers with user consent. For example, container applications can collect information about how users interact with various microapps in different situations or scenarios. Microapp developers can use this information to improve their microapps. As another example, microapp developers can set up automated alerts for specific types of errors or user behaviors. For instance, "automatic checks" can be implemented to log every user interaction with a microapp (e.g., up to a level or stage in a predefined process or flowchart) without completing a financial action (e.g., a purchase, payment request, etc.). As yet another example, microapp developers can define specific user feedback issues and / or prompts to be presented within the microapp. These features can be provided within the developer portal for container applications. Therefore, various aspects of this application are aimed at improving the developer experience.

[0123] Exemplary methods

[0124] Figure 18A flowchart depicts an exemplary method for integrating micro-applications into container applications and / or platforms according to exemplary embodiments of this disclosure. Although Figure 18 For illustrative and discussion purposes, the steps are described in a specific order, but the method of this disclosure is not limited to the specific order or arrangement shown. The various steps of method 1800 may be omitted, rearranged, combined, and / or adapted in various ways without departing from the scope of this disclosure.

[0125] At 1802, the computing system can be configured to provide a navigation bar based on data received from the container application, to be displayed within the first panel of the user interface, for example, see reference. Figures 3 to 7C The navigation bar may be displayed within the touch-sensitive display screen 122 of the user computing device 102 (e.g., a smartphone). Container applications may be stored in memory 114 and executed by one or more processors 112 of the user computing device 102, and / or stored in memory 134 of the server computing system 130 and executed by processor 132 of the server computing system 130.

[0126] At 1804, the computing system can be configured to receive application output from at least one micro-application at the container application via an application programming interface. For example, the micro-application can receive application output via, as referenced... Figures 13 to 17 The “Order” API, “Shell” API, “Payment” API, etc., communicate with the container application. These APIs may be stored in memory 114 and executed by one or more processors 112 of the user computing device 102, and / or stored in memory 134 of the server computing system 130 and executed by processor 132 of the server computing system 130.

[0127] At point 1806, the computing system can be configured to provide data describing the application output for display within a second panel of the user interface. The application output may include information about recently placed orders and can be displayed according to one or more APIs. For example, it can be based on the reference above. Figures 13 to 17 One or more of the predefined templates described are used to display information.

[0128] Figure 19 A flowchart depicts an exemplary method for integrating micro-applications into container applications and / or platforms according to exemplary embodiments of this disclosure. Although Figure 19 For illustrative and discussion purposes, the steps performed in a particular order are depicted; however, the method of this disclosure is not limited to the particular order or arrangement shown. The various steps of method 1900 may be omitted, rearranged, combined, and / or adapted in various ways without departing from the scope of this disclosure.

[0129] At 1902, the method may include executing a transaction using a micro-application (e.g., responding to user input requesting the execution of a transaction). For example, a transaction may include ordering goods or services, such as food delivery, purchasing airline tickets, etc., for example, see reference [link to relevant documentation]. Figures 6 to 9 As described above. User touch input can be provided by the user input component 122 that requests to complete the transaction. Figure 1 ) Receive. Data can be sent (e.g., wirelessly via a network 180) to complete a transaction.

[0130] At 1904, the method may include receiving transaction-description data from the microapplication via an application programming interface (API) at the container application. The container application can be configured to receive transaction-description data from the microapplication via the API. Order confirmations, statuses, updates, receipts, etc., can be received via the "Orders" API, as shown in the reference above. Figures 13 to 17 As mentioned above.

[0131] At 1906, the method may include providing data describing a transaction according to an application programming interface (API) for display in a user interface. The API may include a template describing the arrangement of data that describes the transaction within the user interface. Order confirmations, statuses, updates, receipts, etc., may be displayed based on templates included in or defined by the "Orders" API, as shown in the reference above. Figures 13 to 17 The data describing the transaction can be displayed on the touch-sensitive display screen 122 of the user's computing device 102 (e.g., smartphone, tablet, etc.).

[0132] Additional Public Content

[0133] This paper discusses technical reference servers, databases, software applications, and other computer-based systems, as well as the actions taken and the information sent to and from these systems. The inherent flexibility of computer-based systems allows for a wide variety of possible configurations, combinations, and divisions of tasks and functions between and within components. For example, the processes discussed herein can be implemented using a single device or component, or multiple devices or components working in combination. Databases and applications can be implemented on a single system or distributed across multiple systems. Distributed components can operate sequentially or in parallel.

[0134] While the subject matter has been described in detail with reference to various specific exemplary embodiments thereof, each example is provided by way of explanation rather than limitation. Changes, variations, and equivalents to these embodiments will be readily apparent to those skilled in the art upon gaining an understanding of the foregoing. Therefore, this disclosure does not exclude the inclusion of such modifications, variations, and / or additions to the subject matter, which will be apparent to those skilled in the art. For example, features shown or described as part of one embodiment may be used with another embodiment to produce yet another embodiment. Therefore, this disclosure is intended to cover such changes, variations, and equivalents.

Claims

1. A computing system, comprising: Multiple micro-applications, including at least one micro-application; A container application configured to receive application output from the at least one micro-application via an application programming interface; At least one processor; At least one tangible, non-transitory computer-readable medium storing instructions that, when executed by the at least one processor, cause the at least one processor to perform operations, the operations including: A navigation bar is provided based on data received from the container application and displayed within a first panel in the user interface; At the container application, the application output is received from the at least one micro-application via the application programming interface; Provide data describing the application's output to be displayed in a second panel within the user interface; The container application provides a settings panel for globally applying at least one global setting to two or more micro-applications and at least one individual setting to the at least one micro-application. The container application controls the operation of two or more micro-applications among the plurality of micro-applications based on the at least one global setting; and The container application controls the operation of the at least one micro-application based on the at least one individual setting.

2. The computing system according to claim 1, wherein, The operation further includes receiving user input for requesting at least one of a payment or a payment request to be sent to a transaction destination, the transaction destination being described by data output by the at least one micro-application.

3. The computing system according to claim 2, further comprising: In response to the user input, send at least one of the payment or the payment request.

4. The computing system according to claim 1, wherein, Providing data describing the output of the application for display within the second panel of the user interface includes providing data describing at least one of items that can be purchased or services that can be ordered.

5. The computing system according to claim 1, wherein, Providing the navigation bar for display within the first panel of the user interface based on data received from the container application includes: providing at least one of the exit icon or name of the at least one micro-application for display within the first panel of the user interface.

6. The computing system according to claim 1, wherein, Providing the navigation bar for display within the first panel of the user interface based on data received from the container application includes: providing a source indicator for display within the first panel of the user interface, the source indicator describing whether the source of the at least one micro-application corresponds to the source of the container application.

7. The computing system according to claim 1, wherein, The at least one micro-application includes a plurality of micro-applications, and the operation further includes: displaying a plurality of indicators associated with a corresponding micro-application among the plurality of micro-applications within the user interface.

8. The computing system according to claim 1, wherein, The at least one micro-application includes multiple micro-applications, and the operation further includes: displaying multiple category labels describing multiple categories for the multiple micro-applications.

9. The computing system according to claim 1, wherein, The operation also includes: verifying the identity of the user of the computing system based on the user account of the user associated with the container application.

10. The computing system according to claim 1, wherein, The operation further includes receiving user input for requesting shared data, the data describing the application output received from the at least one micro-application via the application programming interface.

11. The computing system according to claim 1, wherein, The application programming interface includes an order API, which is configured to control various aspects of order processing by the at least one microapplication.

12. The computing system according to claim 1, wherein, The application programming interface includes a sensor API, which is configured to control various aspects of data processing from one or more sensors of the computing system by the at least one microapplication.

13. The computing system according to claim 1, wherein, The application programming interface includes a payment API, which is configured to control various aspects of payment processing by the at least one microapplication.

14. A computing system, comprising: Micro-applications; A container application configured to receive transaction-description data from the micro-application via an application programming interface, wherein the container application is capable of storing information not shared with the micro-application. At least one processor; At least one tangible, non-transitory computer-readable medium storing instructions that, when executed by the at least one processor, cause the at least one processor to perform operations, the operations including: Execute transactions using the aforementioned micro-application; At the container application, data describing the transaction is received from the microapplication via the application programming interface; and The application programming interface (API) provides data describing the transaction for display in a user interface, wherein the API includes a template describing the arrangement of the data within the user interface, the data describing the transaction.

15. The computing system according to claim 14, wherein, Providing data describing the transaction in the user interface according to the application programming interface for display in the user interface includes: displaying the order status for delivery of goods in response to the transaction.

16. The computing system according to claim 15, wherein, The application programming interface constrains the changes in the order status.

17. The computing system according to claim 15, wherein, The application programming interface includes an order status template that constrains the display of the order status.

18. The computing system according to claim 14, wherein, The application programming interface includes at least one template for displaying data describing the transaction.

19. The computing system according to claim 14, wherein, Providing data describing the transaction in the user interface according to the application programming interface for display includes: providing an interactive button for display according to the application programming interface, wherein the application programming interface includes a template for displaying the interactive button.

20. The computing system according to claim 14, wherein, Providing data describing the transaction in the user interface according to the application programming interface for display includes: providing a receipt for the transaction for display.

21. A computer-implemented method for integrating micro-applications into container applications, the computer-implemented method comprising: A navigation bar is provided by one or more computing devices based on data received from the container application for display within a first panel in the user interface, the container application being configured to receive application output from at least one of a plurality of micro-applications via an application programming interface; The one or more computing devices at the container application receive the application output from the at least one microapplication via the application programming interface; Data describing the application output is provided by the one or more computing devices for display in a second panel of the user interface; The container application provides a settings panel for globally applying at least one global setting to two or more micro-applications and at least one individual setting to the at least one micro-application. The container application controls the operation of two or more micro-applications among the plurality of micro-applications based on the at least one global setting; as well as The container application controls the operation of the at least one micro-application based on the at least one individual setting.

22. The computer implementation method according to claim 21, further comprising: The one or more computing devices receive user input for requesting at least one of a payment or a payment request to a transaction destination, the transaction destination being described by data output by the at least one microapplication.

23. The computer implementation method according to claim 22, further comprising: In response to the user input, the payment or the payment request is sent by the one or more computing devices.

24. The computer implementation method according to claim 21, wherein, The provision of data describing the application output by the one or more computing devices for display within the second panel of the user interface includes: data provided by the one or more computing devices describing at least one of items that can be purchased or services that can be ordered.

25. The computer implementation method according to claim 21, wherein, Providing the navigation bar by the one or more computing devices based on data received from the container application for display within the first panel of the user interface includes: providing at least one of the exit icon or name of the at least one micro-application by the one or more computing devices for display within the first panel of the user interface.

26. The computer implementation method according to claim 21, wherein, Providing the navigation bar by the one or more computing devices based on data received from the container application for display within the first panel of the user interface includes: providing a source indicator by the one or more computing devices for display within the first panel of the user interface, the source indicator describing whether the source of the at least one micro-application corresponds to the source of the container application.

27. The computer implementation method according to claim 21, wherein, The at least one micro-application includes a plurality of micro-applications, and the method further includes: displaying, within the user interface, a plurality of indicators associated with a corresponding micro-application among the plurality of micro-applications by the one or more computing devices.

28. The computer implementation method according to claim 21, wherein, The at least one micro-application includes multiple micro-applications, and the computer implementation method further includes: displaying multiple category labels describing multiple categories for the multiple micro-applications by the one or more computing devices.

29. The computer implementation method according to claim 21, further comprising: The one or more computing devices verify the user's identity based on the user account associated with the container application.

30. The computer implementation method according to claim 21, further comprising: The one or more computing devices receive user input requesting shared data, the data describing the application output received from the at least one microapplication via the application programming interface.

31. The computer implementation method according to claim 21, wherein, The application programming interface includes an order API, which is configured to control various aspects of order processing by the at least one microapplication.

32. The computer implementation method according to claim 21, wherein, The application programming interface includes a sensor API, which is configured to control aspects of data processing from one or more sensors by the at least one microapplication.

33. The computer implementation method according to claim 21, wherein, The application programming interface includes a payment API, which is configured to control various aspects of payment processing by the at least one microapplication.

34. A computer implementation method for integrating micro-applications into a container application, wherein the container application is capable of storing information not shared with the micro-applications, the computer implementation method comprising: Transactions are executed by one or more computing devices using the micro-application; One or more computing devices receive data describing the transaction from the microapplication at the container application via the application programming interface; as well as One or more computing devices provide data describing the transaction according to the application programming interface for display in a user interface, wherein the application programming interface includes a template describing the arrangement of the data within the user interface, wherein the data describes the transaction.

35. The computer implementation method according to claim 34, wherein, The provision of data describing the transaction by the one or more computing devices in the user interface according to the application programming interface for display in the user interface includes: the one or more computing devices displaying the order status for delivery of goods in response to the transaction.

36. The computer implementation method according to claim 35, wherein, The application programming interface constrains the changes in the order status.

37. The computer implementation method according to claim 35, wherein, The application programming interface includes an order status template that constrains the display of the order status.

38. The computer implementation method according to claim 34, wherein, The application programming interface includes at least one template for displaying data describing the transaction.

39. The computer implementation method according to claim 34, wherein, The provision of data describing the transaction by the one or more computing devices in the user interface according to the application programming interface for display in the user interface includes: the provision of interactive buttons by the one or more computing devices according to the application programming interface for display in the user interface, wherein the application programming interface includes templates for displaying the interactive buttons.

40. The computer implementation method according to claim 34, wherein, Providing data describing the transaction in the user interface by the one or more computing devices according to the application programming interface for display in the user interface includes: providing a receipt for the transaction for display in the user interface.

Images