WO2025221800A1

WO2025221800A1 - Application scenario emulation

Info

Publication number: WO2025221800A1
Application number: PCT/US2025/024784
Authority: WO
Inventors: Joshua Weiss; Michaela SCANZILLO; Richard KICHENAMA; Daniel Ludwig; Michael ELFASSY
Original assignee: Blue Bite LLC
Current assignee: Blue Bite LLC
Priority date: 2024-04-15
Filing date: 2025-04-15
Publication date: 2025-10-23
Anticipated expiration: 2026-10-15

Abstract

A computer-implemented method includes: presenting a page of a second application in a first application; presenting, by the first application, at least one tool usable to set scenario parameters for the second application; obtaining, at the first application, the scenario parameters based on user control of the at least one tool; altering the page of the second application based on the scenario parameters by executing the second application independently from the first application, to obtain an altered page; and presenting the altered page in the first application.

Description

APPLICATION SCENARIO EMULATION

FIELD OF THE DISCLOSURE

[001] This specification relates to systems and techniques associated with application configuration

BACKGROUND

[002] Users can scan real-world objects and marks, such as QR codes, to be directed to corresponding web pages that present information about the objects.

SUMMARY

[003] Some aspects of the present disclosure relate to a computer-implemented method. The method includes: presenting a page of a second application in a first application; presenting, by the first application, at least one tool usable to set scenario parameters for the second application; obtaining, at the first application, the scenario parameters based on user control of the at least one tool; altering the page of the second application based on the scenario parameters by executing the second application independently from the first application, to obtain an altered page; and presenting the altered page in the first application.

[004] This and other methods described herein can have one or more of at least the following characteristics.

[005] In some implementations, the scenario parameters include at least one of: a hardware type or software type of a device accessing the second application; a location of the device accessing the second application; a time of accessing the second application; or a language in which to present the second application.

[006] In some implementations, the scenario parameters include a structured identifier.

[007] In some implementations, the structured identifier includes a uniform resource locator (URL) including one or more tokens indicative of the scenario parameters.

[008] In some implementations, the one or more tokens include at least one of a product number, a batch number, or a serial number. [009] In some implementations, the first application is executed in a first domain, and executing the second application includes executing the second application in a second domain different from the first domain.

[010] In some implementations, the method includes: presenting, by the first application, at least one second tool usable to set content corresponding to the scenario parameters, wherein the page presented in the first application includes the content; obtaining, at the first application, altered content based on user control of the at least one second tool; and altering the page of the second application based on the altered content by executing the second application independently from the first application, to obtain the altered page including the altered content.

[OU] In some implementations, presenting the altered page includes presenting, in a user interface of the first application, a live-updating page of the second application that changes in real time to reflect changes made using the at least one tool.

[012] In some implementations, the user interface includes an iframe in which the live-updating page is presented, and a host of the first application and a client of the second application are configured to communicate with one another using postMessages. [013] In some implementations, the method includes: receiving a user interaction with an element of the live-updating page in the first application; executing the second application in response to the user interaction; and updating the live-updating page in the first application based on the execution of the second application based on the user interaction.

[014] In some implementations, the method includes: receiving a user interaction with an element of the live-updating page in the first application; and, in response to the user interaction, presenting, in the first application, a tool usable to modify the element. [015] In some implementations, the first application is configured to generate a token based on the scenario parameters, the token enabling the second application to access resources associated with the scenario parameters.

[016] In some implementations, the token indicates a location at which the altered page is accessible.

[017] In some implementations, the token is configured to expire after a predetermined time duration. [018] In some implementations, the first application includes a host, and the second application includes a client, and the host and the client are configured to communicate with one another via application programming interface (API) endpoints.

[019] In some implementations, the method includes: storing, at the first application, a value of a local variable corresponding to device access to the page; and updating the stored value of the local variable based on user interaction with the page of the second application.

[020] In some implementations, the first application is configured to generate a structured identifier based on the scenario parameters, and the second application is configured to: parse the structured identifier to obtain at least one token, and render the altered page with content based on the at least one token.

[021] Some aspects of this disclosure describe another method. The method includes: receiving, at a first application, user input indicative of a structured identifier; providing the structured identifier from the first application to a second application; parsing, by the second application, the structured identifier to obtain at least one token; rendering, by the second application, a page based on the at least one token; and presenting the rendered page in the first application.

[022] This and other method described herein can have one or more of at least the following characteristics.

[023] In some implementations, the method includes: generating the structured identifier by the first application, in which generating the structured identifier includes: receiving, at the first application, user input indicative of at least one scenario parameter; and generating the structured identifier such that the structured identifier provides the at least one scenario parameter.

[024] In some implementations, the at least one scenario parameter includes at least one of a serial number, a batch number, or a product number.

[025] In some implementations, the structured identifier includes the at least one scenario parameter.

[026] In some implementations, generating the structured identifier includes: receiving, at the first application, user input including a selection of a schema; and generating the structured identifier with a format that conforms to the schema. [027] In some implementations, the schema includes a GS1 Digital Link schema or a digital product passport (DPP) schema.

[028] In some implementations, the structured identifier includes a uniform resource locator (URL).

[029] In some implementations, the method includes: simulating, by the first application, redirect behavior to generate a second URL that is different from the URL; and presenting the second URL in a user interface of the first application.

[030] In some implementations, the method includes: receiving, in the first application, a direct user edit to the URL; and altering the at least one taken based on the direct user edit.

[031] In some implementations, the at least one token includes at least one of a serial number, a batch number, or a product number.

[032] In some implementations, rendering the page based on the at least one token includes: accessing a third-party data source to obtain a pre-registered state corresponding to a first token of the at least one token; and rendering the page based on the pre-registered state.

[033] In some implementations, rendering the page based on the at least one token includes: accessing a mock state corresponding to a first token of the at least one token, wherein the mock state is provided by the first application; and rendering the page based on the mock state.

[034] In some implementations, the mock state includes at least one of an authentication state, an expiration state, or a lifecycle state.

[035] In some implementations, parsing the structured identifier includes: determining, from among a plurality of schema, a schema to which the structured identifier conforms; and extracting the at least one token from the structured identifier based on a format corresponding to the schema.

[036] In some implementations, the method includes generating the page based on context data that includes at least one of: a hardware type or software type of a device accessing the page, a location of the device, a time of accessing the page, or a language in which to present the page. The context data is provided from the first application to the second application. [037] In some implementations, the method includes presenting the page in the first application includes presenting the page in an iframe of the first application.

[038] In some implementations, the method includes executing the first application and the second application independently from one another.

[039] The foregoing and other disclosed methods can be implemented using a non- transitory computer-readable medium tangibly encoding a computer program operable to cause a data processing apparatus to perform operations of the methods.

[040] The foregoing and other disclosed methods can be implemented using a system including: one or more processors; and one or more computer-readable media encoding instructions that, when executed by the one or more processors, cause the one or more processors to perform the operations of the methods.

BRIEF DESCRIPTION OF THE DRAWINGS

[041] FIG. 1 is a diagram illustrating an example of scanning and page presentation.

[042] FIG. 2 is a diagram illustrating an example of a system including two applications.

[043] FIGS. 3 A-3B are an example of a user interface.

[044] FIGS. 4A-4B are examples of user interfaces.

[045] FIG. 5 is a diagram illustrating an example of a process flow.

[046] FIG. 6 is a diagram illustrating an example of a process for page presentation.

[047] FIG. 7 is a diagram illustrating an example of processing associated with structured identifier handling.

[048] FIG. 8 is an example of a user interface for inputting scenario parameters.

[049] FIG. 9 is a diagram illustrating an example of processing associated with page rendering.

[050] FIG. 10 is a diagram illustrating an example of processing associated with content recommendation.

[051] FIG. 11 is a diagram illustrating an example of processing associated with URL previewing.

[052] FIG. 12 is a diagram illustrating an example of a user interface for URL previewing. [053] FIG. 13 is a diagram illustrating examples of updating processes.

[054] FIG. 14 is a diagram illustrating an example of a process for page rendering.

[055] FIG. 15 is a diagram illustrating an example of a computer system.

DETAILED DESCRIPTION

[056] This disclosure relates to user configuration of pages, e.g., web pages and application pages. When a device navigates to a page (e.g., by scanning a QR code that encodes a Uniform Resource Locator (URL) of the page, or a dynamic URL that redirects to the page), the content of the page may vary based on (i) the content of the URL, which may include one or more tokens as discussed below, and (ii) the context of the navigation. The context can include, for example, an operating system of the device, a language setting of the device, a location of the device, etc. The entirety of the data that determines the content of the page can be referred to as a “scenario.”

[057] Development of pages may be made more difficult by various technical challenges associated with page display and reconfiguration. For example, because page presentation may be closely linked to the scenario in which the page is accessed, it may be difficult for developers to efficiently view the page in various scenarios. For example, developers may want to see how the page will be presented in different contexts such as different times of day, different locations, etc., and/or for different token values such as different batch numbers, product serial numbers, etc. But a developer’s current context may not match a target context for previewing, making context-dependent previewing difficult.

[058] Moreover, in practice, developers may want to preview pages for which backend data, such as states corresponding to tokens, may be unavailable. For example, if a product has not yet been released, a product number for the product - which may be included in a page URL - may not be associated with lifecycle data, expiration data, and the like in third-party databases.

[059] Some aspects of this disclosure provide systems and processing configurations that remedy these challenges. Pages can be rendered to simulate various scenarios directly from structured identifier input, e.g., without requiring (though optionally including) resolution/querying to a backend object or server-side content mapping. For example, because of how some implementations according to this disclosure translate user inputs into rendered and displayed pages, a reliance on the availability of live back- end/third-party data during development can be reduced. This reduces dependency on database lookups and network calls, thereby lowering processing latency, minimizing preview system complexity, and improving runtime availability. As a result, developers are provided with a more responsive and fault-tolerant preview system that remains operable even in partially-configured or disconnected environments.

[060] For example, some aspects of this disclosure provide “speculative” previewing, in which designers can preview dynamic content behavior tied to identifier tokens that are not yet instantiated in the backend. This reduces or eliminates the need to predefine all possible token combinations (e.g., GTIN-batch- serial combinations) as database entries, reducing data preparation overhead and improving the scalability of preview environments, thereby improving the technologies of page rendering and development.

[061] Further, some aspects of this disclosure provide token-based handling of structured identifiers such as URLs of multiple different types. Users can be provided with tools for generating URLs based on tokens, directly editing URLs to be presented with corresponding updated rendered pages reflecting the edits to the URLs, and previewing redirect logic, among other disclosed processes. Some implementations of these processes resolve challenges directly rooted in the technology of structured identifier handling (e g., GS1 DL, DPP, etc.) by linking (i) structured identifiers, (ii) tokenized handling/parsing and (iii) page rendering into a dynamic development environment. For example, in some implementations, structured identifier display/generation and user editing of scenario parameters can be performed jointly and bi-directionally.

[062] Moreover, some implementations of the systems described herein have a high degree of flexibility of scenario previewing. For example, the disclosed systems can feature a protocol (or schema) agnostic architecture that can provide unified handling across multiple different identifier types (e.g., GS1 DL, DPP, NFC, and the like). This modularity improves the maintainability and portability of the previewing systems described herein, allowing structured data simulations to be reused or extended across domains and protocols without duplicating rendering subsystems. [063] Some implementations according to the present disclosure can provide dynamic (e.g., “live” or real-time-updating), adaptive rendering of various different scenario configurations in a streamlined interface, representing an improvement to page development technology.

[064] Additional advantages provided by some implementations of the present disclosure relate to security. Based on the two-application approach of some implementations described herein, application security may be maintained, e.g., in the case of pages that may execute arbitrary scripts. Some implementations of the processes and systems discussed herein can facilitate testing of contextual states and scenarios directly through customizable emulation of real page access, allowing for efficient, complete testing and development of context-specific pages. This can be performed using a two-application system with independent execution (e.g., execution on different devices, on different domains, and the like) to maintain security.

[065] Two-application execution presents technical challenges for exchanging data between the applications such that each application can execute independently and successfully. Some aspects of the present disclosure provide data processing and transfer processes that satisfy security needs while providing dynamic page rendering behavior, e.g., through the use of structured identifiers that directly guide page rendering, “mock” states that reduce backend dependency, iframes and postMessages for presenting rendered pages, and the like. The processes described herein (e.g., data architectures and handling) can provide dynamic page updating to reflect state changes within a lifecycle of a page (e.g., after an initial loading event and before a refresh event or reload event, such as to reflect user interactions with the page to test the page’s functionality), resolving technical challenges associated with joint execution of two applications for experience previewing.

