Patent Application
20190179620
This disclosure relates to a software architecture usable to build web pages via a web application and a content module bundler, according to various embodiments.
Hypertext Markup Language (HTML) and computer languages such as JavaScript are frequently used to construct web pages. As web pages have evolved, their underlying source code has gotten more complicated and offered an increasing array of functionality.
With increased complexity, designing, implementing, and updating web applications has also become increasingly cumbersome and difficult. An error in the source code of one area of a web application can render the application partially or totally unusable, for example, even if such an error relates to only a small portion of the web application. Further, tight integration of content with functionality and design may tend to increase the software testing burden when making updates to a web application (particularly for applications with multiple functionalities).
A web application may include one or more web pages that feature various content and functionality. Various software architectures can be used to service a web page request.
One extremely basic method is to simply serve a static web page to the user. A static web page may generally only be changed in response to manual editing. The modern Internet, however, has feature-rich web pages that include programming elements and dynamically generated text, images, and other data.
A web application may therefore have programming code that dictates its style and layout. The web application may make data requests to a data source, such as an SQL or other database, to generate content for the end user.
Changing such a web application may require editing scripting code in one or more locations. Such edits can have negative consequences, including breaking functionality of one or more portions of the web application. Even when attempting to design or modify one particular portion of a web application (e.g. one or more specific web pages), there is no guarantee that other portions of the web application will not be negatively impacted.
The present specification, however, features a modular web content architecture that separates out the responsibility of rendering certain content to a user into different independent renderable content modules. A front-end application can call on a module bundler application to provide self-contained portions of content (e.g. modules) that adhere to a particular architectural format used by both the front-end application and the module bundler. The module bundler delivers one or more independent renderable content modules to the front-end application, which can then easily integrate the content modules into a web page. The front-end application may not need to worry about error handling or whether some effect within an independent renderable content module could cause an impact on another unrelated portion of the front-end application. This structure provides a useful way to provide and update web content.
Such an architecture can be even more beneficial in larger web applications that may be maintained by many different development teams. Consider a web page that supports five different functionalities as implemented by five different software development teams. Without a modular content architecture, any time one of these software teams makes a change, the remaining four teams may all need to perform verification and testing that the change does not cause any errors for the other functionalities. Such testing can be expensive and time consuming. With a modular content architecture, however, there is no such need for testing in various embodiments. If an independent renderable content module is used to encapsulate functionality, then it may be sufficient to simply do software testing only within that module (and without the need to involve other software development teams). This approach allows for faster and more reliable web software development. Note that the phrases “independent [and] renderable”, as referring to a content module, refers in various embodiments to the fact that the content module is not dependent on a particular front-end web application, and contains the ability to self-render. A specific content module may be independent from a front-end application, for example, because that content module is self-contained in such a way that it does not require particular settings or operations from the front-end application in order to be successfully included in a web page (and to render its content).
This specification includes references to “one embodiment,” “some embodiments,” or “an embodiment.” The appearances of these phrases do not necessarily refer to the same embodiment. Particular features, structures, or characteristics may be combined in any suitable manner consistent with this disclosure.
“First,” “Second,” etc. As used herein, these terms are used as labels for nouns that they precede, and do not necessarily imply any type of ordering (e.g., spatial, temporal, logical, cardinal, etc.).
Various components may be described or claimed as “configured to” perform a task or tasks. In such contexts, “configured to” is used to connote structure by indicating that the components include structure (e.g., stored logic) that performs the task or tasks during operation. As such, the component can be said to be configured to perform the task even when the component is not currently operational (e.g., is not on). Reciting that a component is “configured to” perform one or more tasks is expressly intended not to invoke 35 U.S.C. § 112(f) for that component.
Turning to
As shown, system 100 includes browser 105, front end application 110, mid-tier service 120, and module bundle(s) 130. Browser 105 may be a web browser of a user, such as GOOGLE CHROME™, APPLE SAFARI™, MICROSOFT INTERNET EXPLORER™, etc. More broadly, browser 105 may be any software application that allows web content to be viewed on a computing device (e.g. browser 105 could also include smartphone applications that support ANDROID WEBVIEW™ or another way to view web content, for example). Browser 105 makes a browser request 107 to front-end application 110, as shown. This may be a hyper-text transfer protocol (HTTP) request, in various embodiments, such as a request for a particular web page or other resource.
Front-end application 110 is a web application in various embodiments, and may be implemented by one or more web servers. Such web applications can have a variety of functionality, including displaying text and media (e.g. images, sound, videos), receiving user input, etc. Web applications can be implemented in a variety of languages, including HTML, JavaScript, PHP, Java, etc.
In some instances, front-end application 110 may perform a module configuration read 112. This operation may include reading one or more configuration files for the front-end application to determine what independent renderable content modules will be requested by the front-end application, and/or additional configuration information for those modules. In one instance, a configuration file might resemble the following format
In this brief example, there are two independent renderable content modules used by the front-end application. The names of these modules may be arbitrary, but serve to identify the module to module bundler(s) 130 in various embodiments. “Column” refers to an A or B column in this example, where the first independent renderable content module will be displayed in column A (e.g., a first column) while the second listed independent renderable content module will be displayed in column B (e.g. a second column adjacent to the first column). Various different layout types are possible, however, and are not confined to simply having two columns. The “promo” attribute also indicates whether promotional content (e.g. advertising) should be included within a particular module, in this example. As will be appreciated, different attribute information may be used within module configuration information in various embodiments (for layout/placement, and for other factors as well). Front-end application 110 may also receive required dependencies for server-side rendering from content platform module 114 in some embodiments. Such dependencies can include library or other dependencies (e.g. a cascading style sheets (CSS) dependency listing one or more particular files, a JavaScript functions library dependency listing one or more particular files, etc.) Thus, in some instances, extended functionality beyond content rendering can be provided to a front-end application via content platform module 114.
Front-end application makes an external module request 118 to mid-tier service 120, in various embodiments, as an HTTP formatted request. The external module request may specify the identities of independent renderable content modules to be retrieved (e.g. user_balance_information, recent_transactions, etc.).
Front-end application also delivers rendered page 165 to browser 105 in response to browser request 107 in various embodiments. This rendered page includes all necessary markup, code, text, images, etc. necessary to display a web page for the user on browser 105. The rendered page may therefore include a variety of different elements inside it that reflect included independent renderable content modules, as well as any additional content made directly available via front-end application 110. For example, a web page format may be defined by front-end application 110 (and can be stored in content platform module 114 in some cases).
Mid-tier service 120, in various embodiments, includes a software application that that interacts with module bundler(s) 130. For example, mid-tier service 120 may pass configuration and registry information 125 to a module bundler, and may also receive back a module bundle 145 from a module bundler. The module bundle may contain a group of one or more independent renderable content modules, as prepared by module bundler(s) 130 (e.g. including localized content, data retrieved from back end services 140, formatting and/or code for execution, etc.).
Module bundler(s) 130 includes one or more module bundlers, in various embodiments. A module bundler may take particular operations relative to one or more independent renderable content modules. These operations may include registry validation 132, making a content module fetch 134, and performing a locale content read 138 in various embodiments (e.g., reading an appropriate locale file for a user's request). A module bundler may also make parallelized data calls 136 to back end services 140. These parallelized data calls can include one or more requests sent to one or more databases to retrieve data necessary to build a content module and/or display information within the content module when it is rendered on a web page.
HTTP boundaries 109, 119, and 139 are also illustrated in
Turning to
As shown, system 200 includes user devices 205, 210, 215, a web server system 220, a bundling system 230, a back end system 240, a records DB (database) 250, and transaction system 260. Note that other permutations of this figure are contemplated (as with all figures). While certain connections are shown (e.g. data link connections) between different components, in various embodiments, additional connections and/or components may exist that are not depicted. Further, components may be combined with one other and/or separated into one or more systems.
User devices 205, 210, and 215 may be any type of computing device. Thus, these devices can be a smartphone, laptop computer, desktop computer, tablet computer, etc. As discussed below, user devices such as 205, 210, and 215 may engage in various actions, including transactions, using transaction system 260. The systems shown may comprise one or more computing devices each having a processor and a memory. Network 250 may comprise all or a portion of the Internet. One or more of web server system 220, bundling system 230, back end system 240, records DB 250, and transaction system 260 may be controlled by an electronic service provider entity, which may be an electronic transaction payment service provider in some instances (allowing for transfer of currency or other quantities, for example).
Transaction system 260 may correspond to an electronic payment service such as that provided by PayPal™. Transaction system 260 may have a variety of associated user accounts allowing users to make payments electronically and to receive payments electronically. A user account may have a variety of associated funding mechanisms (e.g. a linked bank account, a credit card, etc.) and may also maintain a currency balance in the electronic payment account. A number of possible different funding sources can be used to provide a source of funds (credit, checking, balance, etc.). User devices 205, 210, and 215 can be used to access electronic payment accounts such as those provided by PayPal™ In various embodiments, quantities other than currency may be exchanged via transaction system 260, including but not limited to stocks, commodities, gift cards, incentive points (e.g. from airlines or hotels), etc.
Records database (DB) 250 includes records related to various transactions taken by users of transaction system 260. These records can include any number of details, such as any information related to a transaction or to an action taken by a user on a web page or an application installed on a computing device (e.g., the PayPal app on a smartphone). Many or all of the records in records database 250 are transaction records including details of a user sending or receiving currency (or some other quantity, such as credit card award points, cryptocurrency, etc.).
Web server system includes front-end application 110 in the embodiment shown, while bundling system 230 includes mid-tier service 120 and module bundler(s) 130. Back end system 240 includes back end services 140 and is connected to records database 250 in this embodiment. Different systems than those depicted may implement front-end application 110, mid-tier service 120, module bundler(s) 130, and back-end services 140, however, in various embodiments.
Turning now to
Operations described relative to
In operation 310, web server system 220 receives a request for a first web page from a first user, according to some embodiments. This request may be received via hypertext transfer protocol (HTTP) as a request sent from a user's web browser or another application. (Note that the HTTPS protocol is also included by the term HTTP, as used herein.) The request is received by a web application running on web server system 220 in some embodiments. The web application may be implemented by an instance of a web server such as APACHE™, for example. Thus, the web application can include one or more web pages that have executable code in them, such as JavaScript, PHP, AJAX, etc.
In operation 320, the web application identifies one or more independent renderable content modules required by the web application to build a requested web page, according to some embodiments. (Note that if a content module that is “required” to build a web page is unavailable or has an error, the web page can still be successfully built in various embodiments.)
The requested web page may have one or more configurable display areas that are configured to be populated with dynamic content based on the independent renderable content modules. These configurable display areas may be arranged in columns, rows, and/or any other formation. The web page may also have one or more additional display areas not configured to be populated with content from independent renderable content modules. Thus, a web page could have some particular images, text, control elements, etc., that are not derived from the independent renderable content modules, but are simply part of a menu bar on the top or bottom of the web page, for example.
Note that different portions of a web application (e.g. different web pages within the application) may also have different independent renderable content modules that are used. One web page in a web application may use independent renderable content modules A, B, and C, while another web page uses independent renderable content modules A and D.
Further, even within the same web page in a web application, varied independent renderable content modules can be used based on context. A particular user who is on a specific web page might make use of independent renderable content modules A and B, while a different user might only use independent renderable content module C. Differing requirements for independent renderable content modules can be due to personalization, about which more information can be found in related U.S. patent application Ser. No. 15/835,055.
Identifying one or more independent renderable content modules, in operation 320, can include reading one or more configuration files for a web page and/or web application. A configuration file may specify particular independent renderable content modules to be used when building a web page. A configuration file may also include different contextual rules for building the page as well. For example, a configuration file may specify that if condition #1 is met (such as a user falling into a certain category, the user having an IP address from a particular country or region, or any other number of contexts), then certain independent renderable content modules should be used, while if condition #2 is met, different independent renderable content modules should be used. A configuration file for the above purposes may be a “flat file” in a plain text format, or any other format, and may be incorporated into a rules/decision engine in some embodiments.
In operation 330, the web application makes an external module request to a separate module bundler application, according to various embodiments. This request may be made via an external module request protocol, which can be HTTP and/or another protocol (e.g. JavaScript Object Notation (JSON), Simple Object Access Protocol (SOAP), etc.). Operation 330 can include front-end application 110 making a request to a system that includes mid-tier service 120 and/or module bundler(s) 130 (which, in some instances, may be installed on the same computer system).
The external module request may specify identities of the independent renderable content modules that are being requested, and can also include configuration information for those modules (e.g. parameters that may affect how module bundler(s) 130 assemble the independent renderable content modules).
In operation 340, a module bundler application receives and parses the external module request, according to various embodiments. The module bundler application, as discussed above, may comprise mid-tier service 120 and/or module bundler(s) 130 in some instances, but may be any software and/or hardware application configured to perform the operations discussed herein. Parsing the external module request can include reading the data contained in the request and storing relevant attribute information into appropriate intermediate data structures.
In operation 350, based on the parsing, the module bundler application fetches one or more independent renderable content modules, according to some embodiments. Fetching the independent renderable content modules can include reading one or more files or reading from one or more databases that contain the independent renderable content modules. Each of the independent renderable content modules may include executable code and/or other data. The executable code may be compiled code, intermediate form code such as a Java bytecode, or interpretable script code such as JavaScript.
In some embodiments, fetching in operation 350 includes performing a validation check to ensure that the one or more requested independent renderable content modules are valid. This can include making a registry check (e.g. sending a query to a registry) to see if the status of a module is valid. Instead of a valid status, in some cases, an independent renderable content module could have a status such as deprecated, forbidden, or might simply not exist (to the knowledge of module bundler(s) 130—for example if a module was misidentified with an incorrect name in the external module request 118). Independent renderable content modules can be fetched from storage locally available to bundling system 230, in some instances, or remote storage.
In operation 360, the module bundler application integrates the one or more independent renderable content modules to build a module bundle comprising content for the one or more independent renderable content modules, according to some embodiments. In this context, the content that is included for the one or more independent renderable content modules includes both executable elements as well as data. Thus, “content” in an independent renderable content module can include HTML markup, Javascript or other code, style and formatting information such as CSS (cascading style sheets) information, and text, images, video, audio, etc., for display.
Integrating the one or more independent renderable content modules can include several operations, in various embodiments. One function that may be performed are various back-end data calls (e.g. to back-end services 140). Different databases may need to be accessed to find content for the modules. Such content may be generic (e.g. the same for all users) or may be contextualized content (e.g. account information or other information that is specific to a user or to a group of users, but not one or more other users). These back-end data calls may be made in parallel to speed operations.
Another function that may be performed when integrating one or more independent renderable content modules into a bundle is reading localized content (e.g. as in local content read 136). The independent renderable content module, rather than containing hard-coded text or other content for display, may include references such as strings that refer to particular items. Thus, a string called “Greeting_1” might cause bundling system to check a translation database and pull out the appropriate content based on a user's region or language. The string “Greeting_1” could be replaced with “Welcome to your PayPal account!” for English language users, for example, or instead be replaced with “Bienvenido a su cuenta PayPal!” for Spanish language users. Many different pieces of content within an independent renderable content module may be localized, including images and other content not limited to display text.
Further localization for an independent renderable content module may include changing a layout of the module's content as well. Certain different colors may be used (e.g. in some cultures and regions it may be appropriate to use a black color but not a blue color within a particular context). Content such as text, images, etc., may also appear in different areas when displayed, according to localization rules, as desired. E.g. a rule might specify one layout for English users from the U.S. and the United Kingdom, but a different layout for English users from Australia, if desired. Many different such customizations are possible. During the integration process of operation 360, these various customizations may be performed.
Error handling can also be performed during operation 360 (or elsewhere if desired). For example, a module bundler application may encounter an error condition during integration of a particular one of the plurality of independent renderable content modules. The error encountered can be a variety of different error types, and may be handled appropriately based on that type. In some embodiments, an error encountered when integrating a content module may be a critical or non-critical error. A developer of the independent renderable content module can define the conditions for whether an error is a critical one or not for that module. In some embodiments, a developer of front-end application 110 may also decide whether a particular error in the module is considered to be a critical or non-critical error for the front-end application. In other words, both the module itself and the front-end application can make determinations as to the status (e.g. criticality) of an error, and in some instances an error indicated by the module as non-critical could still be deemed critical by the front-end application.
When an error condition is encountered by bundling system 230, the module bundler application may generate a content error for the particular independent renderable content module according to an external module request protocol. This content error can then be included in the module bundle that is being built. The content error can specify a variety of information, including what portion(s) of the module are affected by the error and whether the error is a critical one (as considered by the module—the front end app may make its own determination in some cases.)
The independent renderable content module, after being integrated, may include various content (e.g. executable code, HTML, text, images, etc.) and be formatted according to any defined external module request protocol. When an error is present, the independent renderable content module may include the error condition information but omit some or all other information. In the case of a critical error (as defined by the independent renderable content module rules) the module may include nothing else besides error information (e.g. no other content). In other instances, the error information may be included along with other content.
In operation 370, the module bundler application returns, to the web application, the module bundle, according to some embodiments. The module bundle may include a list of the requested independent renderable content modules, as integrated during operation 360 (e.g. after processing). As noted above, each of the independent renderable content modules may also have one or more error conditions included within them, if an error was encountered during integration.
In operation 380, a web application (e.g. front-end application 110) iterates through a module bundle to build the web page requested by the user, according to some embodiments.
Iterating through the module bundle may include executing a “view” function that is included within different independent renderable content modules. Such a view function can essentially cause the module to execute various code to render that independent renderable content module appropriately according to its own internal formatting. The web application may place the independent renderable content module within a particular configurable display area on a web page such that the actual appearances of images, text, control elements, etc. within the independent renderable content module is not dictacted by the web application, but whether the module appears on the left or right hand side of the web page (for example) is controlled by the web application. During the iteration process, the web application may take steps such as checking for errors and determining whether the error is critical or non-critical.
In some embodiments, responsive to a content error encountered in a module bundle, a web application may omit a display of a particular independent renderable content module or alternatively, display an error message corresponding to the particular independent renderable content module. For example, if the “user_balance_information” independent renderable content module encounters a critical error (e.g. there is no data for the module other than the error information), the web application may render an error message on the web page for the user, such as “ERROR: Unable to load balance information at this time.”
If the “user_balance_information” independent renderable content module encounters a non-critical error, a different message could be displayed. For example, consider a scenario where a user has a checking account, a savings account, and a 401(k) retirement account. Ordinarily, the user_balance_information module might return a dollar amount for each of these accounts, but during integration of the module, an error may have been encountered when querying the 401(k) account (which could be part of a different database than the checking and savings accounts). In this example, the error may be a non-critical one. The rendered content for the module might be “Savings account balance: $1,000; Checking account balance: $500; 401(k) account balance: currently unavailable.” In another example, an error for a promotional message (e.g. an advertisement or offer) might cause that portion of the independent renderable content module to be omitted from display. In other instances, an error in an independent renderable content module may result in the module being omitted entirely from the web page. A critical error in the module, for example, may cause a web application to simply not attempt to display the module's content within the web page. As will be appreciated, many different scenarios with a non-critical error that affects displayed content for an independent renderable content module are possible.
The web application, when iterating through the module bundle, may also review error information to determine whether in error in a particular independent renderable content module represents a critical error to the application itself. This may depend on the web page and the current context for the web application. For example, consider a web application that allows a user to transfer money from a checking account to a savings account. This web application (or portion thereof) may use the user_balance_information module to display the account balances so that the user can see how much money is available to move from the checking account. If the user_balance_information has an error such that the user is only able to see his savings account balance, but not a checking balance, then the app has encountered a critical error in this example: it is imperative that the user know how much money is in the checking account balance if he is to able to use it as a source of funds for the transfer. Thus, even if the user_balance_information has (from the module's perspective) a non-critical error (e.g. the savings information is still available), the web application itself may deem this a critical error and alter the content of the web page to reflect this appropriately (e.g., a message such as “ERROR: unable to make a transfer from checking account at this time.”). In an instance such as this, the web application can be said to disable one or more functionalities of the web application that are separate from the particular independent renderable content module (e.g. the user_balance_information module) that had the content error.
In other contexts, however, such as when a user is simply being displayed account balance information for informational purposes, the error in the user_balance_information module may be non-critical from the perspective of the web application. Again, many different related scenarios are possible, and web applications are not limited to only such financial transactions and may be used for many different purposes. Rather, the techniques of this disclosure broadly apply to an architecture that can be used to effectively handle content for many possible types of web applications and independent renderable content modules.
Likewise, in response to a content error in an independent renderable content module being a non-critical application error, the web application may maintain all other functionalities of the web application that are separate from the particular independent renderable content module that had the content error. Continuing the example above, if a web application offers functionalities that are not impacted by missing checking account balance information, all those functionalities may continue to be available to the user, and content for those functionalities (including control elements on the web page such as forms, menus, hyperlinks, etc.) may be rendered into the web page by the web application.
In operation 390, the web application returns the web page to the user, according to some embodiments. This operation may include making an HTTP transmission to the user responsive to that user's earlier request for a web page. The web page can be transmitted back to a user's web browser (or other requesting application).
Turning to
Note that more generally, program instructions may be stored on a non-volatile medium such as a hard disk or FLASH drive, or may be stored in any other volatile or non-volatile memory medium or device as is well known, such as a ROM or RAM, or provided on any media capable of staring program code, such as a compact disk (CD) medium, DVD medium, holographic storage, networked storage, etc. Additionally, program code, or portions thereof, may be transmitted and downloaded from a software source, e.g., over the Internet, or from another server, as is well known, or transmitted over any other conventional network connection as is well known (e.g., extranet, VPN, LAN, etc.) using any communication medium and protocols (e.g., TCP/IP, HTTP, HTTPS, Ethernet, etc.) as are well known. It will also be appreciated that computer code for implementing aspects of the present invention can be implemented in any programming language that can be executed on a server or server system such as, for example, in C, C+, HTML, Java, JavaScript, or any other scripting language, such as VBScript. Note that as used herein, the term “computer-readable medium” refers to a non-transitory computer readable medium.
In
In the illustrated embodiment, system 500 includes at least one instance of an integrated circuit (processor) 510 coupled to an external memory 515. The external memory 515 may form a main memory subsystem in one embodiment. The integrated circuit 510 is coupled to one or more peripherals 520 and the external memory 515. A power supply 505 is also provided which supplies one or more supply voltages to the integrated circuit 510 as well as one or more supply voltages to the memory 515 and/or the peripherals 520. In some embodiments, more than one instance of the integrated circuit 510 may be included (and more than one external memory 515 may be included as well).
The memory 515 may be any type of memory, such as dynamic random access memory (DRAM), synchronous DRAM (SDRAM), double data rate (DDR, DDR2, DDR6, etc.) SDRAM (including mobile versions of the SDRAMs such as mDDR6, etc., and/or low power versions of the SDRAMs such as LPDDR2, etc.), RAMBUS DRAM (RDRAM), static RAM (SRAM), etc. One or more memory devices may be coupled onto a circuit board to form memory modules such as single inline memory modules (SIMMs), dual inline memory modules (DIMMs), etc. Alternatively, the devices may be mounted with an integrated circuit 510 in a chip-on-chip configuration, a package-on-package configuration, or a multi-chip module configuration.
The peripherals 520 may include any desired circuitry, depending on the type of system 500. For example, in one embodiment, the system 500 may be a mobile device (e.g. personal digital assistant (PDA), smart phone, etc.) and the peripherals 520 may include devices for various types of wireless communication, such as wife, Bluetooth, cellular, global positioning system, etc. Peripherals 520 may include one or more network access cards. The peripherals 520 may also include additional storage, including RAM storage, solid state storage, or disk storage. The peripherals 520 may include user interface devices such as a display screen, including touch display screens or multitouch display screens, keyboard or other input devices, microphones, speakers, etc. In other embodiments, the system 500 may be any type of computing system (e.g. desktop personal computer, server, laptop, workstation, net top etc.). Peripherals 520 may thus include any networking or communication devices necessary to interface two computer systems.
Although specific embodiments have been described above, these embodiments are not intended to limit the scope of the present disclosure, even where only a single embodiment is described with respect to a particular feature. Examples of features provided in the disclosure are intended to be illustrative rather than restrictive unless stated otherwise. The above description is intended to cover such alternatives, modifications, and equivalents as would be apparent to a person skilled in the art having the benefit of this disclosure.
The scope of the present disclosure includes any feature or combination of features disclosed herein (either explicitly or implicitly), or any generalization thereof, whether or not it mitigates any or all of the problems addressed by various described embodiments. Accordingly, new claims may be formulated during prosecution of this application (or an application claiming priority thereto) to any such combination of features. In particular, with reference to the appended claims, features from dependent claims may be combined with those of the independent claims and features from respective independent claims may be combined in any appropriate manner and not merely in the specific combinations enumerated in the appended claims. The techniques disclosed above are specifically contemplated for use in combination with the techniques disclosed in U.S. application Ser. No. 15/835,055 in various embodiments and may be combined in any suitable way (e.g. using content personalization within the web content architecture disclosed herein).
This application is a continuation-in-part of, and claims priority to, U.S. patent application Ser. No. 15/835,055, filed Dec. 7, 2017 and entitled Dynamic Web Content Based on Contextual Profile, the contents of which are herein incorporated by reference in their entirety.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15835055 | Dec 2017 | US |
| Child | 15886570 | US |
