Patent Application
20230385027
This invention relates to a method and a standard for application packaging and integration, and, more particularly, to application resource integration and deployment into a cloud.
Computer systems present some challenges with regard to developing and installing updates and patches to hosted web applications. Software as Service (SaaS) web applications are integrated into systems by a vendor using special delivery and installation packages. However, if the vendor needs to integrate/deploy his application into a cloud, he will have to repeat all integration operations for each host or hosting platform several times. The hosts and the hosting platforms have applications that control the host or the hosting platforms. These applications make it very difficult and expensive to integrate external (third party) applications or web services.
Currently, integration of applications into hosts and hosting platforms is implemented by a controller. In case of a cloud system. A cloud (or cloud server) is a software-hardware combination of a host provider, which provides for functionality of external applications in its client's accounts.
In the field of cloud computing platforms, there exists an inefficiency of creation and deployment of client applications in conjunction with platform form operations. For example, cloud computing platforms may encounter problems related to effective application development and/or host deployment. Software as Service (SaaS) web applications are generally developed in a rigid association with a platform host. All processes relating to new applications in development are rigidly tied to platform host stacks deployment. Such method brought inconveniences and time losses in common with background related to necessity to resolve problems with applications on a core level.
The main disadvantage of conventional technologies is that, during a new application creation and deployment, a platform host is required to communicate packages having indefinite testing environment inside a package during application development. Moreover, the conventional technologies require excess deployment time, and a continuous internet connection is required during application creation. Accordingly, there is a need in the art for an efficient and inexpensive method for integration of the application itself, application updates and patches into a cloud platform host.
Embodiments described herein provide for frontend microservice development. Specifically, embodiments disclose systems and methods for creating and integrating a frontend microservice application into a host platform. The systems and methods can include communicating, to a UX development platform, a requirements package corresponding to a microservice frontend application; generating, by the UX development platform, a mockup package based on the requirements package; communicating the mockup package to a microservice frontend development platform, to a microservice frontend application; generating, by the microservice application development platform, a microservice frontend application package based on the mockup package; and integrating the microservice frontend application package, wherein a vendor application is integrated utilization the microservice frontend application based on the requirements package.
Conventionally, a frontend developer may encounter several challenges developing separated from the whole platform microservice to be used in a platform host as a part of multi microservice environment. Developing microservice via platform host raises supplementary development costs including deployment and sandbox adjustment (i.e., to the stack and platform host). Even minor changes to microservice code can necessitate deployment of all code to a stack again, resulting in transport loss. Frontend developers are usually provided with requirements for UI (User Interface) elements (buttons, fonts, colors, and others) and implementing each time from the scratch. The developer has to take into account many aspects in addition to writing the core of the business task itself of: how the microservice should appear with respect to the application itself, and how the microservice may appear and function in the common interface (platform host) and compliance with a single experience.
In some embodiments, FMD methods and systems can include a local microservices development mode that functions independently from a platform host, as described in detail in U.S. patent application Ser. No. 17/824,563, which is incorporated by reference in its entirety herein. In some embodiments, FMD methods and systems can additionally include processes for mockup and tokenization, i.e., tokens maintained in a unified library of widgets, for example, supported independent from a specific application and available to a frontend developer. In some embodiments, FMD methods and systems can further include interaction of microservice with the external world. For example, FMD methods and systems can enable communication between the frontend microservice in development with other microservices, the host itself, the Representational State Transfer (REST) request system, unit testing, application debugging, simulation of communication before host deploys, etc.
In some embodiments, FMD methods and systems can also include the use of specific cloud framework(s) as part giving everything needed to frontend developer and getting back the result as application, integrated part of the process. The framework preliminary separates new microservice (web application) to specific program layers. According to embodiments described here, task resolution is achieved effectively by good organization of communication among different parts of “blocks” involved into web application creation process overall. Thus, faster application readiness, improved testing and debugging, and reduced costs of application development can be obtained.
Such approach allows to decrease the time of frontend developer spent to a new microservice, allows him to be lower skilled. FMD systems and methods require a developer only to combine software layers, do debugging process and further deploy to a stack and a platform host a workable microservice. Specific REST-Store vertical details provide effective frontend-backend connection of the microservice developed described below allowing developer use one and the same code for such modes as local development (with emulated data transport level), unit testing and in production (runtime).
According to embodiments of the present invention, Systems and Methods for Frontend Microservice Development (FMD) are provided to improve application development process. The FMD solution effectively addresses the above-mentioned technical problems, providing an independent application creation process and efficient application deployment to a platform host minimizing downtime, on a platform host core level.
FMD systems and methods are provided for creating, sharing, and integrating a vendor application. Systems and methods for application development and deployment can include communicating, by a host platform, a framework package corresponding to an application framework, wherein the framework package comprises a software abstraction for providing generic functionality in developing a vendor application, receiving, by the host platform, an application package corresponding to a vendor application, wherein the application package comprises a plurality of metadata files, control method descriptions, and content files, and integrating the application package to generate an integration of the vendor application based on the application framework.
According to some embodiments, FMD systems and methods differ from previous prior art technologies in that the rigid connection application-host is broken at the time of application development. The host “adopts” already workable application that is easily deployed there. Even constant internet connection when application developing is not required for such scenario. Conventional systems and methods can require several hours merely to begin a process of developing new application, due to host operations. According to exemplary embodiments, a platform host is separated from application development process which brought many efforts. A new application can be created and tested before host deployment to enable production of reliable applications when deployed. Moreover, the necessity of fixing faults due to a host core level is omitted during application development, resolving an additional problem in conventional technologies. FMD systems and methods enable efficient application creation with respect to speed, reliability, resource savings.
For the purposes of promoting an understanding of the principles of the present disclosure, reference will now be made to the embodiments illustrated in the drawings, and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of this disclosure is thereby intended.
Embodiments may be implemented in hardware, firmware, software, or any combination thereof. Embodiments may also be implemented as instructions stored on a machine-readable medium, which may be read and executed by one or more processors. A machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computing device). For example, a machine-readable medium may include read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices, and others. Further, firmware, software, routines, instructions may be described herein as performing certain actions. However, it should be appreciated that such descriptions are merely for convenience and that such actions in fact result from computing devices, processors, controllers, or other devices executing the firmware, software, routines, instructions, etc.
It should be understood that the operations shown in the exemplary methods are not exhaustive and that other operations can be performed as well before, after, or between any of the illustrated operations. In some embodiments of the present disclosure, the operations can be performed in a different order and/or vary.
Embodiments described herein are directed to FMD methods and systems that can include a local microservices development mode that functions independently from a platform host, as described in detail in U.S. patent application Ser. No. 17/824,563, which is incorporated by reference in its entirety herein. In some embodiments, FMD methods and systems can additionally include processes for mockup and tokenization, i.e., tokens maintained in a unified library of widgets, for example, supported independent from a specific application and available to a frontend developer. In some embodiments, FMD methods and systems can further include interaction of microservice with the external world. For example, FMD methods and systems can enable communication between the frontend microservice in development with other microservices, the host itself, the Representational State Transfer (REST) request system, unit testing, application debugging, simulation of communication before host deploys, etc.
Frontend Microservice Development (FMD) systems and methods are provided to address the above-mentioned technical problems. FMD systems and methods provide a specific layer for a vendor microservice application frontend that provides all resources needed to a frontend developer to return an application as an integrated part of the process. The FMD facilitates task resolution effectively organizing and enabling communication between different components of web application creation process blocks. The FMD systems and methods enable timely application readiness, and improvements in testing and debugging. Thus, better operability of end user applications is achieved with reduced costs of application development. The frontend developer is enabled to specifically combine software layers and perform debugging process, deployment while minimizing time and effort spent developing a new microservice. FMD systems and methods include specific REST-Store vertical details to provide a more effective frontend-backend connection of the microservice, allowing the developer to use a single compilation of code for such modes as local development (with emulated data transport level), unit testing and runtime (i.e., production).
As shown in
UX development platform 120 enables creation of a set of design tokens, i.e., variables-constants for specific components and cases of their use. Operation 310 includes the creation of variables-constants that can be already used in handoff (visual look and feel documentation) gallery of reference components. See, for example
FMD system 100 enables one or more mockup(s) 124 to be transmitted to and/or retrieved by a microservice platform 130. Microservice development platform 130 enables one or more developer(s) 132 to generate microservice frontend application 134 associated with application microservice requirements 110, utilizing mockup(s) 124. Microservice development platform 130 performs page-by-page microservice design development. Microservice development platform 130 includes testing module 136 that further enables developer(s) 132 to conduct unit testing, end-to-end (e2e) testing, etc. and debug microservice frontend application 134.
As depicted, microservice frontend application creation at development platform 130 is separated from the platform host 140 itself. According to the exemplary embodiment, one or more frameworks associate an application of development platform 110 to a (production) application of platform host (130). That is, the framework(s) mutually connect the respective applications. The framework(s) comprise fundamental templates needed for application and testing at development platform 110. The framework(s) also comprise necessary specific means to integrate and deploy an application at a platform host (hosting cloud) 130.
In an exemplary embodiment, microservice development platform 130 enables generation microservice frontend application 134 based on application code 134a and framework 134b. Application code 134a can include developer-written code. Framework 134b (e.g., VUE) can provide a software abstraction for providing generic functionality, that can be selectively adapted and implemented by application code 134a, thus providing application-specific software, such as for building user interfaces. Framework 134b can provide this abstraction built on top of standard programming languages (e.g., HTML, CSS, JavaScript, etc.), providing a declarative and component-based programming model permitting efficient development of application-specific software, such as a user interface, whether simple or complex.
When FMD 100 is configured to deploy application 134, development platform 110 can generate an application bundle that implements application 134 and framework 104 as a stand-alone, all in one container. According to the exemplary embodiment, developer 132 (e.g., a cloud application vendor or the like) can bundle application code 134a and framework 134b according to the APS. The format of the bundle depends on the receiver, such as platform host 130. If the receiver is a standard WINDOWS desktop, then the software can be packaged using standard installers, and the file has a *.exe or *.msi extension. The installer includes unpacking rules, that includes a user dialog, writing into the registry, checking for updates, and so on. In the case of APS, the bundle can have a app.zip extension, and includes metadata, scripts and software code itself.
Exemplary development application 102 is transferred via an application bundle to platform host 140. microservice frontend application 134 is generated inside the platform host 140 based on frontend applications 134a and framework 134b. Platform host 140 can include a controller, i.e., an application packaging controller, having a runtime module configured to distribute microservice frontend applications 134 to one or more end user(s). The APS is a specification defining a life cycle of microservice frontend application 134 in a cloud. The application's life cycle includes packaging, delivering to the cloud, integrating (and unpacking/deploying) into the cloud, distributing to clients, licensing, functionality, updates and deletion. The APS can include an Application Programming Interface (API) for accessing the APS functions from a program code or by http/https requests. The APS provides for efficient integration of SaaS web applications, such as microservice frontend application 134, into the cloud. According to the exemplary embodiment, in order for an application to function according to the APS, an APS module 138 (i.e., a controller) is integrated into a software hosting platform of a hosting cloud (platform host 140). APS module 138 functions as a connector for controlling microservice frontend application(s) 134.
As shown in
UX development platform 120 includes a handoff 230 document, which can include a gallery of reference components. UX development platform 120 can enable a handoff mode on mockups to facilitate sharing detailed information about design tokens used in mockups. Handoff 230 can include each detail and digital asset required for the development team to bring a microservice frontend design to life.
UX development platform 120 enables one or more Development UX-UI-Theme(s) 220 to be utilized with handoff 230 in the implementation of one or more Development UX-UI-Theme-Kit 220 based on microservice requirements 110. SCSS variables can be physically imported into UI-Theme-Kit 220 to minimize inconsistencies in the mockup(s), address designs issues and permit customization and skinization.
UX development platform enables implementation of one or more design Storybook(s) 250. Storybook(s) 250 enable UX developers to develop components, permits documenting components for reuse, visually tests such components, and capture their states to spot inconsistencies. In addition, FMD system 100 enables publishing Storybook(s) 250 by UX development platform 120 as one or more mockup(s) 124 published to be implemented by microservice development platform 140.
As shown in
At operation 315, page-by-page microservice design development is performed. Operation 315 can include generation of mockups associated with the microservice design. This is a distinct approach from conventional methodologies for post-generation of mockup. According to embodiments, separate SCSS variables can be implemented initially in mockups, and physically imported into the UI Kit and into the microservice applications. Accordingly, such embodiments enable parity between the resulting layout and the mockups. Additionally, operation 315 can permit designers themselves to address design issues. The embodiments provide another advantage in facilitating customization and skinization, where skinization refers to a process of applying specific set of user experience (UX) rules specific for each consumer. For example, skinization can involve the application of specific tokens, colors, icons, etc.
Operation 315 includes one or more processes for creation of a set of design tokens, i.e., variables-constants for specific components and cases of their use. Operation 310 includes the creation of variables-constants that can be already used in handoff (visual look and feel documentation) gallery of reference components. See, for example
Operation 315 can include the integration of design tokens into the theme project, to UI elements override, and to Framework UI project KIT. Tokens can be used inside the main project (Framework) and also in UI KIT project as a part of Framework project, and in final microservices. Tokenization methods are used such that token design sets are created and interconnected with design components, which can then be used for other projects and reconfigured based on changes in the project. A token defines one or more sets of variables-constants. For example, as shown in (see below images) a token defines one or more sets of variables-constants for components and cases (conditions) where they are used.
When one or more tokens are changed, they are transmitted to web applications and change the presentation without the need for developers to work. The use of a tokenization sub-process allow these changes to be implemented without hardcoding widget styles (colors, font sizes, margins, etc.) by designers and developers. In addition, one or more tokens can be provided with one or more a default value(s) to allow microservice applications to execute locally during development.
In some embodiments, each design token can be provided in a single file that includes all such design tokens. Any token update can include execution of the following sub-processes: (1) automatically updating a designer widget library; (2) automatically updating a developer theme package; and (3) updating a product with new styles in accordance with the design token(s).
Each mockup can be implemented in a “handoff” mode by developer(s). In Handoff mode, information can be communicated about design tokens used in mockups. Design tokens can be integrated further to a theme project, to UI elements override, and to Framework UI project KIT. Tokens are used inside the main project (Framework) and also in UI KIT project as a part of Framework project, and in final microservices.
At operation 320, Frontend microservice development is performed. Operation 320 can include one or more sub-processes for generation of microservice. Operation 320 can include one or more sub-processes for page-by-page development of the microservice, involving the development of software code for the microservice. Page-by-page microservice development can be configured to commence after mockups for each web screen views are created. Each page is developed based on an associated mockup. A mockup can define common positioning of elements-components and components themselves. According to this methodology, the developer only needs to perform steps to compose page of blocks-components, adjust each component according to requirements and integrate required specific parameters. Each component already has functionality and representation (handoff, storybook) and supplementary development is unnecessary. Operation 320 can also include one or more sub-processes for development of a code layer for communicating with the backend. In addition, Operation 320 can include one or more sub-processes for debugging and testing (i.e., creating unit tests, end-to-end tests, etc.).
At operation 325, Frontend microservice delivery is performed. Operation 325 can include integration and frontend microservice delivery to an end user, as described below.
As shown in
FMD system 400 can include a container as a controller representing the application utilizing a set of web components. As shown in
System 600 comprises one or more container(s) that function as controller 615 comprising a component/rout store of application 610. The route store 615 acts as an upper layer of one or more web component(s) configured to organize the flow and operation of other web components, i.e., routes 620. Routes 620 are web components that can be provided having an organization implemented by controller 615. Route array 620 comprises one or more routes, providing a library for page navigation (routes) in applications, e.g. web applications. Each route 620 is another view that the web application 610 can render (e.g., current route 622) or hide as requested, for example, by user navigation. Application 610 can include specific representations having an internal physical structure. Therefore, application 610 itself represents web components, i.e., routes 620, that are configured to control other web components.
Route store 615 is configured to connect, for example via an API, REST-Store layer 630 and function as an upper layer of one or more web component(s) configured to organize the flow and operation of other web components. REST layer 630 can be configured to connect to a microservice backend application 640 and an Application Packaging Standard (APS) bus 645. REST layer 630 can be configured to perform a data request and retrieve data to microservice backend application 640 and Application Packaging Standard (APS) bus 645.
This environment is prepared with a supplementary framework (FW) layer. The FW comprises everything required for a new application in an isolated of stack form. A same, singular FW can be used for the creation of unit tests, additionally.
New application integration can further include creation of a compiled bundle file to be dynamically downloaded to a platform host. File downloading to a platform host is also optimized. Said file is prepared as set of asynchronous web components which can be downloaded part-by-part at time of opening new page-representation of application. At the same time, final bundle file comprises no code of primary vendor-libraries. This code is downloaded into a host from FW directly. In some embodiments, a final bundle file comprises specific business layer code only providing minimal bundle file size. Such process organization provides optimal and effective platform host deployment.
Usage of web components provides new layer of isolated applications from old applications and from platform host. In such a manner new applications do not influence on old applications; they exist in parallel with optimal platform host load. A debugging process can be performed via the use of specific real-time means, such as Vue Devtools. After the microservice frontend is generated, a developer is enabled to obtain a workable draft for future application development, that determines application structure, patterns and principles of development, unit tests with the use of framework. A microservice application can have a rigid structure composed of at least:
For example, a microservice application in development can specify the following parts:
In runtime, a layer can be provided for performing communication with a microservice backend. Specifically, a REST-Store layer can be provided as a software and technology layer of the application that provides interaction with the application backend. REST-Store layer can perform interactions and provide structure of the components itself.
The REST-Store layer can be implemented in different environments. Local development mode uses emulated transport level as for development as for further unit tests (plug). Transport level is a REST (Representational State Transfer) service responsible for execution of REST methods like GET, POST and others. At production (runtime), a physical transport level can be utilized. Therefore, the developer can use the same code for various stages without the necessity of doing it in different modes in different ways. Such vertical provides higher speed and accuracy for frontend-backend connection of the application (microservice) making it in the most effective way.
After that, it describes all the data for the operation of the MOCK system, the ability to fully develop locally without connecting to the network at all (Internet, corporate). This layer simulates connection to the backend allowing local development.
To ensure the quality of the code, it is necessary to cover it with tests. Tests can be divided into several groups based on subject (i.e., test object, case, etc.):
For mock types use the same mock system as for local development. Also, there is a section for testing at the framework level, which has everything to prepare environments for tests, The environment provides all its features, methods and approaches. In addition, there are helper methods for testing some specific basic components, various utility methods.
If necessary, it is possible to debug the application using the dev-tools standard for the view, which greatly facilitates and speeds up this process itself. In runtime (platform host), the dev-tools works in a limited mode, this is due to the architecture of deployment and operation of the finished application in this environment.
For the local development process, a system of prompts has been created for working with the mock system: when accessing the backup for data for which there is no mock yet, no error occurs, but instead a debug message is issued in the console about which rest method and which rest service and with which parameters it was launched, after which you can it is easy to create mock data for a specific rest method and continue development with a full simulation of work in real conditions. Embodiments described herein improve transparency, linearity and clarity of the development process. For each stage, all specific development cases have been worked out.
All this allows the engineer to focus only on creating the business logic of the application core, without distraction to secondary activities in the form of creating components, architectural design of the entire application as a whole and its individual layers, for example, a layer for communicating with the back. All this has already been solved systematically, and all that remains is only to use it. In such a manner of application development, bugs are localized in specific technological layers and there is easy to find them fast and fix according to their nature. Therefore, the process of development goes highly effective.
Various embodiments may be implemented, for example, using one or more computer systems, such as computer system 700 shown in
Computer system 700 may include one or more processors (also called central processing units, or CPUs), such as a processor 704. Processor 704 may be connected to a communication infrastructure or bus 706.
Computer system 700 may also include user input/output device(s) 708, such as monitors, keyboards, pointing devices, etc., which may communicate with communication infrastructure 706 through user input/output interface(s) 702.
One or more of processors 704 may be a graphics processing unit (GPU). In some embodiments, a GPU may be a processor that is a specialized electronic circuit designed to process mathematically intensive applications. The GPU may have a parallel structure that is efficient for parallel processing of large blocks of data, such as mathematically intensive data common to computer graphics applications, images, videos, etc.
Computer system 700 may also include a main or primary memory 708, such as random access memory (RAM). Main memory 708 may include one or more levels of cache. Main memory 708 may have stored therein control logic (i.e., computer software) and/or data.
Computer system 700 may also include one or more secondary storage devices or memory 710. Secondary memory 710 may include, for example, a hard disk drive 712 and/or a removable storage device or drive 714. Removable storage drive 714 may be a floppy disk drive, a magnetic tape drive, a compact disk drive, an optical storage device, tape backup device, and/or any other storage device/drive.
Removable storage drive 714 may interact with a removable storage unit 718. Removable storage unit 718 may include a computer usable or readable storage device having stored thereon computer software (control logic) and/or data. Removable storage unit 718 may be a floppy disk, magnetic tape, compact disk, DVD, optical storage disk, and/any other computer data storage device. Removable storage drive 714 may read from and/or write to removable storage unit 718.
Secondary memory 710 may include other means, devices, components, instrumentalities or other approaches for allowing computer programs and/or other instructions and/or data to be accessed by computer system 700. Such means, devices, components, instrumentalities or other approaches may include, for example, a removable storage unit 722 and an interface 720. Examples of the removable storage unit 722 and the interface 720 may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM or PROM) and associated socket, a memory stick and USB port, a memory card and associated memory card slot, and/or any other removable storage unit and associated interface.
Computer system 700 may further include a communication or network interface 724. Communication interface 724 may enable computer system 700 to communicate and interact with any combination of external devices, external networks, external entities, etc. (individually and collectively referenced by reference number 728). For example, communication interface 724 may allow computer system 700 to communicate with external or remote devices 728 over communications path 726, which may be wired and/or wireless (or a combination thereof), and which may include any combination of LANs, WANs, the Internet, etc. Control logic and/or data may be transmitted to and from computer system 700 via communication path 726.
Computer system 700 may also be any of a personal digital assistant (PDA), desktop workstation, laptop or notebook computer, netbook, tablet, smart phone, smart watch or other wearable, appliance, part of the Internet-of-Things, and/or embedded system, to name a few non-limiting examples, or any combination thereof.
Computer system 700 may be a client or server, accessing or hosting any applications and/or data through any delivery paradigm, including but not limited to remote or distributed cloud computing solutions; local or on-premises software (“on-premise” cloud-based solutions); “as a service” models (e.g., content as a service (CaaS), digital content as a service (DCaaS), software as a service (SaaS), managed software as a service (MSaaS), platform as a service (PaaS), desktop as a service (DaaS), framework as a service (FaaS), backend as a service (BaaS), mobile backend as a service (MBaaS), infrastructure as a service (IaaS), etc.); and/or a hybrid model including any combination of the foregoing examples or other services or delivery paradigms.
Any applicable data structures, file formats, and schemas in computer system 700 may be derived from standards including but not limited to JavaScript Object Notation (JSON), Extensible Markup Language (XML), Yet Another Markup Language (YAML), Extensible Hypertext Markup Language (XHTML), Wireless Markup Language (WML), MessagePack, XML User Interface Language (XUL), or any other functionally similar representations alone or in combination. Alternatively, proprietary data structures, formats or schemas may be used, either exclusively or in combination with known or open standards.
In some embodiments, a tangible, non-transitory apparatus or article of manufacture comprising a tangible, non-transitory computer useable or readable medium having control logic (software) stored thereon may also be referred to herein as a computer program product or program storage device. This includes, but is not limited to, computer system 700, main memory 708, secondary memory 710, and removable storage units 718 and 722, as well as tangible articles of manufacture embodying any combination of the foregoing. Such control logic, when executed by one or more data processing devices (such as computer system 700), may cause such data processing devices to operate as described herein.
It should be understood that the operations shown in the exemplary methods are not exhaustive and that other operations can be performed as well before, after, or between any of the illustrated operations. In some embodiments of the present disclosure, the operations can be performed in a different order and/or vary.
It is to be appreciated that the Detailed Description section, and not the Summary and Abstract sections, is intended to be used to interpret the claims. The Summary and Abstract sections may set forth one or more but not all exemplary embodiments of the present invention as contemplated by the inventor(s), and thus, are not intended to limit the present invention and the appended claims in any way.
The present invention has been described above with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined so long as the specified functions and relationships thereof are appropriately performed.
The foregoing description of the specific embodiments will so fully reveal the general nature of the invention that others can, by applying knowledge within the skill of the art, readily modify and/or adapt for various applications such specific embodiments, without undue experimentation, without departing from the general concept of the present invention. Therefore, such adaptations and modifications are intended to be within the meaning and range of equivalents of the disclosed embodiments, based on the teaching and guidance presented herein. It is to be understood that the phraseology or terminology herein is for the purpose of description and not of limitation, such that the terminology or phraseology of the present specification is to be interpreted by the skilled artisan in light of the teachings and guidance.
The breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments but should be defined only in accordance with the following claims and their equivalents.
The present application is a continuation in part (CIP) of U.S. patent application Ser. No. 17/824,563, filed May 25, 2022, entitled SYSTEMS AND METHODS FOR INDEPENDENT APPLICATION DESIGN AND DEPLOYMENT TO PLATFORM HOST, the disclosure of which is hereby incorporated by reference herein.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 17824563 | May 2022 | US |
| Child | 18089082 | US |