[066] FIG. 1 illustrates a non-limiting example of page access. A user uses a device 100 (e.g., a smartphone or another mobile device) to scan a mark 102, e.g., a near field communication (NFC) tag or a marker or barcode, such as a QR code. For example, the device 100 can scan the NFC tag using a wireless module of the device 100 or can use a camera of the device 100 to capture an image of the barcode. [067] In this example, the mark 102 is associated with (e g., provided on or in) an object 104, e.g., a watch or other product for sale. A page associated with the mark 102 can provide object-specific text (such as serial number, model number, warranty information, authenticity information, etc.), images, and/or other media. For example, the page can include a picture of the watch, and the picture of the watch can have a wristband color matching a color of the wristband of the real-world watch. Presentation of pages specific to particular objects or classes of objects (e.g., a page corresponding to a given stock keeping unit (SKU)) can enhance the value of the objects (e.g., by allowing for authenticity verification) and/or allow users to access information relevant to the objects. [068] As shown in FIG. 1, based on scanning the mark 102, the device 100 accesses a page 112 corresponding to a current scenario. For example, the mark 102 can encode or include a web address (e.g., uniform resource locator (URL)), application address, or other page identifier 114 usable to retrieve the page 112. The page identifier 114 can be a “structured identifier,” discussed in more detail below, that provides (e.g., encodes or includes) one or more tokens indicative of characteristics of the object 104. The device 100 uses the page identifier 114 to access the page from a page server 108 through a network 106, e.g., the Internet.

[069] By providing the page identifier 114, the device 100 can provide one or more tokens 132 that are provided by the page identifier 114. The tokens 132 can be tokens 710 discussed below. In some implementations, the device 100 further provides context data 130 that can alter how the page will be presented (e.g., that correspond to a context). The context data 130 and the tokens 132 can together be referred to as scenario parameters 116, and the scenario parameters 116 can be referred to as an “interaction payload” or as “metadata.” The context data 130 can include, for example, a location of the device 100 (e.g., a region, a country, a town or city, a ZIP code, an address, etc.), a user preference (e.g., a default or selected language of the device 100), an operating system of the device 100 (e g., Android or iOS), hardware information of the device 100 (e.g., display size, device type/model, etc.), and/or a current time. The tokens 132 can include, for example, a serial number, a batch number, a product number, and/or the like. [070] In some implementations, instead or additionally, one or more (e.g., all) of the scenario parameters 116 can be obtained/determined by the page server 108, e.g., without necessarily being provided by the device 100. For example, the page server 108 can obtain an Internet Protocol address (IP address) for the device 100 and determine the location of the device 100 based on the IP address. As another example, the page server 108 can determine the current time without requiring the current time to be provided by the device 100. In some implementations, the scenario parameters 116 include third-party data such as product information and/or an NFC verification state.

[071] In some implementations, the scenario parameters 116 - for example, the context data 130 - include one or more parameters that can be obtained (e.g., by the page server 108 or by the child application 204 discussed below) from a third-party platform 110. For example, the page server 108 can use the device’s location to determine current weather conditions for the device by accessing a third-party weather service, can access tracking data provided by the third-party platform 110 to determine behavior patterns associated with a user of the device 100, and/or can access an external data feed provided by the third-party platform 110 to obtain other types of data. The weather, behavior patterns, and/or data are examples of scenario parameters 116 that affect how the page 112 is presented.

[072] In some implementations, the page server 108 provides the page 112 corresponding to the scenario based on the scenario parameters 116. For example, the page server 108 can access a stored mapping between elements of the page 112 (e.g., text, images, video, audio, etc.) and corresponding scenario parameters 116. For example, a first image can correspond to morning, and a second image can correspond to evening; the page server 108 can determine, based on the current time (an example of context data 130), whether to select the first image or the second image, and the provided page 112 can include the selected image. As another example, the page server 108 can include, in the page 112, text in a language selected by the device 100, where the language selection is an example of context data 130. As another example, user interface elements of the page 112 can be presented in a style that is based on the operating system and/or hardware of the device 100, examples of context data 130. As another example, if the page server 108 determines the scanned NFC tag to be valid/authentic (where the authenticity state corresponds to a token 132 included in the page identifier 114), exclusive information can be included in the page 112. As another example, if a batch number of the scenario parameters 1 16 - a token 132 in the page identifier 114 — corresponds to an “expired” state (where, for example, the object 100 is a food product or a pharmaceutical), the page 112 can include an expiration warning. As another example, context data 130 can include a user role, and the page 112 can vary depending on the user role, such that a designer can preview how a regulatory reviewer, marketing team member or consumer might each experience different metadata-driven content variants. [073] Some implementations according to this disclosure provide methods and systems associated with configuring and previewing the page 112 based on the scenario, e.g., configuring the stored mapping between elements of the page 112 and corresponding scenario parameters 116, and previewing corresponding rendering results. [074] Some implementations according to this disclosure may be compatible with, or used in conjunction with, structured product identifiers, examples of page identifiers 114. Examples of structured identifiers include GS1 Digital Link (GS1 DL), URLs and associated data carriers, and Digital Product Passport (DPP) payloads. These identifiers can embed or be linked to product-specific scenario parameters 116 (or metadata) such as batch identifiers, serial numbers, Global Trade Item Numbers (GTINs), lifecycle attributes, stock data, and the like.

[075] For example, a GS1 DL for a product can be associated with one or more data carriers such as a QR code, a data matrix, an NFC tag, an RFID tag, and/or the like.

Customers may interact with (e.g., scan) the data carrier to access Internet-based product- related experiences that include one or more pages 112. For example, the pages 112 can include product information, promotions (e.g., coupons), product guides and frequently asked questions, etc. Retailers and supply-chain partners may interact with the data carrier to access lifecycle information, stock information, authenticity data, and the like. Third-party applications may interact with the data carrier to provide related data and products. As such, the GS1 DL represents a unified, multipurpose data carrier (e.g., barcode) that can be used to flexibly distribute information to various types of users in various scenarios.

[076] However, existing systems may lack the capability to simulate how metadata affects rendered output of, and runtime content logic of, user-facing experiences. This deficiency may result in blind spots when testing and validating experiences that dynamically respond to compliance, localization, and/or product-specific rules associated within GS1 DL or other identifiers. Experience designers may be unable to validate regulatory compliance, localization behavior, metadata-driven content logic, or personalization rules before deployment.

[077] Based on the systems and processes described herein, users can configure and preview how experiences and pages linked to GS1 DLs, and other identifiers, adapt to various metadata. For example, designers can preview experience variations tied to supply chain conditions associated with a product (an example of a scenario parameter 116), compliance status for a product (an example of a scenario parameter 116), personalization logic (an example of a scenario parameter 116), and the like. This allows structured metadata to drive scenario-based rendering during the experience/page design phase, providing the systems described herein with significant application in traceability, regulatory frameworks, and contextual product content, among other domains. Designers can test how structured identifiers, such as GS 1 DL URLs and DPP payloads, adapt dynamically based on metadata associated with product status, supply chain attributes, and jurisdiction-specific regulations, among other types of scenario parameter 116.

[078] FIG. 2 shows an example of a system 200 for viewing and/or configuring presented pages corresponding to different scenarios. The system 200 includes a parent application 202 and a child application 204. As discussed in further detail below, the system 200 can represent a preview architecture that supports simulation of experiences and content - as provided by the child application 204 - in response to different structured identifiers and metadata. The parent application 202 sends scenario parameters (for example, in the form of structured identifiers 240 and, optionally, context data 130) to the child application 204, which provides renderings based on the scenario parameters. This decoupled previewing enables design-time validation of lifecycle-dependent content, personalization logic, regulatory messaging, and other types of scenarios. Stakeholders can benefit by reviewing localized or scenario-based variations of presented content before the content is deployed, while technical teams can advantageously test how structured inputs map to dynamic content rendering.

[079] The parent application 202 and the child application 204 can execute independently from one another. For example, the parent application 202 and the child application 204 can execute on separate servers, in separate processes of an operating system, or in separate domains. For example, a server component of the parent application 202 can execute at studio, [domain-here], com, and a server component of the child application 204 can execute at *. [domain-here] .io, where * is a user- or accountspecific placeholder. Accordingly, the server components are on different domains and are cross-origin.

[080] For example, the parent application 202 and the child application 204 can be separate web applications, each having its own server component that performs page- rendering (e.g., an application execution module 214 for the child application 204, and another module for the parent application 202). Each can include a different client-side application running in a browser of a user the parent application 202. The servers on which the server components of the parent application 202 and the child application 204 execute can be separate computer systems. The client side applications corresponding to the parent application 202 and the child application 204, respectively, can run in the same browser but can be hosted on separate domains; accordingly, browser-based security protocols that isolate separate-domain web pages from one another can advantageously provide improved security.

[081] Although referred to herein as “parent” and “child” applications, the applications 202, 204 need not have any nesting, hierarchy, or other similar relationship. The parent application 202 can equally be referred to as a “first” application, and the child application 204 can equally be referred to as a “second” application.

[082] Security can be important in the context of development/configuration of the child application 204. For example, in some implementations, the child application 204 can execute arbitrary or custom scripts/code, such as JavaScript. If this code were run directly in the parent application 202, or if the code had access to the parent application 202, the code might present a security risk. According to some implementations of the present disclosure, a boundary is maintained between the parent application 202 and the child application 204, providing for independent execution (e.g., on separate domains). For example, as discussed below, pages of the child application 204 can be presented in an iframe of the parent application 202. Messages (e.g., messages including tokens, and/or postMessages) can be sent across the boundary in a manner compatible with security. Accordingly, users can configure the child application 204 with custom code without a security risk to the parent application 202 or a platform thereof.

[0831 The parent application 202 can be a design application, e.g., including tools for testing, designing, and/or developing applications such as web applications. The child application 204 can be an application tested, designed, and/or developed using the parent application 202. For example, the child application 204 can be a web application, website, or web page, a page of which (e.g., a website of which) is provided by the page server 108 as described with respect to FIG. 1. The applications 202, 204 can be web applications (e.g., executing within a web browser) and/or installed applications such as mobile apps and/or desktop applications. In some implementations, the child application 204 is a dedicated previewing engine for use in conjunction with the parent application 202, e.g., there need not be (though may be) an expectation that the child application 204 will be run by users without corresponding execution of the parent application 202.

[084] The parent application 202 can include scenario configuration tools 206, an emulation host 208, a child application visualization module 210 in which an emulation client 212 executes, and a recommendation module 220. The parent application 202 can include further modules not shown in FIG. 2. The parent application 202 can include a server-side component and a client-side component.

[085] The child application 204 can include the emulation client 212 and an application execution module 214. The child application 204 can include further modules not shown in FIG. 2. The child application 204 can optionally include a server-side component and a client-side component. The server-side component of the child application 204 can execute on a different domain than the server-side component of the parent application 202. When the parent application 202 is being used to develop the child application 204, the client-side components of the applications 202, 204 can be executed by a common computing device/system (e.g., by a browser of a user device), but can be executed separately. For example, as discussed below, an iframe mechanism can allow the client-side component of the child application 204 to reside visually inside the client-side component of the parent application 202 while being executed separately from the parent application 202. [086] The applications 202, 204 and the elements thereof can be implemented, for example, as software, programs, and/or applications executing on one or more computer systems. For example, one or more hardware processors can execute instructions (e.g., instructions stored in a non-transitory computer-readable medium such as a memory) that, when executed, cause the one or more hardware processors to perform the operations described herein for the applications 202, 204 and the elements thereof. In some implementations, a computer system that executes the parent application 202 is distinct from a computer system that executes the child application 204. It will be understood that the elements of the applications 202, 204 can be split and/or combined in various ways, and that the applications 202, 204 can include other and/or alternative modules configured to perform the operations described herein for the applications 202, 204, and/or other operations.

[087] In some implementations according to this disclosure, the parent application 202 is used to configure the child application 204, and/or to provide data to the child application 204 that the child application 204 uses for preview rendering. The parent application 202 presents a user interface, such as user interfaces 300, 400, 800, 1200, through which designers can define a scenario to be simulated in a child application 204. The scenario corresponds to a specific set of conditions — such as structured metadata values, object states, lifecycle stages, and/or third-party data — that influence rendering behavior in the child application 204. The parent application 202 sends scenario parameters 116 - e.g., a structured identifier 240 and/or context data 130, as shown in FIG. 2 - to the child application 204.

[088] The child application 204, in some implementations executing independently from the parent application 202, executes based on the configuration/scenario set in the parent application 202, and pages of the thus-executed child application 204 are presented, in the parent application 202, by the child application visualization module 210. For example, based on user configuration of a scenario in the parent application 202, the scenario is obtained and transmitted to the child application 204 - which can be referred to as a preview engine - and executed independently of the parent application 202. The child application 204 renders a page based on the scenario, applying the structured metadata provided by the parent application 202 to dynamically determine which content modules, logic branches, or conditional rendering paths should be activated.

[0891 The application execution module 214 can be configured to perform primary execution of the child application 204, e.g., evaluating the scenario parameters 116, generating pages 232, performing internal application processing, responding to user interactions in the page 232 as presented in the parent application 202, etc.

[090] The scenario configuration tools 206 are configured to allow users to (i) set a scenario of a page 232 to be displayed by the child application visualization module 210, (ii) adjust what elements/content are included in the page 232 corresponding to the scenario parameters 116, and/or (iii) provide for visualization of page state information and errors associated with applied scenarios. The scenario configuration tools 206 can include appropriate user interface elements such as text entry interfaces, buttons, dropdowns, toggle controls, menus, etc., along with suitable corresponding functions to implement user selections. The user selections provide scenario parameters 116 that will be provided to the child application 204 as a structured identifier 240 and/or context data 130.

[091] For example, FIG. 3A and 3B illustrate a user interface 300 that can be presented by the parent application 202, e.g., by a display module of the parent application 202. The user interface 300 includes a content configuration interface 302, a page presentation interface 304, and a scenario configuration interface 306. In some implementations, the interfaces 302, 306 can be provided by the scenario configuration tools 206, and the page presentation interface 304 can be provided by the child application visualization module 210.

[092] The scenario configuration interface 306 includes interface elements that enable a user to set a scenario (e.g., to set scenario parameters 116) according to a page 232 will be rendered and displayed in the page presentation interface 304. In the example of the user interface 300, the interface elements include elements usable to set context data 130 such as operating system (OS), language, location, time, batch, serial number, expiration date, GTIN, and DPP lifecycle phase.

[093] In some implementations, the scenario configuration interface 306 includes interface element(s) 310 that can be used to input portions of, or an entire, GS1 DL, or other protocol-based URL, to be provided as a structured identifier 240. For example, the scenario configuration interface 306 can include interface elements that permit entry of token(s) 710, directly or implicitly as part of entry of a structured identifier 240.

Examples of such interfaces, which can be included in the scenario configuration interface 306, are user interfaces 800 and 1200, discussed in more detail below.

[094] An interface element 308 can be selected to apply the currently-selected set of scenario parameters to the child application 204 in the page presentation interface 304, e.g., to trigger parsing and rendering by the child application 204 based on the latest input scenario parameters 116.

[095] The content configuration interface 302 includes interface elements that enable a user to configure the child application 204 for the scenario selected in the page presentation interface 304. For example, in the case of the user interface 300, by interacting with the interface elements of the content configuration interface 302 (and based on the current settings in the page presentation interface 304), a user can select what content will be provided to a device when the device accesses a page of the child application, in the case where the device is an Android device using English, where the location of the device is unknown or generic, and where the time is the current date and time. As shown for the user interface 300, the interface elements of the content configuration interface 302 enable users to insert into the child application 204, and configure, format, and set styles for, text, buttons and other interactive interface elements, media, images, dynamic responses such as actions, and embeddings of various websites and applications, to provide several non-limiting examples of configurable content. When the child application 204 performs rendering based on scenario parameters 116, rendered pages 232 can, in some implementations, include content that has been set in the content configuration interface 302.

[096] To this end, the parent application can provide content configuration data 250 to the child application 204, the content configuration data 250 providing content, settings, and the like to be used by the application execution module 214 for rendering of pages 232. The content configuration data 250 can be based on user inputs in the scenario configuration tools 206. [097] Conventional content configuration tools can be presented by the content configuration interface 302 for this purpose. However, in some implementations, contrary to conventional approaches, the content that is set is not generic content for the child application 204 but, rather, is linked to one or more scenario parameters 116, such that the configured content is rendered conditional on the inclusion of particular values of the scenario parameters 116.

[098] At least some of the content configurable using the content configuration interface 302 can be specific to an object or class of objects. For example, a given page (sometimes referred to as an “experience”) of the child application may be presented in response to a device scanning multiple different objects or classes of object. However, the content in the page can at least partially vary based on the object or class of object. For example, the “Object Attribute” element of the interface 302 can be used to set or select an attribute of an object or class of objects, and other elements of the interface 302 can then be used to configure content corresponding to the attribute. For example, in a case in which an image of a watch is presented in the page presentation interface 304, an Object Attribute can be “strap color.” Different values of “strap color” can correspond to different images of watches that have the different strap colors, and the different values of “strap color” can also be configured to correspond to different real -world objects. Accordingly, for example, referring again to FIG. 1, when the device 100 scans a watch having a brown strap (as the object 104), the presented page includes an image of the same type of watch having the same color strap.

[099] In the foregoing example, “strap color” can be reflected in a serial number or other token 710, so that rendered content varies based on the token 710.

[0100] The page presentation interface 304 presents a page of the child application, the page generated by executing the child application according to configurations in the interfaces 302, 306. For example, in the case of the user interface 300, the page presentation interface 304 presents a page of the child application, the page designed to exhibit features of the system 200. For example, a button under “OS” varies with the scenario based on the OS of the scenario; text under “Language” is displayed in the language of the scenario; and a map under “Location” can indicate the location of the scenario. The button, the text under “Language,” and configuration of the map can be set using the content configuration interface 302. The page presentation interface 304 can be presented alongside design-focused interfaces such as the interfaces 302, 306, and/or can be provided in a separate user interface.

[0101] Providing the page presentation interface 304 directly in the user interface 300 of the parent application 202 can advantageously allow scenarios to be directly simulated and tested in-place.

[0102] In some implementations, the page of the child application in the page presentation interface 304 is presented in an iframe, e.g., an iframe embedded in the parent application. The use of a cross-domain iframe can permit presentation of pages of the child application while maintaining isolated, independent execution of the parent application and the child application.

[0103] Configurations/settings in the interfaces 302, 306 can be applied in the page presentation interface 304 in one or more suitable ways. Referring again to FIG. 2, communication between the parent application 202 (in which the child application 204 is configured) and the child application 204 can be performed via the emulation host 208 and the emulation client 212. The emulation host 208 and emulation client 212 can communicate with one another, e.g., via application programming interface (API) endpoints. The emulation client 212 can be middleware installed into a runtime system of the child application 204. The emulation client 212 is configured to facilitate one-way and/or two-way communication with the emulation host 208. For example, the emulation client 212 can be configured to detect changes to an internal state of the child application 204, e.g., based on user interaction with the page presentation interface 304 and/or based on updates made to the configuration of the child application in the content configuration interface 302. Based on the detected changes, the emulation client 212 can cause the application execution module 214 to execute the child application 204 based on the detected changes, and an updated page of the child application 204 (reflecting the changes) can be presented in the page presentation interface 304. In some implementations, the emulation client 212 is configured to detect errors and/or lifecycle events (e.g., updates to local variables) that occur in the child application 204. The emulation client 212 can communicate information indicative of the errors and/or lifecycle events to the emulation host 208, which can cause information about the errors and/or lifecycle events to be displayed in the parent application 202 (e g., in the state visualization interface 402 discussed below).

[0104] For example, as shown in FIG. 2, the emulation host 208 can send a structured identifier 240 and/or context data 130 to the emulation client 212, thereby providing data indicative of scenario parameters 116, configuration/scenario changes, and the like to the emulation client 212. Data can be sent in the form of postMessages or another suitable protocol. The emulation client 212 can send updated page states to the emulation host 208, which allows display of the updated page states by the child application visualization module 210. In accordance with the isolated, independent execution of the applications 202, 204, the emulation host 208 and the emulation client 212 can be in separate domains, and communication therebetween can be cross-domain between the two separate domains. For example, postMessages can be sent cross-origin, between the child application 204’ s domain and the parent application 202’ s domain

[0105] As examples of operations that the emulation client 212 can be configured to perform, in some implementations, the emulation client 212 can retrieve (e.g., via an API token as discussed below), or be provided with, scenario parameters 116 and, based on the scenario parameters 116, configure an initial state for the child application 204. A corresponding page 232 can be rendered by the child application 204 and presented in the parent application 202. This processing can be performed, for example, as described with respect to FIGS. 7 and 9 below.

[0106] The emulation client 212 can monitor for changes to the scenario parameters 116 and/or corresponding content. For example, the emulation client 212 can listen for messages from the emulation host 208 and modify rendering of the page 232 to apply changes described in the messages. The emulation client 212 can provide an interface to the child application 204 that allows the child application 204 to update its page state information and present the page state information in the parent application 202. The emulation client 212 can monitor for state changes within the child application 204 (e.g., changes to content displayed by the child application 204, errors, variable updates, etc.) and communicate the state changes to the emulation host 208, resulting in an updated page 232 of the child application 204 being displayed by the parent application 202 and/or other information, such as error information and/or variable information, being displayed by the parent application 202.

[0107] The state changes can include, for example, user interactions such as clicks/taps on user interface elements of pages 232 rendered by the child application 204 and presented in the parent application 202. These interactions can cause a change in a variable value, and the emulation client 212 can relay the updated value to the emulation host 208. In some implementations, the emulation client 212 can send information on the interacted-with interface element, which can allow, for example, identification of the interacted-with portion of a page more quickly. That is, the previewed pages 232 need not be static but, rather, in some implementations can be interacted with by a user in the page presentation interface 304, as the page 232 could be in a real-world usage scenario.

[0108] As examples of operations that the emulation host 208 can be configured to perform, in some implementations, the emulation host 208 creates initial scenario states by saving a set of scenario parameters 116 and generating an expiring token 260 (not to be confused with the tokens 710) associated with the set of scenario parameters 116. In some implementations, the emulation host 208 obtains changes (e.g., to the scenario parameters 116 and/or content configuration data 250) made in the content configuration interface 302 and/or the scenario configuration interface 306, determines data/massages to be sent to the child application 204 via the emulation client 212 based on the changes, and sends the messages. In some implementations, the emulation host 208 is configured to provide a mechanism for the parent application 202 to monitor for status updates from the child application 204, e.g., when the user navigates to a different page in the child application 204, changes a state of the page, or clicks an element of the page in Inspection Mode (discussed below).

[0109] In some implementations, a token system is used to apply at least some configurations to the child application 204. Based on configuration of scenario parameters 116 (e.g., using the scenario configuration interface 306), the parent application 202 (e.g., the emulation host 208) can generate a token 260, e.g., an API token. This token 260 can be different from the tokens 710 discussed below. The token 260 can be, include, or be similar to the tokens 710 discussed below. The token 260 is an identifier for the set of scenario parameters 116 and enables the child application 204 to access content configured for the set of scenario parameters 116. For example, the token can represent the scenario parameters 116 in a protocol of a content platform 216. The content platform 216 can be any suitable platform integrated together with the child application 204 or the parent application 202 (e.g., executing on a common server with the child application 204 or the parent application 202) and/or can be a separate platform, e.g., a platform accessed through the Internet. The content platform 216 can include a computer system storing content to be used by the child application 204 to generate pages that are then presented by the child application visualization module 210. The content platform 216 can include multiple platforms. The content platform 216 can be a third- party platform and/or can include content, data, and the like directly controlled by, for example, the parent application 202.

[0110] As shown in FIG. 2, the emulation host 208 can generate the token 260 and send the token 260 to the child application 204, e.g., to the emulation client 212. The emulation client 212 can provide the token 260 to the application execution module 214, which accesses the content platform 216 using the token 260 to obtain content associated with the token 260. For example, the content platform 216 can store the content in association with the token 260, such that the child application 204 can retrieve the stored content using the token 260. For example, in a case in which the content platform 216 is a platform of the parent application 202, the parent application 202 can store content configured for the set of scenario parameters 116 in association with the token 260. Upon receiving the token 260, the content platform 216 can obtain the content based on the association and provide the content to the child application 204. However, as noted above, the content platform 216 need not be associated with the parent application 202. The token can be, or can be associated with, an alphanumeric string or other encoding symbol.

[0111] In some implementations, the token 260 provides permissioning. For example, the token 260 can be temporary (e.g., can be associated with a “time to live” (TTL)). While the token 260 is active, pages 232 corresponding to scenario parameters 116 corresponding to the token 260 can be accessed. After expiry of the token 260, the pages 232become inaccessible. Accordingly, content and pages can be tested and configured while maintaining security. [0112] In some implementations, the token 260 is or indicates a location, e.g., a network location or a file location, at which a rendered page 232 can be accessed. For example, the token 260 can be a string appendable to a URL to access the page of the child application 204 (e.g., in a format “mychildapplication.com?token={token}”). The token 260, added to the URL of the child application, can give temporary access to the emulation API and allow the child application 204 (e.g., the emulation client) to conform to the selected scenario, e.g., during a page's initial render. In some implementations, the child application 204 obtains the token 260 based on the token’s inclusion in a URL. For example, the parent application can include the token 260 in a URL of a page to be embedded in the iframe, such that the child application receives the token 260 in the URL of the page being generated by the child application.

[0113] In some implementations, the token 260 discussed above is a structured identifier 240 and/or is included in a structured identifier 240. For example, the token 260 can be a token 710 included in a structured identifier 240.

[0114] In some implementations, a token 260 as described above is not used.

[0115] In some implementations, the parent application 202 can send messages to the child application 204 to alert the child application 204 to changes in the scenario and/or content corresponding to the scenario (the changes made using the interfaces 302 and/or 306). For example, the emulation host 208 can send messages to the emulation client 212, the messages indicating the changes. For example, in cases in which a page 232 of the child application 204 is embedded in the page presentation interface 304 as an iframe, the emulation host 208 can send postMessages to the emulation client 212 in the iframe. The messages can indicate alterations to content of the page 232 rendered by the child application 204, and/or to scenario parameters 116 corresponding to the page 232 of the child application 204. The application execution module 214 modifies and/or regenerates one or more pages 232 based on the changes (e.g., to reflect the changes). For example, the emulation client 212 can send a received message, content of the message, and/or data indicative of the changes to the application execution module 214.

[0116] Based on the communication between the parent application 202 and the child application 204, configurations made by a user in the configuration interfaces 302, 306 can be reflected an updated page 232 shown in the page presentation interface 304. For example, the application execution module 214 can provide modified and/or regenerated pages 232 to the emulation client 212, and the emulation client 212 can cause presentation of the pages in the interface 304 (e.g., in an iframe). Additionally, or alternatively, the application execution module 214 can cause the modified and/or regenerated pages to be available at a predetermined location (e.g., at a URL specified by a token, as discussed above), and the parent application 202 can access the pages at the predetermined location (e.g., by performing a refresh operation such that a previously- accessed page at a URL is displayed in updated form).

[0117] FIG. 7 illustrates an example of processing 700 by the application execution module 214, represented as functional blocks and operations. As shown in FIG. 7, a structured identifier 240 is received (e.g., provided by the parent application 202). The structured identifier 240 is parsed (702) to extract one or more tokens 710 (706), a process that can be referred to as tokenization.

[0118] The structured identifier 240 can have a form or structure that conforms to a known schema or protocol such as GS1 DL, DPP, NFC Data Exchange Format (NFC NDEF), custom protocols (for example, user-defined protocols), etc. The structured identifier 240 includes one or more tokens 710 that can be extracted. For example, the structured identifier 240 can have a URL format, such as a GS1 DL structured identifier, an example of which is “https://example.org/gtin/0123456789012/batch/ABC123/serial/001122”. The application execution module 214 can parse the URL to obtain a GTIN “0123456789012,” a batch number “ABC123”, and a serial number “001122,” each of which is a token 710.

[0119] To perform the parsing and extraction, the application execution module 214 can identify (704) a protocol, pattern, or schema (collectively referred to as a “schema”) to which the structured identifier 240 conforms. The application execution module 214 can identify (i) a type of the structured identifier 240 (e.g., GS1 DL, DPP, or the like) and (ii) which token(s) are encoded in the structured identifier 240. For example, in the example shown in FIG. 7, the application execution module 214 can identify that the provided URL conforms to the GS1 DL schema and includes a GTIN, a batch number, and a serial number. This can be performed using suitable schema validation and/or identification logic. [0120] Suitable fallback handling can be performed to account for partial or malformed inputs. For example, if a token 710 is identified as incorrectly formatted (e.g., not matching a known token 710, having a wrong number of digits or otherwise being malformed, or the like), the application execution module 214 can replace the token 710 with a default token value that is usable for page generation.

[0121] In some implementations, the extracted tokens 710 are buffered into a transient session memory, session store, or the like, from which the extracted tokens 710 can be obtained for further processing in the process 700.

[0122] As shown in FIG. 7, one or more extracted tokens 710 are used to render (712) pages 232 based on the tokens 710. Rendering the pages 232 can include generating payloads 720. For example, generation of the payload 720 can include evaluation of conditional logic (708). The conditional logic can include conditional rendering logic in which one or more visual elements are (i) rendered based on the presence of a certain type of token 710 and/or (ii) rendered differently depending on the value of a token 710. For example, the conditional logic can result in rendering of a product-specific disclaimer associated with an extracted GTIN, can render a warranty status associated with an extracted serial number, and/or can activate unit-level traceability features associated with an extracted batch number, based on what types of tokens 710 are included in the structured identifier 240. Rendering of different types of content can correspond to activation, invocation, or execution of different corresponding logic paths by the application execution module 214. Rendering of conditional logic can be performed in generation of the payloads 720 and/or in execution of the rendering engine 722 based on the payloads 720.

[0123] The payload 720 can include data that indicates what content is to be rendered, can include content to be rendered, and/or the like, based on the evaluation of the conditional logic (708). The payload 720 can mirror a payload that would be generated at runtime upon scanning a physical QR code, and, correspondingly, pages and experiences rendered by the child application 204 can mirror payloads that would be generated at runtime upon scanning a physical QR code. Based on the payload 720, the application execution module 214 can render (722) a page 232 and send the page 232 to the parent application 202 for display. The payload 720 can be, for example, a data object including experience tree data and simulated object/interaction data.

[0124] As such, pages presented to a user can reflect different experiences depending on the scenario parameters 116, e.g., depending on the tokens 710 included in a provided structured identifier 240, and in some cases depending on other scenario parameters 116, such as context data 130, provided by the parent application 202 to the child application 204. For example, a GTIN-only input may result in a default brand-level experience. A GTIN + batch input may resulting in rendering of content tied to manufacturing data or shelf life. A GTIN + batch + serial may trigger unit-level traceability modules, such as authenticity verification or warranty status display, and rendering of corresponding content. Rendering (712) can include execution of a rules engine to determine which logic paths and rendering routines to execute, based on which metadata tokens (or fields) are present in the structured identifier 240. By being configured to parse structured identifiers 240 having various different formats and types of tokens 710, the child application 204 can support previewing of a range of data configurations that may be commonly encountered in serialized product tracking. As such, granular testing across various identification levels can be achieved.

[0125] The application execution module 214 can operate for both previously-defined objects, tokens, and content, and for “undefined,” “speculative,” or “objectless” previewing in which tokens 710 may not correspond to defined backend objects.

[0126] With respect to objects, tokens, and content that have been previously defined, the application execution module 214 can enrich the payload 714 with third-party data, content, and/or metadata (716), referred to collectively as third-party data. For example, the third-party data can be provided by a content platform 216. The content platform 216 can include, for example, a GS1 Resolver service or a similar platform for other protocols. Instead, or additionally, the content platform 216 can include a recall database, a sustainability registry, and/or an industry-specific compliance service. The content platform 216 can include one or more of these types of platforms, which can be separate and/or integrated with one another, such that the content platform 216 can include multiple platforms. [0127] The application execution module 214 can send extracted tokens 710 to the content platform 216, and the content platform 216 can provide third-party data, corresponding to the tokens 710, to the application execution module 214 for inclusion in payload 720, use in evaluating condition logic based on the tokens 710, presentation in rendered pages, and/or the like.

[0128] As an example, a token such as serial number, batch number, or GTIN included in the structured identifier 240 can correspond to one or more states. The states can include: an authenticity state (e.g., authentic/inauthentic, or verified/unverified), expiration state (e.g., expired/unexpired), recall state (e.g., recalled/un-recalled), lifecycle state (e.g., “in-use” or “end-of-life”), an error condition (e.g., indicating a timeout or a malformed payload), and/or the like. These states may be stored in or known to the content platform 216. The states can be retrieved based on the extracted tokens 710, and data/content based on the tokens can be included in the payload 720 for corresponding presentation in a page. For example, the page can include text such as “this product is expired,” “this product is authentic,” or the like, based on the third-party data.

[0129] Instead of, or in addition to states, tokens can be associated with objects such as text, graphics, animations, other media types, and the like. These objects can be provided by the content platform 216 for inclusion in the payload 720 and inclusion in rendered pages presented in the parent application 202.

[0130] Further, instead of or in addition to states and objects provided by the content platform 216, the application execution module 214 can be configured to process tokens and provide corresponding output even in a case where one or more types of third-party data corresponding to a token 710 are unavailable. This can be referred to as injection (718) of simulated return states. For example, one or more of the tokens 710, or a combination of two or more of the tokens 710, may not be previously registered in the content platform 216 or otherwise. For example, an extracted batch number may not correspond to a product batch that has been actually manufactured or registered. As another example, an extracted GTIN may correspond to a product that is in development but has not been registered with the content platform 216.

[0131] Accordingly, in some implementations, the application execution module 214 can inject simulated (sometimes referred to as mock or artificial) return states, and/or other simulated/artificial objects, into the payloads 720. These simulated states/objects can be default states generally applied by the application execution module 214, and/or can include simulated states/objects input by a user of the parent application 202.

Generated payloads 720 can include, or can be based on, these simulated states/objects, e.g., as placeholder content. As such, operation of the system 200 need not be inhibited by user entry of tokens without corresponding backend states, objects, or definitions. This process can reduce or avoid dependencies on resolved backend objects to permit direct previewing of experiences based on raw, unresolvable structured identifiers 240, such as raw, unresolvable GS1 DL URLs. Further, this “speculative previewing” process can eliminate a need for state/object instantiation This eliminates the need for object instantiation prior to design, streamlining workflows and decoupling creative design from data registration bottlenecks.

[0132] FIG. 8 illustrates an example of a user interface 800 for entry of scenario parameters. The user interface 800 can be included in, or presented by, the scenario configuration tools 206 provided by the parent application 202.

[0133] The user interface 800 includes entry fields 802, 804, 806 into which a user can input one or more tokens to be included in the structured identifier 240, such as batch number, serial number, and/or GTIN. For each token type, the user interface 800 includes interface elements 808, 810, 812 with which a user can input whether the token is “registered,” e.g., whether a state and/or object corresponding to the entered token is available for provision by the content platform 216. In this example, the batch number is registered, but the serial number and GTIN are not. Accordingly, interface elements 814, 816 are included in the user interface 800, and a user can use these interface elements 814, 816 to input simulated (mock) states corresponding to the batch number and GTIN. For example, the interface elements 814, 816 can include dropdown menus usable to select a simulated state. The application execution module 214 will use the input states when generating a payload 720 and rendering pages, e.g., as if the simulated state had originated from a real interaction with a content platform 216. For example, a structured identifier 240 generated based on the user interface 800 shown in FIG. 8 will result in presentation of a page 232 that would be presented to a user if the user scanned a QR code on a product with an expiration date of 05/07/2026, where the product was approved by a compliance regulator.

[0134] Because the batch number “ABC 123” is “registered” - for example, content corresponding to the batch number “ABC 123” is available from the content platform 216 - the user need not (though may) input a simulated state for the batch number. Rather, the structured identifier 240 generated based on the user interface 800 shown in FIG. 8 will result in the application execution module 214 retrieving, from the content platform 216, content corresponding to the batch number “ABC 123”. A payload 720 including or based on the content will be provided to the rendering engine 722 so that the content will be included in the page 232.

[0135] Accordingly, in some implementations, designers can perform design-time testing of conditional UI states based on downstream metadata retrieval, without requiring live backend integration. Designers can visualize and test how different URL compositions result in different content renderings, previewing the interplay between design in the parent application 202, the final URL (structured identifier 240), and the live output rendered as the page 232.

[0136] Rendering pages (712) can include binding tokens 710 (e.g., in a form {{GTIN}}, {{batch}}) to a corresponding page template of the child application 204. When simulated states/objects are used, this can be performed without querying an object store, such that full rendering behavior is simulated without requiring resolved product definitions.

[0137] Injection (718) of simulated states can include generated suitably-formatted data as a payload 720 into a rendering pipeline of the rendering engine 722. For example, the application execution module 214 can generate a mock application programming interface (API) response, such as JSON-formatted data or XML-formatted data, into the rendering pipeline. For example, to simulate a recall state, the following data (as a payload 720) can be injected into the rendering pipeline: {

“status”: “recalled”,

“recall_reason”: “Batch contamination detected”,

“recall_date”: “2025-03-15” [0138] Conditional rendering logic of the rendering engine 722 can then render the page 232 so as to include content corresponding to the simulated state. The rendering engine 722 can process the injected data as if the data were provided from a real-time third-party service. Rendering of content can be triggered by the presence of the injected data. For example, the page 232 can include a warning overlay reflective of the simulated state, and/or include text or other media indicative of the simulated state. As another example, the page 232 can exhibit restricted access as if a real API call to a content platform 216 had occurred. For example, a simulated state can cause an effect of device location on page content to be simulated, reflecting dynamically-simulated geolocationbased dynamic restrictions/alterations of access to content. As another example, a simulated state can cause an effect of a user’s access level to be simulated. Therefore, error handling user experience and compliance-driven paths can be validated without dependence on live services providing responses as the content platform 216. This is useful in many situations, and can be particularly useful for regulated industries like pharmaceuticals and consumer electronics, where auditability of third-party checks can be advantageous or required.

[0139] For example, a simulated “recalled product” response may trigger a warning overlay in the page 232, or content suppression in the page 232. Based on user configuration of multiple test states (e.g., expired, unregistered, counterfeit) and error conditions (e.g., HTTP 403, timeout). This allows the designer to test both positive and negative UI states associated with third-party lookups, thereby improving robustness of experience testing without backend dependency.

[0140] As noted above, in some implementations, an error condition can be simulated. For example, the context data 130 can indicate the presence of an error condition such as a forbidden access error (e.g., HTTP 403 response), a timeout, or a malformed data response indicative of an incorrectly-formatted structured identifier 240. When such an indication is included in the context data 130 provided to the child application 204, page rendering (712) can include injecting, into the rendering pipeline of the rendering engine 722, a payload 720 that causes the page 232 to include content reflecting the error condition, as an injection (718) of a simulated state. For example, the page 232 can include content that a user would experience if their real-world access were associated with the error condition, such as an error message. This allows testing of fallback user interface elements and error-handling workflows without requiring backend instability or mock infrastructure.

[0141] As such, based on injection (718) of simulated states into the rendering pipeline, the system 200 can simulate interactions that would otherwise depend on external systems or live data sources (e.g., as content platform 216).

[0142] FIG. 9 illustrates an example of a process 900 that can be performed as part of page rendering (712). As shown in FIG. 9, scenario parameters 116 provided to the child application 204 can include, for example, a structured identifier 240, simulated state data 902 (e.g., as input using a user interface like user interface 800), and/or other scenario parameters 116, such as context data 130 like date, location, language, error state(s), and/or the like. The simulated state data 902 can include indications of one or more states that a user would like to simulate for presentation of the page 232, e.g., “authentic” or “unverified” for an authenticity state, an expiration date, “expired,” or “unexpired” for an expiration state, etc. Tokens 710 can be extracted from the structured identifier 240, e g., as described in reference to element 702 of FIG. 7.

[0143] Extracted tokens 710 and/or other data of scenario parameters 116 (e.g., context data) are used to access (910) a content platform 216 and retrieve content 912 corresponding to the extracted tokens 710 and/or other data, as described in reference to third-party content and access to the content platform 216 in connection with FIG. 7. A payload 720 is generated based on the content 912 (914), and the payload 720 is provided to the rendering engine 722 (916). The rendering engine 722 can use the payload 720 to generate a page 232 that includes or reflects the content 912.

[0144] The simulated state data 902 is used to generate a simulated payload 908 (904), as described in reference to simulated states in connection with FIG. 7. The simulated payload 908 is an example of a payload 720. The simulated payload 908 can include content corresponding to the simulated state data 902, e.g., content corresponding to a simulated state indicated by the simulated state data, as described in reference to FIG. 7. The simulated payload 908 can include a synthetic payload having a JSON, XML, or other format. In some implementations, the simulated payload 908 includes content input by a user in the parent application 202. For example, the content configuration interface 302 can provide controls usable to input content (text, media, and the like) that will be rendered in a page 232 based on the simulated state data 902.

[0145] The simulated payload 908 is injected into a rendering pipeline of the rendering engine 722 (906). The rendering engine 722 can use the payload 908 to generate a page 232 that includes or reflects the content corresponding to the simulated state data 902 (906).

[0146] Referring again to FIG. 8, the user interface 800 further includes an interface element 818 that, when selected, provides additional tools by which a user can input other scenario parameters 116. For example, interface element 818, when selected, can open the scenario configuration interface 306 shown for the user interface 300.

[0147] The user interface 800 also includes an interface element 820 that, when selected, triggers provision of scenario parameters 116 to the child application 204, e.g., including a structured identifier 240 (such as a URL) generated in accordance with the inputs in the user interface 800. For example, the parent application 202 can generate the structured identifier 240 based on a schema selected using interface element 822. The parent application 202 can store a library of URL generation routines, templates, and/or the like, for multiple schema and can apply the routine corresponding to the selected schema to generate a URL as the structured identifier 240. For example, the parent application 202 can generate the URL with a format corresponding to the selected schema.

[0148] Accordingly, the system 200 can provide protocol-agnostic previewing. Each schema (e.g., GS1 DL or DPP) can have a corresponding schema template. The parent application 202 (e.g., the scenario configuration tools 206) can access the template for a selected schema and apply the template to generate a structured identifier 240, as described in reference to FIG. 8. This modularity allows the same simulation engine to handle heterogeneous input formats without custom rendering pipelines.

[0149] In some implementations, user interface elements are selectively displayed based on a selected schema. For example, selecting “GS1 DL” as the schema may expose entry fields for GTIN, batch, and serial. Selecting “DPP” may expose entry fields such as lifecycle phase, sustainability score, and recyclability class. Different user interface elements can be displayed for different schema.

[0150] The use of schema-based parsing and payload assembly allows the system 200 to support interaction previewing across heterogeneous identifier systems without requiring unique object resolution infrastructure for each.

[0151] Various methods for scenario configuration are within the scope of this disclosure. In some implementations, a user interface of the parent application 202, such as the user interface 800, includes an interface element 824 usable to directly enter a full URL string. The URL string is then sent by the parent application 202 to the child application 204 as a structured identifier 240.

[0152] In some implementations, the changes are reflected in the page presentation interface 304 in real-time. For example, as a user reconfigures the scenario parameters 116 and/or the corresponding content configuration data 250, the presented page 232 of the child application can reflect the reconfigured scenario parameters 160 and/or the reconfigured content configuration data 250, e.g., automatically as a user makes the changes, and/or in response to selection of an interface element such as an “update” button. For example, when a user edits text in the content configuration interface 302, the edited text can be displayed in the page presentation interface 304 (as an updated page of the child application 204) in real-time and/or immediately in response to a user instruction to update the interface 304. As another example, when a user changes the scenario in the scenario configuration interface 306 (e.g., changes a selected location or operating system), content corresponding to the changed scenario can be displayed in the page presentation interface 304 (as an updated page of the child application 204) in realtime and/or immediately in response to a user instruction to update the interface 304.

[0153] In some implementations, the applications 202, 204 can operate based on a distinction between (i) real-time updates that are provided without a page refresh, and (ii) page refresh/loading operations. For example, when a user configures a scenario and corresponding content and selects the interface element 308 of the user interface 300, a structured identifier 240 can be generated and a page 232 can be generated based on the structured identifier 240, as discussed above. The page 232 can be presented in the page presentation interface 304, e g., using a URL as discussed above. When the user subsequently makes changes to the page 232 (including, in some cases, interacting with the page 232, as discussed below), messages such as postMessages can be provided by the emulation client 212 to the emulation host 208 to implement the changes in the already-loaded page, without requiring a refresh of the page (e.g., re-accessing the URL of the page) or re-loading of the page for each tested scenario and/or content configuration. This can provide an improved user experience and more efficient page development.

[0154] For example, in some implementations, real-time updates without a refresh can be performed using react/redux scripting/logic. In some implementations, the parent application 202 and/or the child application 204 includes a runtime that converts user configurations done in the UI of the parent application into suitable state management logic that is applied to the child application. In some implementations, performing the real-time updates includes handling conflicts and throttling state change messages going to and from the emulation client and emulation host. For example, hooks provided to the child application 204 can allow the child application to monitor for changes, obtain the current states of values, and trigger changes

[0155] Some implementations of the processes and systems described herein can enable not only page configuration but also page interaction. For example, as shown in the cropped interface of FIG. 4A, a presented page of a child application includes selectable elements “Description” and “Specifications.” In the state shown in FIG. 4A, “Description” has been selected, and a product description is displayed in the page. This state of the page can be stored/indicated using a local variable, e.g., local variable “page_state” having a value of “1” as shown in FIG. 4A. A user of the parent application 202 can click or otherwise select “Specifications” as presented in an interface of the parent application 202, e.g., the page presentation interface 304. The selection is detected by the child application, which dynamically updates the page in real time to display product specifications, as shown in FIG. 4B. Further, a value of the local variable “page_state” is altered to “2,” corresponding to the page state that includes the displayed product specifications. The updates page state information and variable information can be communicated from the emulation client 212 to the emulation host 208 for presentation in the interface of the parent application, e.g., in an ifirame. [0156] Messages between the parent application 202 and the child application 204 are not limited to postMessages. For example, other forms of communication between the parent and child applications 202, 204 are within the scope of this disclosure, e.g., forms of communication compatible with client components of the applications 202, 204 executing on different devices. For example, in some implementations, the client component of the parent application 202 executes on a first computing device (e.g., a laptop or desktop), and the client component of the child application 204 executes on a second computing device (e.g., a mobile device such as a smartphone). In some implementations, a server is used as an intermediary to rely information between the parent application 202 and the child application 204.

[0157] In some implementations, changes made to local variables in the parent application 202 can be reflected in the child application 204. For example, in some implementations, from the state shown in FIG. 4B, a user can use the parent application 202 to manually change the value of “page_state” to “1.” In response (e.g., based on a message sent from the parent application 202 to the child application 204), the page 232 of the child application 204 (as rendered by the child application 204 and presented in the parent application 202) can change in real time to the state shown in FIG. 4A. Local variables can be variables that would be stored on a device (e.g., mobile device) accessing the deployed child application 204, e.g., via a web browser after scanning an object. The values of the local variables (e.g., user preferences) can be tracked and stored by the parent application.

[0158] In the example of FIG. 4A, the presented user interface 400 of the parent application includes a state visualization interface 402, which can be presented instead of and/or alongside one or more of the interfaces 302, 304, 306 discussed with respect to the user interface 300. The state visualization interface 402 can present, for example, information indicating internal page states of the child application (e.g., the variable “page_state”), information about lifecycle events, and/or errors.

[0159] The operations shown in FIGS. 4A-4B illustrates that users can interact with elements of the page 232 of the child application 204 presented in the page presentation interface 304 as if interacting directly with the child application 204, e.g., clicking and otherwise interacting with page elements, navigating to other pages of the child application 204 by clicking links, etc., and causing the child application 204 to respond to the interactions. Accordingly, for example, when the child application 204 is a website or web application, a user can interact with the website or web application as if the user were directly accessing the website or web application in a specific scenario (e.g., at a specific time, using specified hardware, etc.). In some implementations, the child application 204 is not being simulated, modeled, or otherwise mocked-up - rather, the child application 204 is executing separately from the parent application 202, and pages of the child application 204 are presented in the parent application 202, permitting an experience of the true look and behavior of pages of the child application 204.

[0160] As another example of state/variable changing and updating, a variable “registered” (in this example, an object variable) can be “true” when an object corresponding to a page of the child application has been registered (e g., with a warranty platform), and can be “false” if the object is not registered. For example, scanning the object (e.g., as shown in FIG. 1) can result in automatic registration of the object. When “registered” is “false,” the page can provide a form by which a user can input data (e.g., name, email address, etc.) to perform registration. A user of the parent application can interact with this form in the parent application (e.g., by clicking/typing in an iframe) and submit the form to emulate registration. In response to the form being submitted, “registered” can be set to “true.” The real time-updating value of “registered” can be displayed in the state visualization interface 402.

[0161] In some implementations, the parent application 202 can be set (e.g., by a suitable interface element) to an “Inspection Mode.” In Inspection Mode, selection (e.g., clicking) of an element of the child application 204 in the page presentation interface 304 causes configuration information/options corresponding to the element to be presented in the content configuration interface 302. For example, referring to the user interface 300, when a user clicks the text “The below text changes...” when in Inspection Mode, the content configuration interface 302 can present an HTML entry interface in which the user can modify that text, apply various formatting options, etc. For example, in Inspection Mode, selection of an element causes the parent application 202 to open a portion of the page’s build configuration at which the element is defined. This allows a user who observes, for example, a visual defect during testing to quickly find and remedy the defect. Changes made in Inspection Mode can correspond to changes made to content configuration data 250, and an indication of the change can be provided by the parent application 202 to the child application 204 to cause updated rendering based on the changes. In some implementations, the parent application 202 is configured to execute Inspection Mode by event handlers of the presented page of the child application 204. In some implementations, when in Inspection Mode, the child application visualization module 210 causes highlighting of hovered-over elements in the presented page.

[0162] In some implementations, the parent application 202 is configured to monitor lifecycle events such as a connection (e.g., initial connection) to the emulation client 212, navigation to different pages, and error messages. For example, when an error is triggered in the child application 204 (e.g., based on a user’s interaction with the child application in the page presentation interface 304, based on an invalid state change or invalid behavior, etc ), the error can be reported back to the parent application 202 (e.g., can be indicated in data sent from the emulation client 212 to the emulation host 208), and the error can be presented to a user, e.g., in the state visualization interface 402. The error can include, for example, an error in execution of script/code of the child application 204, e.g., a JavaScript error.

[0163] A monitoring module of the parent application 202 can be configured to perform the monitoring and perform operations in response to the monitoring.

[0164] In some implementations, the parent application 202 is configured to emulate access to pages both with an interaction payload (which provides scenario parameters, as discussed with respect to FIG. 1) and without the interaction payload. For example, in some cases, the interaction payload is provided when a user scans an object; if a user accesses a child application without scanning (e.g., by navigating to a webpage of the application in a browser), the interaction payload and, accordingly, a scenario for the access, may not be available. By selection of an appropriate interface element of the scenario configuration interface 306 (e.g., “without scan” as shown in the user interface 300), pages can be presented without corresponding to any particular scenario or corresponding to a default scenario. For example, users can use the parent application 202 configure (e.g., as a default configuration) how pages of the child application 204 should be presented in the absence of scenario parameters. [0165] Referring again to FIG. 2, in some implementations, the parent application 202 includes a recommendation module 220. The recommendation module 220 can suggest content for inclusion in a presented page 232 based on detected patterns. Recommendations can include, for example: a prompt to add an expiration alert; a warning for incomplete protocol coverage; and/or a recommendation for a region-specific module. The recommendation can be provided as user interface elements in the scenario configuration tools 206, such as contextual overlays, prompts, iconography, tooltips, and/or regulatory callouts. For example, the recommendations can be presented as user interface elements in the content configuration interface 302.

[0166] For example, the recommendation module 220 can determine an input GTIN that maps to a food category. Based on this determination, the recommendation module 220 can display interface element(s) suggesting the inclusion of allergen disclosures and/or nutritional information in a presented page 232 corresponding to the GTIN. As another example, the recommendation module 220 can determine that an input scenario reflects a product nearing expiration. Based on this determination, the recommendation module 220 can recommend inclusion of a message indicating urgency in using the product. As another example, if context data, GTIN, or the like indicates that a product is in a particular region, the recommendation module 220 can recommend the inclusion of regulatory icon(s) corresponding to that region. For example, for the European Union (EU) region, the recommendation module 220 can recommend inclusion of a European Conformity (CE) mark, a Green dot, or the like.

[0167] Referring to FIG. 10, processing 1000 by the parent application 202 can include providing the scenario parameters 116 as input to the recommendation module 220. The input scenario parameters 116 can include, for example, tokens 710, context data 130, parsed data of structured identifiers 240, etc. In some implementations, content of parsed structured identifiers, such as tokens 710, is provided by the child application 204 to the parent application 202 for use an input to recommendation by the recommendation module 220. For example, recommendations can be based on GTIN and/or another extracted token type. Recommendations can be based on detected GS1 or DPP values. The recommendation module 220 can execute rules-based processing 1002 and/or one or more machine learning models 1004 using the scenario parameters 116 as input. The rules-based processing 1002 and/or machine learning models 1004 can output a recommendation 1006 for content for inclusion in page 232. The recommendation can be presented (1008) in a user interface of the parent application 202, e.g., by the scenario configuration tools 206.

[0168] The machine learning models 1004 can be trained based on, for example, historical designer behavior, historical content rules, product classes, industry-specific templates, and/or the like.

[0169] The parent application 202 can present user interface elements by which a user can accept, modify, or dismiss recommendations. In some cases, a natural language explanation is provided alongside each suggestion. For example, the user interface elements can include a prompt to add allergen labeling, and text stating “This product’s category requires allergen labeling in the EU.”

[0170] The recommendations 1006 can include, for example, content positioning/placement recommendations, recommendations for iconography, recommendations for regulatory callouts, recommendations for labeling style, etc. Designers may accept, modify, or reject these recommendations within a user interface of the parent application 202 (e.g., a preview canvas). These recommendations may be presented as optional design-time interventions which the designer may accept, reject or modify. Additionally, natural language interfaces may be used to explain how particular metadata attributes are influencing the preview, or to accept designer input in a conversational format.

[0171] Execution by the recommendation module 220 can include execution of an overlay engine configured to generate contextual suggestions, warnings, and the like based on rules-based processing 1002 and/or machine learning models 1004. For example, if a GTIN (e.g., as input by a user and/or as extracted based on parsing by the child application 204) corresponds to a known product category requiring regulatory content, such as medical devices or food items, the overlay may present inline UI prompts recommending inclusion of mandatory labeling or regional disclosures. These overlays may be rendered using a UI framework that layers guidance components on top of scenario configuration tools 206 and/or other user interface tools of the parent application 202, triggered, for example, by metadata-type detection and associated with content zone anchors.

[0172] Accordingly, real-time recommendations can be provided based on structured metadata analysis. These recommendations — such as regulatory disclosure prompts or lifecycle phase adaptations — are grounded in rule-based and/or learned models that process protocol -derived inputs. This yields an enhanced human-machine interface where designers are guided toward compliant and semantically relevant configurations, reducing the cognitive load and risk of error in metadata-dependent content creation.

[0173] In some implementations, the scenario configuration tools 206 include a URL handling module 1102, shown in FIG. 11. The URL handling module 1102 can present a corresponding user interface 1200, shown in FIG. 12. The URL handling module 1102 can be configured to generate “preview URLs” that simulate or match URLs that would be used for a page or experience. That is, a first URL that acts as a structured identifier 240 may differ from a corresponding second URL that is actually shown to an end user upon scanning of the first URL, interaction with the first URL, and the like. It may be useful for designers to view and interact with the second (“preview”) URL to better understand the user experience, to see how changes to the preview URL correspond to changes in presented pages, and the like.

[0174] As shown in FIG. 11, the URL handling module 1102 can receive a structured identifier 240 having the form of a URL. For example, the URL can be a URL generated using the user interface 800 or a similar interface. In some implementations, the URL is directly input into a URL entry field 1202.

[0175] A URL conversion module (or layer) 1104 of the URL handling module 1102 converts the input URL into a preview URL 1106, e.g., in response to selection of interface element 1204. The preview URL 1106 is presented in a user interface (1108), e.g., in user interface element 1206 of FIG. 12.

[0176] The URL conversion module 1104 simulates redirect behavior to generate the preview URL 1106. For example, the URL conversion module 1104 can apply a transformation engine to map the input URL to the preview URL 1106 based on resolution rules, configuration logic, etc. For example, in the case shown in FIG. 12, an input URL “https://example.org/gtin/0123456789012/batch/ABC123,” which is a GS1 DL URL, is converted into a preview URL “https://preview.brand.com/product/0123456789012/batch/ABC123”. The transformation engine can simulate resolution behavior performed by a URL resolver, redirector, or product cloud system, thereby providing designers with insight into the full URL lifecycle and a preview of its outcome. In some implementations, the URL conversion module 1104 is configured to perform conversion by extracting token(s) 710 from the input URL (e.g., GTIN, serial number, batch number, and/or any other token type described herein) and automatically populating a preview URL template, such as “such as /product/ { { GTIN } } /b at ch/ { { b atch } } ” .

[0177] In real-world use, a person scanning a QR code representing the input URL would be redirected to the preview URL. Therefore, users of the parent application 202 can preview what a live experience URL would look like, given a certain structured input. This provides transparency and testability during design and enables designers to verify URL composition logic, share previews for stakeholder review, and understand how changes to metadata affect routing and path resolution.

[0178] The preview URL can include tokens 710 (e.g., “batch/ABC123”) to improve transparency, debugging fidelity, and test coverage for routing logic.

[0179] As shown in FIG. 12, a user interface element 1208 presented alongside the preview URL can be selected to cause presentation of a page generated based on the preview URL. For example, in response to selection of user interface element 1208, the preview URL and/or token(s) thereof can be sent (1112) to the child application 204 for processing and page generation as described in reference to FIGS. 2, 7, and 9. For example, in reference to FIG. 12, “https://preview.brand.com/product/0123456789012/batch/ABC123” can be sent to the child application 204, and/or parsed/labeled token information can be sent to the child application 204, such as “batch=ABC123,” “product=0123456789012,” etc. A corresponding page can be rendered and presented based on the provided data, as discussed in reference to FIGS. 2, 7, and 9.

[0180] In some implementations, a user of the parent application 202 can edit (1110) the presented preview URL 1106, e.g., directly in the user interface. For example, in the user interface 1200, a user can edit (1110) text in-line in user interface element 1206 to edit the preview URL. Page rendering can be updated based on the updated preview URL, providing real-time feedback. For example, a user can directly edit a serial number in the preview URL to cause updated rendering based on the edited serial number.

[0181] In some implementations, the URL handling module 1102 is configured to validate preview URLs (1114) for compliance with one or more requirements. The URL handling module 1102 can provide an indication 1210 as to whether the preview URL 1106 conforms to supported identifier format(s) and/or whether rendering of a page 232 can be performed successfully based on the preview URL 1106.

[0182] In some implementations, the URL handling module 1102 presents one or more sharing tools. For example, as shown in FIG. 12, user interface elements 1212, 1214 can be selected to share the preview URL or copy the preview URL, respectively. [0183] In some implementations, live updates are propagated between multiple portions of the system 200. For example, as shown in FIG. 13, synchronized mappings can be maintained between (i) user input of scenario parameters 116, (ii) a preview URL 1106, and (iii) rendered pages. Modification of a scenario parameter 116 (e.g., modification of a token 710 in the user interface 800) can cause display of an updated preview URL 1106 that incorporates the modified token. Further, modification of the scenario parameter 116 can cause rendering of an updated page based on the updated scenario parameter 116. Conversely, modification of the preview URL 1106 (e.g., direct URL modification in the user interface 1200) that includes modification of a scenario parameter 116 can cause modification of scenario parameters 116 in another user interface, e.g., the user interface 800. Further, modification of the preview URL 1106 can cause rendering of an updated page based on updated scenario param eter(s) 116 in the updated preview URL 1106, e.g., as described in reference to FIG. 11.

[0184] The foregoing configurations and processes can be applied, for example, to DPP lifecycle phase simulation. The DPP standard defines various lifecycle stages, including “Initial Sale,” “In Use,” and “End of Life.” It can be advantageous for pages corresponding to a product to reflect the product’s lifecycle, e.g., in content presented in the pages. For example, in the Initial Sale phase, promotional and/or onboarding modules can be presented. In the In Use phase, maintenance, warranty, and/or safety information can be presented. In the End of Life phase, sustainability disclosures, disposal guidance, and the like, can be presented.

[0185] A user can input, in a user interface of the parent application 202, a lifecycle stage. The parent application 202 can generated a DPP-conforming structured identifier 240 that includes the input lifecycle stage. The child application 204 can receive the structured identifier 240, parse the structured identifier 240 to obtain the lifecycle stage, and render a page that includes content corresponding to the lifecycle stage. In some implementations, the content is retrieved by the child application 204 from a content platform 216, based on the lifecycle stage. In some implementations, the content is input by a user in the parent application 202. The rendered page is presented in the parent application 202. For example, the rendered page in the parent application 202 may display different regulatory icons, instructional content, or access permissions based on whether the product is in its initial sale phase or end-of-life recycling phase, as reflected by the input lifecycle stage. Accordingly, page rendering is modified to reflect scenario- driven behaviors independently from any live object backend.

[0186] FIG. 5 illustrates an example of a process flow 500 according to which applications described herein can operate. In the process flow 500, a user creates a child application (e.g., child application 204) using a parent application (e.g., parent application 202) (502). For example, the user can use tools presented in the content configuration interface 302 to create and modify content to be presented in pages of, or rendered by, the child application. Operation 502 is optional, and the child application need not be created by the parent application.

[0187] A page of the child application is rendered and is presented in an iframe of the parent application (504). The page rendering can be performed by the child application executing independently from the parent application. For example, page rendering can be performed based on scenario parameters 116 and/or content configuration data 250 provided by the parent application to the child application, as discussed in reference to FIGS. 2, 7, and 9.

[0188] The user configures a scenario in the parent application, and applies the scenario (506). For example, the user can set one or more scenario parameters 116 using the interfaces like interfaces 306, 800, and/or 1200, and apply the scenario parameters 116 (e ., by selecting a user interface element 308, 820, or 1208). Applying the scenario parameters 116 can include generating a structured identifier 240 providing (e.g., including) at least some of the scenario parameters 116, such as tokens 710, and sending the structured identifier to the child application 204.

[0189] An emulation host (e.g., emulation host 208) sends updates to the child application in the iframe via a postMessage (508). For example, the updates can indicate the configured scenario, and the postMessage can be sent to an emulation client (e.g., emulation client 212). In some implementations, sending the updates includes sending the scenario parameters 116, such as a structured identifier 240, to the child application 204. [0190] The emulation client dynamically updates the page presented in the iframe in real-time to reflect the configured scenario (510). For example, the application execution module 214, executing independently from the parent application 202, can generate the updated page, and the updated page can be provided in the iframe via the emulation client 212.

[0191] A user manipulates a page state of the page in the iframe or induces an error; the manipulation or the error corresponds to a changed state of the child application (512). For example, the user can interact with interface elements in the iframe to alter the page state, or can enter data in the iframe that causes an error in the child application. [0192] The emulation client communicates with the emulation host to cause the changed state of the child application to be reflected in the parent application (514). For example, emulation client can send a postMessage to the emulation host, and data representative of the changed state can be presented in an interface of the parent application (e.g., in the state visualization interface 402).

[0193] FIG. 6 illustrates an example of a process 600 that can be performed according to some implementation described herein. The process 600 can be performed by and/or using the parent application 202 and the child application 204. The process 600 can be performed by one or more computer devices and/or computer systems.

[0194] The process 600 includes independently executing a first application (e.g., a parent application) and a second application (e.g., a child application) (602). For example, the applications can execute in different domains, on separate hardware, in separate computer systems, etc. The applications can execute isolated from one another. [0195] A page of the second application is presented in the first application (604). For example, the page can be presented in a distinct page of the first application, in an iframe of the first application, etc.

[0196] The first application presents at least one tool usable to set a scenario for the second application (606). For example, the at least one tool can be a tool of the scenario configuration interface 306. The at least one tool can be used to set scenario parameters 116, such as a structured identifier 240, tokens 710, context data 130, and/or the like.

[0197] The first application obtains the scenario based on user control of the at least one tool (608). For example, the user can interact with the at least one tool to set a location, a time, a verification state, a language, a batch number, a structured identifier URL, a serial number, a product number, and/or the like.

[0198] The page of the second application is altered based on the scenario by executing the second application, to obtain an altered page (610). For example, the independent execution of the second application can generate and render the altered page using data received by an emulation client of the second application. For example, as opposed to simulated execution of the second application, mocked-up generation of the page, etc., the operation 610 can provide an authentic, fully-realized version of the altered page while maintaining inter-application security.

[0199] The altered page is presented in the first application (612), e.g., in the iframe. [0200] FIG. 14 illustrates an example of a process 1400 that can be performed according to some implementation described herein. The process 1400 can be performed by and/or using the parent application 202 and the child application 204. The process 1400 can be performed by one or more computer devices and/or computer systems.

[0201] As shown in FIG. 14, the process 1400 includes receiving, at a first application, user input indicative of a structured identifier (1402). For example, a user can directly input the structured identifier, or a user can input scenario parameters (e.g., one or more tokens 710) based on which the first application generates the structured identifier, e.g., based on a user-selected schema. The structured identifier can be, but is not limited to, a URL conforming to a schema such as GS1 DL, DPP, or any other suitable schema. The first application can be the parent application 202, and the second application can be the child application 204. [0202] The process 1400 includes providing the structured identifier from the first application to a second application (1404), for example, as described in reference to FIG. 2. In some implementation, both the structured identifier and context data are provided from the first application to the second application, permitting page rendering based on the context data.

[0203] The process 1400 includes parsing, by the second application, the structured identifier to obtain at least one token (1406). For example, the token can be a serial number, a product number, a batch number, or another token type. Parsing can be performed as described in reference to FIG. 7, e.g., based on a known format of a schema of the structured identifier.

[0204] The process 1400 includes rendering, by the second application, a page based on the at least one token (1408). For example, one or more payloads can be generated by the second application and used by a rendering engine of the second application to generate the page. The second application can access a content platform (e.g., a third- party platform) to determine a state corresponding to a token, and can render the page to include content corresponding to the state. The second application can obtain a mock state corresponding to a token, the mock state provided by the first application (e.g., without having to access a live backend that provides the mock state), and can render the page to include content corresponding to the state.

[0205] The process 1400 includes presenting the rendered page in the first application (1410). For example, the rendered page can be presented in an iframe of the first application or otherwise presented by the child application visualization module 210.

[0206] Various modifications and extensions of the foregoing description can be applied in various implementations. In some implementations, the parent application 202 can be configured to save scenarios for future use. In some implementations, the parent application 202 can be configured to recommend scenarios based on content of the child application 204, e.g., by applying a machine learning model to predict likely access scenarios of page of the child application 204 based on content of the child application 204 (e.g., locations from which the child application 204 is likely to be accessed). In some implementations, the parent application 202 can be configured to recommend content to be included in the child application 204 based on provided scenarios, e g., using a machine learning model. In some implementations, the parent application 202 can be configured to import scenario parameters from third-party systems, allowing for more seamless workflows and broader testing capabilities. In some implementations, the parent application 202 can be configured to present historical page events triggered by user behavior, providing more insight into the page’s implementation of analytics and reporting. In some implementations, pages of the child application 204, described in the foregoing as being presented within the parent application 202, can be accessible in other applications and other formats.

[0207] Some features described herein, such as the device 100, page server 108, content platform 216, applications 202, 204, and elements thereof (e.g., tools, modules, etc.) may be implemented in digital and/or analog electronic circuitry or in computer hardware, firmware, software, or in combinations of them. Some features may be implemented in a computer program product tangibly embodied in an information carrier, e.g., in a machine-readable storage device, for execution by a programmable processor. Method steps may be performed by a programmable processor executing a program of instructions to perform functions of the described implementations by operating on input data and generating output, by discrete circuitry performing analog and/or digital circuit operations, or by a combination thereof.

[0208] Some described features may be implemented advantageously in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. A computer program is a set of instructions that may be used, directly or indirectly, in a computer to perform a certain activity or bring about a certain result. A computer program may be written in any form of programming language (e.g., Objective- C, Java, Python, JavaScript, Swift), including compiled or interpreted languages, and it may be deployed in any form, including as a stand-alone program or as a module, component, subroutine, or other unit suitable for use in a computing environment.

[0209] Suitable processors for the execution of a program of instructions include, by way of example, both general and special purpose microprocessors, and the sole processor or one of multiple processors or cores, of any kind of computer. Generally, a processor will receive instructions and data from a read-only memory or a random-access memory or both. The essential elements of a computer are a processor for executing instructions and one or more memories for storing instructions and data. Generally, a computer may communicate with mass storage devices for storing data files. These mass storage devices may include magnetic disks, such as internal hard disks and removable disks; magneto-optical disks; and optical disks. Storage devices suitable for tangibly embodying computer program instructions and data include all forms of non-volatile memory, including by way of example, semiconductor memory devices, such as EPROM, EEPROM, and flash memory devices; magnetic disks such as internal hard disks and removable disks; magneto-optical disks; and CD-ROM and DVD-ROM disks. The processor and the memory may be supplemented by, or incorporated in, ASICs (application-specific integrated circuits). To provide for interaction with a user the features may be implemented on a computer having a display device such as a CRT (cathode ray tube), LED (light emitting diode) or LCD (liquid crystal display) display or monitor for displaying information to the author, a keyboard and a pointing device, such as a mouse or a trackball by which the author may provide input to the computer.

[0210] For example, FIG. 15 is a block diagram illustrating a computer system 1500. In some implementations, one or more computer systems 1500 can be configured to execute the parent application 202, the child application 204, or both. In some implementations, separate computer systems 1500 are configured to execute the parent application 202 and the child application 204.

[0211] The computer system 1500 can be configured to perform operations described herein as being performed by either or both of the parent application 202, the child application 204, for example, processes 500, 600, and/or 1400, and/or the processing shown or described in reference to in FIGS. 2, 3A to 3B, 4A to 4B, and/or 7-13.

[0212] The computer system 1500 may refer to any system including a general purpose or special purpose computing system. For example, the computer system 1500 may include a personal computer, a server computer, a cloud computing system, a laptop computer, a home appliance, and the like. As shown in FIG. 15, the computer system 1500 may include at least one processor 1510, a memory 1520, a storage system 1530, a network adapter 1540, an input/output (I/O) interface 1550, and a display 1560. [0213] The at least one processor 1510 may execute a program module including computer system executable instructions. The program module may include routines, programs, objects, components, logic, data structures, and the like, performing a specific task or implementing a specific abstract data type. The memory 1520 may include a computer system readable, non-transitory medium in the form of a volatile memory such as a random access memory (RAM). The at least one processor 1510 may access the memory 1520 and execute instructions loaded in the memory 1520. The storage system 1530 may non-volatilely store information and may include at least one program product including a program module configured to perform the operations described herein for any of the parent application 202 or the child application 204.

[0214] The network adapter 1540 may provide a connection to a local area network (LAN), a wide area network (WAN), and/or a public network (e.g., the Internet), etc. The I/O interface 1550 may provide a communication channel with a peripheral device such as a keyboard, a pointing device, and an audio system. The display 1560 may output various pieces of information so that the user may check the information.

[0215] In some implementations, operations described above with respect to FIGS. 2 to 14 are implemented as or using a computer program product. The computer program product may include a non-transitory computer-readable medium (or storage medium) including computer-readable program instructions for causing the at least one processor 1510 to perform the disclosed operations. Computer readable instructions may be, but are not limited to, assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state setup data, or source code or object code written in at least one programming language.

[0216] The computer-readable medium may be any type of medium capable of non- transitorily holding and storing instructions executed by the at least one processor 1510 or any instruction executable device. The computer-readable medium may be an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any combination thereof, but is not limited thereto. For example, the computer readable medium may be a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an electrically erasable read only memory (EEPROM), a flash memory, a static random access memory (SRAM), a compact disc (CD), a digital versatile disc (DVD), a memory stick, a floppy disk, a mechanically encoded device such as a punch card, or any combination thereof.

[0217] The foregoing description provides methods. For example, the foregoing description provides the following methods:

[0218] Method 1 : A computer-implemented method that includes: presenting a page of a second application in a first application; presenting, by the first application, at least one tool usable to set scenario parameters for the second application; obtaining, at the first application, the scenario parameters based on user control of the at least one tool; altering the page of the second application based on the scenario parameters by executing the second application independently from the first application, to obtain an altered page; and presenting the altered page in the first application.

[0219] Method 2: Method 1, in which the scenario parameters include at least one of: a hardware type or software type of a device accessing the second application; a location of the device accessing the second application; a time of accessing the second application; or a language in which to present the second application.

[0220] Method 3 : Any of the foregoing Methods, in which the scenario parameters include a structured identifier.

[0221] Method 4: Method 3, in which the structured identifier includes a uniform resource locator (URL) including one or more tokens indicative of the scenario parameters.

[0222] Method 5: Method 4, in which the one or more tokens include at least one of a product number, a batch number, or a serial number.

[0223] Method 6: Any of the foregoing Methods, in which the first application is executed in a first domain, and in which executing the second application includes executing the second application in a second domain different from the first domain. [0224] Method 7: Any of the foregoing Methods, including: presenting, by the first application, at least one second tool usable to set content corresponding to the scenario parameters, wherein the page presented in the first application includes the content; obtaining, at the first application, altered content based on user control of the at least one second tool; and altering the page of the second application based on the altered content by executing the second application independently from the first application, to obtain the altered page including the altered content.

[0225] Method 8: Any of the foregoing Methods, in which presenting the altered page includes presenting, in a user interface of the first application, a live-updating page of the second application that changes in real time to reflect changes made using the at least one tool.

[0226] Method 9: Method 8, in which the user interface includes an iframe in which the live-updating page is presented, and a host of the first application and a client of the second application are configured to communicate with one another using postMessages. [0227] Method 10: Method 8 or 9, including: receiving a user interaction with an element of the live-updating page in the first application; executing the second application in response to the user interaction; and updating the live-updating page in the first application based on the execution of the second application based on the user interaction.

[0228] Method 11: Method 8, 9, or 10, including: receiving a user interaction with an element of the live-updating page in the first application; and, in response to the user interaction, presenting, in the first application, a tool usable to modify the element.

[0229] Method 12: Any of the foregoing Methods, in which the first application is configured to generate a token based on the scenario parameters, the token enabling the second application to access resources associated with the scenario parameters.

[0230] Method 13: Method 12, in which the token indicates a location at which the altered page is accessible.

[0231] Method 14: Method 12 or 13: in which the token is configured to expire after a predetermined time duration.

[0232] Method 15: Any of the foregoing Methods, in which the first application includes a host, and the second application includes a client, and in which the host and the client are configured to communicate with one another via application programming interface (API) endpoints.

[0233] Method 16: Any of the foregoing Methods, including: storing, at the first application, a value of a local variable corresponding to device access to the page; and updating the stored value of the local variable based on user interaction with the page of the second application.

[0234] Method 17: Any of the foregoing Methods, in which the first application is configured to generate a structured identifier based on the scenario parameters, and in which the second application is configured to: parse the structured identifier to obtain at least one token, and render the altered page with content based on the at least one token. [0235] Method 18: A computer-implemented method that includes: receiving, at a first application, user input indicative of a structured identifier; providing the structured identifier from the first application to a second application; parsing, by the second application, the structured identifier to obtain at least one token; rendering, by the second application, a page based on the at least one token; and presenting the rendered page in the first application.

[0236] Method 19: Method 18, including generating the structured identifier by the first application, in which generating the structured identifier includes: receiving, at the first application, user input indicative of at least one scenario parameter; and generating the structured identifier such that the structured identifier provides the at least one scenario parameter.

[0237] Method 20: Method 19, in which the at least one scenario parameter includes at least one of a serial number, a batch number, or a product number.

[0238] Method 21 : Method 19 or 20, in which the structured identifier includes the at least one scenario parameter.

[0239] Method 22: Method 19, 20, or 21, in which generating the structured identifier includes: receiving, at the first application, user input including a selection of a schema; and generating the structured identifier with a format that conforms to the schema.

[0240] Method 23: Method 22, in which the schema includes a GS1 Digital Link schema or a digital product passport (DPP) schema.

[0241] Method 24: Any of Methods 18-23, in which the structured identifier includes a uniform resource locator (URL).

[0242] Method 25: Method 24, including: simulating, by the first application, redirect behavior to generate a second URL that is different from the URL; and presenting the second URL in a user interface of the first application. [0243] Method 26: Method 24 or 25, including: receiving, in the first application, a direct user edit to the URL; and altering the at least one taken based on the direct user edit.

[0244] Method 27: Any of Methods 18-26, in which the at least one token includes at least one of a serial number, a batch number, or a product number.

[0245] Method 28: Any of Methods 18-27, in which rendering the page based on the at least one token includes: accessing a third-party data source to obtain a pre-registered state corresponding to a first token of the at least one token; and rendering the page based on the pre-registered state.

[0246] Method 29: Any of Methods 18-28, in which rendering the page based on the at least one token includes: accessing a mock state corresponding to a first token of the at least one token, wherein the mock state is provided by the first application; and rendering the page based on the mock state.

[0247] Method 30: Method 29, in which the mock state includes at least one of an authentication state, an expiration state, or a lifecycle state.

[0248] Methods 31 : Any of Methods 18-30, in which parsing the structured identifier includes: determining, from among a plurality of schema, a schema to which the structured identifier conforms; and extracting the at least one token from the structured identifier based on a format corresponding to the schema.

[0249] Method 32: Any of Methods 18-31, including generating the page based on context data that includes at least one of: a hardware type or software type of a device accessing the page, a location of the device, a time of accessing the page, or a language in which to present the page. The context data is provided from the first application to the second application.

[0250] Method 33: Any of Methods 18-32, in which presenting the page in the first application includes presenting the page in an iframe of the first application.

[0251] Method 34: Any of Methods 18-33, including executing the first application and the second application independently from one another.

[0252] Aspect 35: A non-transitory computer-readable medium tangibly encoding a computer program operable to cause a data processing apparatus to perform operations of any of Methods 1-34. [0253] Aspect 36: A system including: one or more processors; and one or more computer-readable media encoding instructions that, when executed by the one or more processors, cause the one or more processors to perform the operations of any of Methods 1-34.

[0254] A number of implementations have been described. Nevertheless, it will be understood that various modifications may be made. Elements of one or more implementations may be combined, deleted, modified, or supplemented to form further implementations. In yet another example, the logic flows depicted in the figures do not require the particular order shown, or sequential order, to achieve desirable results. In addition, other steps may be provided, or steps may be eliminated, from the described flows, and other components may be added to, or removed from, the described systems. Accordingly, other implementations are within the scope of the following claims.

Claims

What is claimed is:

1. A computer-implemented method, comprising: presenting a page of a second application in a first application; presenting, by the first application, at least one tool usable to set scenario parameters for the second application; obtaining, at the first application, the scenario parameters based on user control of the at least one tool; altering the page of the second application based on the scenario parameters by executing the second application independently from the first application, to obtain an altered page; and presenting the altered page in the first application.

2. The computer-implemented method of claim 1, wherein the scenario parameters comprise at least one of: a hardware type or software type of a device accessing the second application; a location of the device accessing the second application; a time of accessing the second application; or a language in which to present the second application.

3. The computer-implemented method of claim 1, wherein the scenario parameters comprises a structured identifier.

4. The computer-implemented method of claim 3, wherein the structured identifier comprises a uniform resource locator (URL) comprising one or more tokens indicative of the scenario parameters.

5. The computer-implemented method of claim 4, wherein the one or more tokens comprise at least one of a product number, a batch number, or a serial number.

6. The computer-implemented method of claim 1, wherein the first application is executed in a first domain, and wherein executing the second application comprises executing the second application in a second domain different from the first domain.

7. The computer-implemented method of claim 1, comprising: presenting, by the first application, at least one second tool usable to set content corresponding to the scenario parameters, wherein the page presented in the first application includes the content; obtaining, at the first application, altered content based on user control of the at least one second tool; and altering the page of the second application based on the altered content by executing the second application independently from the first application, to obtain the altered page including the altered content.

8. The computer-implemented method of claim 1, wherein presenting the altered page comprises presenting, in a user interface of the first application, a live-updating page of the second application that changes in real time to reflect changes made using the at least one tool.

9. The computer-implemented method of claim 8, wherein the user interface comprises an ifirame in which the live-updating page is presented, and wherein a host of the first application and a client of the second application are configured to communicate with one another using postMessages.

10. The computer-implemented method of claim 8, comprising: receiving a user interaction with an element of the live-updating page in the first application; executing the second application in response to the user interaction; and updating the live-updating page in the first application based on the execution of the second application based on the user interaction.

11 . The computer-implemented method of claim 8, comprising: receiving a user interaction with an element of the live-updating page in the first application; and in response to the user interaction, presenting, in the first application, a tool usable to modify the element.

12. The computer-implemented method of claim 1, wherein the first application is configured to generate a token based on the scenario parameters, the token enabling the second application to access resources associated with the scenario parameters.

13. The computer-implemented method of claim 12, wherein the token indicates a location at which the altered page is accessible.

14. The computer-implemented method of claim 12, wherein the token is configured to expire after a predetermined time duration.

15. The computer-implemented method of claim 1, wherein the first application comprises a host, and the second application comprises a client, and wherein the host and the client are configured to communicate with one another via application programming interface (API) endpoints.

16. The computer-implemented method of claim 1, comprising: storing, at the first application, a value of a local variable corresponding to device access to the page; and updating the stored value of the local variable based on user interaction with the page of the second application.

17. The computer-implemented method of claim 1, wherein the first application is configured to generate a structured identifier based on the scenario parameters, and wherein the second application is configured to: parse the structured identifier to obtain at least one token, and render the altered page with content based on the at least one token.

18. A computer-implemented method, comprising: receiving, at a first application, user input indicative of a structured identifier; providing the structured identifier from the first application to a second application; parsing, by the second application, the structured identifier to obtain at least one token, rendering, by the second application, a page based on the at least one token; and presenting the rendered page in the first application.

19. The computer-implemented method of claim 18, comprising generating the structured identifier by the first application, wherein generating the structured identifier comprises: receiving, at the first application, user input indicative of at least one scenario parameter; and generating the structured identifier such that the structured identifier provides the at least one scenario parameter.

20. The computer-implemented method of claim 19, wherein the at least one scenario parameter comprises at least one of a serial number, a batch number, or a product number.

21. The computer-implemented method of claim 19, wherein the structured identifier comprises the at least one scenario parameter.

22. The computer-implemented method of claim 19, wherein generating the structured identifier comprises: receiving, at the first application, user input comprising a selection of a schema; and generating the structured identifier with a format that conforms to the schema.

23. The computer-implemented method of claim 22, wherein the schema comprises a GS1 Digital Link schema or a digital product passport (DPP) schema.

24. The computer-implemented method of claim 18, wherein the structured identifier comprises a uniform resource locator (URL).

25. The computer-implemented method of claim 24, comprising: simulating, by the first application, redirect behavior to generate a second URL that is different from the URL; and presenting the second URL in a user interface of the first application.

26. The computer-implemented method of claim 24, comprising: receiving, in the first application, a direct user edit to the URL; and altering the at least one taken based on the direct user edit.

27. The computer-implemented method of claim 18, wherein the at least one token comprises at least one of a serial number, a batch number, or a product number.

28. The computer-implemented method of claim 18, wherein rendering the page based on the at least one token comprises: accessing a third-party data source to obtain a pre-registered state corresponding to a first token of the at least one token; and rendering the page based on the pre-registered state.

29. The computer-implemented method of claim 18, wherein rendering the page based on the at least one token comprises: accessing a mock state corresponding to a first token of the at least one token, wherein the mock state is provided by the first application; and rendering the page based on the mock state.

30. The computer-implemented method of claim 29, wherein the mock state comprises at least one of an authentication state, an expiration state, or a lifecycle state.

31. The computer-implemented method of claim 18, wherein parsing the structured identifier comprises: determining, from among a plurality of schema, a schema to which the structured identifier conforms; and extracting the at least one token from the structured identifier based on a format corresponding to the schema.

32. The computer-implemented method of claim 18, comprising generating the page based on context data that comprises at least one of: a hardware type or software type of a device accessing the page, a location of the device, a time of accessing the page, or a language in which to present the page, wherein the context data is provided from the first application to the second application.

33. The computer-implemented method of claim 18, wherein presenting the page in the first application comprises presenting the page in an iframe of the first application.

34. The computer-implemented method of claim 18, comprising executing the first application and the second application independently from one another.

35. A non-transitory computer-readable medium tangibly encoding a computer program operable to cause a data processing apparatus to perform operations of any of claims 1-34.

36. A system comprising: one or more processors; and one or more computer-readable media encoding instructions that, when executed by the one or more processors, cause the one or more processors to perform the operations of any of claims 1-34.