Desktop-to-cloud application migration

Abstract

The present disclosure provides systems or techniques for facilitating desktop-to-cloud application migration. In various embodiments, a system may access a desktop application. In various aspects, a system may deploy a desktop application in a cloud computing environment based on generating a nested model-view-renderer software architecture that takes the desktop application as an external data model. In various instances, the cloud computing environment may include a server device and a client device, where the server device may hosting a portion of an external renderer and the desktop application, and where the client device may hosting another portion of the external renderer and an external view. In various cases, the external view may include an internal view, an internal renderer, and a reduced version of the desktop application.

Description

Background Art

[0001] Scientific instruments are often associated with computer programs. Typically, such computer programs take the form of traditional desktop applications. It may be desirable to migrate such traditional desktop applications to a cloud computing environment. Summary of the Invention

[0002] The following summary is presented to provide a basic understanding of one or more embodiments. This summary is not intended to identify key or critical elements, or to delineate any scope of a particular embodiment or any scope of the claims. Its sole purpose is to present concepts in a simplified form as a prelude to the more detailed description that is presented later. In one or more embodiments described herein, devices, systems, computer-implemented methods, apparatus, or computer program products that facilitate desktop-to-cloud application migration are described.

[0003] According to one or more embodiments, a system is provided. The system may include a non-transitory computer-readable memory that may store a computer-executable component. The system may also include a processor that may be operably coupled to the non-transitory computer-readable memory and may execute the computer-executable component stored in the non-transitory computer-readable memory. In various embodiments, the computer-executable component may include an access component that may access a desktop application. In various aspects, the computer-executable component may include a cloud component that may deploy the desktop application in a cloud computing environment based on generating a nested model-view-renderer software architecture that uses the desktop application as an external data model.

[0004] According to one or more embodiments, a computer-implemented method is provided. In various embodiments, the computer-implemented method may include accessing a desktop application by a device operatively coupled to a processor. In various aspects, the computer-implemented method may include deploying the desktop application in a cloud computing environment by the device based on generating a nested model-view-renderer software architecture that uses the desktop application as an external data model.

[0005] According to one or more embodiments, a computer program product for facilitating desktop to cloud application migration is provided. In various embodiments, the computer program product may include a non-transitory computer-readable memory having program instructions contained therein. In various aspects, the program instructions are executable by a processor to enable the processor to access a computer program. In various cases, the program instructions may be executed to enable the processor to identify a tree hierarchy of the computer program via code compilation or syntactic parsing facilitated by one or more first preprocessor instructions. In various cases, the program instructions may be executed to enable the processor to deploy the computer program in a nested model-view-renderer software architecture, which is derived from the tree hierarchy via code introspection and data type association facilitated by one or more second preprocessor instructions. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Various embodiments will be readily understood by the following detailed description in conjunction with the accompanying drawings. For ease of description, like reference numerals denote like structural elements. The drawings illustrate embodiments by way of example and not by way of limitation. These drawings are not necessarily drawn to scale.

[0007] Figure 1 An example non-limiting block diagram of a scientific instrument module is illustrated in accordance with various embodiments described herein.

[0008] Figure 2 An example non-limiting flow chart illustrating a computer-implemented method according to various embodiments described herein.

[0009] Figure 3 Illustrated is a block diagram of an example non-limiting system that facilitates desktop to cloud application migration according to one or more embodiments described herein.

[0010] Figure 4 Illustrated is a block diagram of an example non-limiting system including a nested model-view-renderer architecture that facilitates desktop to cloud application migration according to one or more embodiments described herein.

[0011] Figure 5 Illustrated is an example non-limiting block diagram showing a nested Model-View-Renderer architecture according to one or more embodiments described herein.

[0012] Figure 6 Illustrated is an example non-limiting block diagram showing how a nested model-view-renderer architecture may be distributed in or across a cloud computing environment, according to one or more embodiments described herein.

[0013] Figure 7Illustrated is an example non-limiting communication diagram showing how a nested model-view-renderer architecture may operate according to one or more embodiments described herein.

[0014] Figures 8 to 10 A flow diagram illustrating an example non-limiting computer-implemented method of facilitating desktop-to-cloud application migration according to one or more embodiments described herein.

[0015] Figures 11 to 15 An example non-limiting block diagram showing how to generate a nested model-view-renderer architecture is illustrated according to one or more embodiments described herein.

[0016] Figure 16 Illustrated is an example non-limiting block diagram of a graphical user interface that may be used to perform some or all of the methods or techniques disclosed herein, according to various embodiments described herein.

[0017] Figure 17 Illustrated is an example non-limiting block diagram of a computing device that can perform some or all of the methods or techniques disclosed herein, according to various embodiments described herein.

[0018] Figure 18 Illustrated is an example, non-limiting block diagram of a scientific instrument support system in which some or all of the methods or techniques disclosed herein may be performed, according to various embodiments described herein.

[0019] Figure 19 A block diagram illustrating an example non-limiting operating environment in which one or more embodiments described herein may be facilitated.

[0020] Figure 20 An example networking environment is illustrated that is operable to perform various implementations described herein. DETAILED DESCRIPTION

[0021] The following detailed description is illustrative only and is not intended to limit the embodiments and / or the application or uses of the embodiments. In addition, there is no intention to be bound by any express or implied information presented in the previous background or summary or detailed description sections.

[0022] One or more embodiments will now be described with reference to the accompanying drawings, wherein like reference numerals are used throughout to refer to like elements. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a more thorough understanding of one or more embodiments. However, it will be apparent that in various circumstances, one or more embodiments may be practiced without these specific details.

[0023] The various operations can be described as a plurality of discrete actions or operations in a manner that is most helpful for understanding the subject matter disclosed herein. However, the described order should not be interpreted as implying that these operations must rely on the order. Specifically, these operations can be performed in an order different from the order presented. The described operations can be performed in an order different from the described embodiment. Various additional operations can be performed, or the described operations can be omitted in additional embodiments.

[0024] Although some elements may be referred to in the singular (e.g., "processing device"), any appropriate element may be represented by multiple instances of that element, and vice versa. For example, a set of operations described as being performed by a processing device may be implemented with different ones of those operations being performed by different processing devices. As used herein, the phrase "based on" should be understood to mean "based, at least in part, on" unless otherwise specified.

[0025] A scientific instrument (e.g., a mass spectrometer, an electron microscope) can be any suitable computerized device that can capture or generate electronic measurements (e.g., can capture or generate spectral images or component spectra) in a scientific, laboratory, research, or clinical operating context. To facilitate the capture or generation of such electronic measurements, a scientific instrument can utilize a complex arrangement of actuatable components (e.g., ion sources, ion lenses, heaters, coolers, fluid valves, fluid pumps, circuit switches, sample stages, apertures), sensors (e.g., ion detectors, voltmeters, thermistors, potentiometers, manometers), or consumables (e.g., carrier fluids, calibrants, filters).

[0026] Scientific instruments are often associated with computer programs. For example, sophisticated computer programs may be created to facilitate the operation of a scientific instrument or its component parts, sensors, or consumables, or to otherwise analyze or post-process electronic measurements captured or generated by the scientific instrument. Typically, such computer programs take the form of traditional desktop applications (e.g., computer programs that may be outdated but are still in use, and that are encoded or configured for local or in-building deployment).

[0027] For various reasons, it may be desirable to migrate such traditional desktop applications to a cloud computing environment. In fact, cloud deployment can be viewed as providing greater flexibility or scalability than local or desktop deployment. For example, before being migrated to a cloud environment, a traditional desktop application can only be accessed or utilized in an in-building manner. However, after being migrated to a cloud environment, the traditional desktop application can alternatively be accessed or utilized even outside the building. As another example, assume that there are multiple separate buildings where it is desired to implement traditional desktop applications. In such a case, if not migrated to a cloud environment, the same instantiation or version of the traditional desktop application would have to be separately or independently deployed at each of those multiple buildings. In such a case, ensuring that all of those identical instantiations or versions of the traditional desktop application remain consistent with each other may become difficult or otherwise become labor-intensive (e.g., if any one of those instantiations or versions is edited or changed, the same edit or change must then be made to the rest of those instantiations or versions to maintain consistency). In contrast, after being migrated to a cloud environment, a single, centralized instantiation or version of a traditional desktop application can be maintained in the cloud environment and can be accessed from any of the multiple separate buildings. Thus, concerns about the consistency of the instantiation or version can be reduced (e.g., if an edit or change is made to the single, centralized instantiation or version, the edit or change can be assumed to be automatically propagated to all of the multiple separate buildings without having to be executed multiple times subsequently).

[0028] Unfortunately, as recognized by the inventors of the various embodiments described herein, existing techniques for migrating traditional desktop applications to cloud computing environments suffer from various shortcomings.

[0029] Specifically, the inventors have recognized that existing technologies suffer from degraded performance due to electronic communication latency. Specifically, when migrated to a cloud computing environment, traditional desktop applications can be hosted on a server device in the cloud computing environment and can be remotely accessed by client devices in the cloud computing environment. As the inventors have recognized, existing technologies require that each time a user of a client device desires to interact with a traditional desktop application, the client device electronically communicates with the server device. That is, each time a user desires to do anything with the traditional desktop application, the user provides input to the client device, the client device requests a response to such input from the server device, and the server device provides such a response back to the client device. Depending on the strength or fidelity of the network connection between the client device and the server device, each such round-trip electronic communication round can take several seconds to complete, and each time a user desires to interact with the traditional desktop application in any way, a different round-trip communication round may be required. In other words, the total communication time between the client device and the server device can easily accumulate excessively, which can be undesirable and can negatively impact the user's cloud computing experience.

[0030] In addition, the inventors have also recognized that existing technologies encounter software development difficulties. In the field of cloud computing and information technology, client or front-end software development is generally considered to be completely separate or different from server or back-end software development. In fact, server or back-end software development is generally focused on writing or debugging the underlying, substantial code for any given desktop application (e.g., decoding the underlying algorithms, machine learning models or functions that a given desktop application will be primarily responsible for executing). In contrast, client or front-end software development is alternatively generally focused on writing or debugging the non-substantial handover code for a given desktop application (e.g., decoding a graphical user interface tool that will be visually presented to a user of a client device and will enable the user to selectively interact with or call the underlying algorithms, machine learning models or functions of a given desktop application). Different decoding languages ​​(e.g., C++ in the back-end) are generally used to facilitate such different ends of software development; Hypertext Markup Language (HTML) or different communication protocols (e.g., sockets, Hypertext Transfer Protocol (HTTP) requests). Therefore, a software developer or engineer who is creating or editing a desktop application in the back-end may lack knowledge, experience or expertise about the front-end. Software developers or engineers may therefore spend valuable time or effort trying to compensate for such lack of front-end knowledge, experience, or expertise, which may slow down, distract, or otherwise negatively impact their writing or debugging of desktop applications.

[0031] Therefore, systems or techniques that can ameliorate one or more of these technical problems may be desirable.

[0032] The various embodiments described herein may solve one or more of these technical problems. One or more embodiments described herein may include a system, a computer-implemented method, an apparatus, or a computer program product that can facilitate improved desktop-to-cloud application migration. Specifically, the various embodiments described herein may involve deploying or migrating desktop applications to a cloud computing environment by automatically generating a nested model-view-presenter (MVP) software architecture based on a desktop application. Recall that the MVP architecture can be viewed as including a data model, a view, and a presenter, wherein the data model can be any code portion that handles underlying or substantial calculations, wherein the view can be any code portion that receives input from a human user and presents output to the human user (e.g., via a graphical user interface), and wherein the presenter can be a code portion that acts as an intermediary between the view and the data model (e.g., the presenter can determine how to update or adjust the data model based on the user input received by the view, and the presenter can determine how the view should format or present the output calculated by the data model). As described herein, the nested MVP software architecture can include an external MVP and an internal MVP. In various cases, the external MVP can include an external view and an external presenter, and the desktop application can be used as or otherwise viewed as a data model for the external MVP. In addition, the internal MVP may include an internal view and an internal renderer, and a reduced or pruned desktop application may be considered or otherwise used as a data model for the internal MVP. In addition, the internal MVP may be considered equivalent to or otherwise contained within the external view of the external MVP. In various aspects, a portion of the external renderer and the desktop application may be hosted on or by a server device in a cloud computing environment, while the remainder of the external renderer and the external view may alternatively be hosted on or by a client device in a cloud computing environment. As described herein, given a desktop application, a nested MVP software architecture may be automatically generated by performing various operations (such as code compilation, syntax parsing, code introspection, or data type matching / association) on the desktop application via preprocessor instructions. Specifically, there may be a repository of prewritten code lines or modules that respectively perform various common rendering or viewing functions or sub-functions; and by selecting any one of those prewritten code lines or modules that corresponds to or matches the data type of the code portion read, parsed, or introspected in the desktop application, various external renderers, internal views, internal renderers, and reduced or pruned desktop applications may be automatically constructed.

[0033] In various cases, this type of nested software architecture may overcome or otherwise reduce various shortcomings or problems encountered with the prior art.

[0034] Indeed, as described above, existing technologies can suffer from excessive communication delays because these techniques require an electronic communication round from the client to the server and back to the client each time a user desires to interact with the desktop application in any way. In stark contrast, the nested MVP architecture described herein can avoid or reduce such excessive communication delays. Specifically, each time a user desires to interact with a desktop application in some manner, a determination can be made as to whether a streamlined or pruned desktop application is capable of adequately handling or otherwise facilitating such interaction. If so, an internal MVP can be invoked to respond to the user. If not, an external MVP can be invoked to respond to the user. Because the internal MVP can be fully hosted on the client device, the case where the internal MVP is invoked to respond to the user can lack client-server communication. In this way, the nested MVP architecture can be viewed as reducing the total number of electronic communication rounds from the client to the server and back to the client (e.g., such communication rounds can be used only when all or the entire desktop application is needed to handle the user's interaction); such communication rounds can be eliminated or avoided when a streamlined or pruned desktop application is sufficient to handle the user's interaction.

[0035] In addition, as described above, existing technologies may pose software development difficulties. In practice, back-end or server-side engineers or technicians may be responsible for writing or debugging desktop applications. However, when implementing existing technologies, back-end or server-side engineers or technicians may waste valuable time trying to familiarize themselves with the front-end or client syntax or protocols. In sharp contrast, when implementing the various embodiments described herein, various automatic operations (such as code compilation, syntax parsing, code introspection, and data type matching or association) can be utilized to automatically generate views and renderers for the nested MVP software architecture. Therefore, back-end or server-side engineers or technicians can focus on properly writing or debugging desktop applications and do not need to waste any time trying to learn how to decode client-side user interface elements (for example, the scripts for the views and renderers of the nested MVP software architecture can be automatically populated with any pre-written common code lines or modules that match the data types introspected from the desktop application, and therefore back-end or server-side engineers or technicians do not need to spend any time trying to learn client syntax or protocols).

[0036] Thus, the various embodiments described herein may be viewed as facilitating improved desktop-to-cloud application migration.

[0037] The various embodiments described herein may be viewed as computerized tools (e.g., any suitable combination of computer-executable hardware or computer-executable software) that can facilitate improved desktop-to-cloud application migration. In various aspects, such computerized tools may include an access component or a cloud component.

[0038] In various embodiments, there may be a scientific instrument. In various aspects, a scientific instrument can be any suitable computerized device that can electronically capture, measure, or otherwise record any suitable electronic information carrying clinical or laboratory significance (e.g., a mass spectrometer, an electron microscope). In any case, there may be a desktop application associated with a scientific instrument. In various cases, a desktop application can be any suitable computer program written in any suitable decoding syntax or decoding language and belonging to a scientific instrument in a substantial manner (e.g., any suitable algorithm for analyzing or otherwise manipulating any electronic information measured by a scientific instrument can be included; any suitable algorithm for modeling or otherwise predicting the behavior or performance of a scientific instrument can be included). In some cases, a desktop application can be considered as a legacy application (e.g., although outdated or aging, it is still in use).

[0039] In various aspects, a cloud computing environment can exist. In various cases, a cloud computing environment can include a server device and a client device that are physically remote from each other but can communicate with each other electronically (e.g., via the Internet or other wireless network connections). In various cases, the client device can be any suitable computing device that can be operated by a user (e.g., a desktop computer, a laptop computer, a smartphone). In various aspects, a server device can be any suitable computing device that can provide any suitable computing or computing services to or on behalf of a client device.

[0040] In various situations, it may be desirable to deploy a desktop application on a cloud computing environment, or otherwise migrate a desktop application to a cloud computing environment. Such deployment or migration can be accomplished by the computerized tools described herein.

[0041] In various embodiments, an access component of a computerized tool can electronically access a desktop application. For example, the access component can receive, retrieve, or otherwise obtain the desktop application from any suitable centralized or decentralized data structure (e.g., a graph data structure, a relational data structure, a hybrid data structure), such that the access component can be viewed as a channel through which other components of the computerized tool can electronically interact with (e.g., read, write, edit, copy, manipulate) the desktop application. Furthermore, in various aspects, the access component can electronically access a cloud computing environment. For example, the access component can communicate with (e.g., transmit data to or from) a server device or a client device, such that the access component can be viewed as a channel through which other components of the computerized tool can electronically interact with (e.g., command, activate, deactivate, affect, change) the cloud computing environment.

[0042] In various embodiments, a cloud component of the computerized tool can electronically migrate the desktop application to the cloud computing environment via generation of a nested MVP architecture. In other words, the cloud component can electronically create a nested MVP architecture based on the desktop application, and the cloud component can electronically deploy the desktop application on the cloud computing environment according to or otherwise using the nested MVP architecture.

[0043] In various aspects, a nested MVP architecture can include an outer MVP architecture and an inner MVP architecture. In various cases, as its name implies, the outer MVP architecture can include an outer data model, an outer renderer, and an outer view. Similarly, as its name implies, the inner MVP architecture can include an inner data model, an inner renderer, and an inner view. In various cases, the outer view can be considered equivalent to or otherwise encompass the inner MVP architecture. Therefore, because the inner MVP architecture can be considered to be within or inside the outer MVP architecture, the terms "inner," "outer," and "nested" are used.

[0044] In various aspects, the external data model can be the desktop application itself. In contrast, the internal data model can be a streamlined, pruned, or otherwise compressed version of the desktop application. In various cases, the internal data model can include or contain metadata about the desktop application (e.g., can indicate or specify how many or what types of underlying algorithms the desktop application has). In various cases, the internal data model can exclude or lack the underlying algorithms of the desktop application, but still be able to save, store, maintain, explore, or post-process any resulting data generated or output by those underlying algorithms (e.g., such resulting data can be post-processed using Fourier transforms, trend line calculations, or hypothesis testing). In various aspects, the internal data model can include a compact, compressed, or simpler version of the underlying algorithms of the desktop application, such that the internal data model can calculate the resulting data more quickly but less accurately than the desktop application itself.

[0045] In various cases, an internal view can be any suitable script or line of computer code that can facilitate receiving input or selections provided by a user; and visual or auditory reproduction or display of any data generated or provided by the internal data model. In various cases, an internal renderer can be any suitable script or line of computer code that can functionally coordinate the internal view and the internal data model. As non-limiting examples, the internal view can forward user-provided inputs to the internal renderer; the internal renderer can extract resulting data responsive to those user-provided inputs from the internal data model; and the internal renderer can instruct the internal view to present or display the resulting data in any suitable format.

[0046] In various respects, as described above, the external view can be considered equivalent to the internal MVP architecture (e.g., equivalent to the entirety of the internal view, internal renderer, and internal data model). In various cases, the external renderer can be any suitable script or line of computer code that can functionally mediate between the external view (e.g., the internal MVP architecture) and the desktop application. As a non-limiting example, in some cases as described herein, the external view (e.g., the internal MVP architecture) can forward user-provided input (e.g., received by the internal view) to the external renderer; the external renderer can extract the resulting data responsive to those user-provided inputs from the desktop application itself; and the external renderer can provide the resulting data back to the external view (e.g., back to the internal MVP architecture for ultimate rendering or display by the internal view).

[0047] More specifically, in various aspects, the internal renderer can include one or more lines of code that determine whether the internal data model can adequately or appropriately process or respond to any user-provided input or selection received by the internal view.

[0048] As a non-limiting example, assume that the internal data model lacks the underlying algorithms of a desktop application, such that the internal data model can store or explore the resulting data generated by the desktop application, but cannot itself compute or generate such resulting data. In such a case, the internal renderer can determine whether the input or selection provided by the user requests the computation or generation of new resulting data not yet stored in the internal data model, or alternatively requests the exploration of resulting data already stored in the internal data model. If the input or selection provided by the user requests the computation or generation of new resulting data not yet stored in the internal data model, the internal renderer can infer that the internal data model cannot adequately or appropriately process or respond to those user-provided inputs or selections. In contrast, if the input or selection provided by the user requests the exploration or manipulation of resulting data already stored in the internal data model, the internal renderer can alternatively infer that the internal data model can adequately or appropriately process or respond to those user-provided inputs or selections.

[0049] As another non-limiting example, assume that the internal data model contains a simpler or compressed version of the underlying algorithm of the desktop application, so that the internal data model can calculate or generate resulting data more quickly but less accurately than the desktop application. In such a case, the internal renderer can determine whether the input or selection provided by the user requests the calculation or generation of resulting data using a level of precision greater than a threshold, or alternatively requests the calculation or generation of resulting data using a level of precision less than a threshold. If the input or selection provided by the user requests the calculation or generation of resulting data using a level of precision exceeding the threshold, the internal renderer can infer that the internal data model cannot adequately or appropriately process or respond to those user-provided inputs or selections. In contrast, if the input or selection provided by the user requests the calculation or generation of resulting data using a level of precision less than the threshold, the internal renderer can alternatively infer that the internal data model can adequately or appropriately process or respond to those user-provided inputs or selections.

[0050] In any case, if the internal renderer infers or determines that the user-provided input or selection can be adequately or appropriately processed by the internal data model, the internal renderer can accordingly extract any data responsive to those user-provided input or selection from the internal data model. On the other hand, if the internal renderer infers or determines that the user-provided input or selection cannot be adequately or appropriately processed by the internal data model, the internal renderer can accordingly forward those user-provided input or selection to the external renderer, and the external renderer can accordingly extract any data from the desktop application responsive to those user-provided input or selection

[0051] In various aspects, cloud components may be distributed or assigned a nested MVP architecture on a cloud computing environment as follows. In various cases, the desktop application may be hosted on a server device or otherwise executed on a server device. In contrast, the external view (e.g., the internal MVP architecture) may alternatively be hosted on a client device or otherwise executed on a client device. In various cases, the client device may compile the external view (e.g., the internal MVP architecture) using WebAssembly or any other suitable compilation platform. In some aspects, the external renderer may be hosted on a server device or otherwise executed on a server device. However, in other aspects, the external renderer may alternatively be divided into two separate parts (e.g., two different but related scripts), one part of which may be hosted on a server device or executed on a server device, and the other part may be hosted on a client device or otherwise executed on a client device. In such cases, the two separate parts may be viewed as encapsulating any communication or network protocol that allows or enables electronic communication between a client device and a server device in order to synchronize client-to-server or server-to-client data transfers.

[0052] In various aspects, distributing or allocating a nested MVP architecture across a cloud computing environment as described herein may reduce the accumulation of client-server communication delays compared to existing techniques.

[0053] In practice, it is assumed that the user of the client device desires to interact with the desktop application in some manner. Thus, the user may provide a given input (e.g., via any suitable human-machine interface of the client device, such as a keyboard, keypad, or touch screen) to the internal view. In various aspects, the internal view may forward the given input to the internal renderer. Because both the internal renderer and the internal view may be hosted by the client device, such forwarding may not involve data transmission between the client device and the server device. In various cases, the internal renderer may determine whether the internal data model (e.g., a streamlined version of the desktop application) is capable of processing or responding to the given input.

[0054] Assume that the internal renderer infers that the internal data model can process or respond to the given input (e.g., the given input requests exploration or manipulation of result data already stored in the internal data model; or the given input requests computation or generation of result data according to a level of accuracy that the internal data model is capable of satisfying). In such cases, the internal renderer may extract from the internal data model any result data that is responsive to the given input or otherwise requested by the given input (e.g., if the given input requests identification, exploration, or manipulation of existing data already stored in the internal data model, the internal renderer may instruct or command the internal data model to identify, explore, or manipulate such existing data as requested, the internal data model may do so, and the internal data model may return the result to the internal renderer; if the given input requests computation of new data that can be provided by the internal data model, the internal renderer may instruct or command the internal data model to compute such new data as requested, the internal data model may do so, and the internal data model may return the result to the internal renderer). In various aspects, the internal renderer can then determine how the resulting data should be formatted visually or audibly, and the internal renderer can instruct or command the internal view to reproduce, play, or display the resulting data according to the determined visual or audible format. Note that because the internal view, internal renderer, and internal data model can all be hosted on the client device, such a scenario may not involve data transmission between the client device and the server device.

[0055] Now, assume instead that the internal renderer infers that the internal data model cannot process or respond to a given input (e.g., the given input requests computation of resulting data above a threshold level of accuracy, where the resulting data is not already stored in the internal data model, and where the internal data model cannot satisfy the threshold level of accuracy). In such a case, the internal renderer may forward the given input to the external renderer. Because the internal renderer may be hosted on a client device, and because at least a portion of the external renderer may be hosted on a server device, such forwarding may involve data transfer between the client device and the server device. In various aspects, the external renderer may extract from the desktop application any resulting data responsive to or otherwise requested by the given input (e.g., the external renderer may instruct or command the desktop application to compute any data requested by the given input, the desktop application may do so, and, regardless of the result, the desktop application may return to the external renderer). In various aspects, the external renderer may forward the resulting data to the internal renderer. In various cases, the internal renderer can then determine how the resulting data should be formatted visually or audibly, and the internal renderer can instruct or command the internal view to reproduce, play, or display the resulting data according to the determined visual or audible format. In some cases, the internal renderer can also transfer the resulting data to an internal data model for storage or future exploration.

[0056] Therefore, as described herein, the nested MVP architecture can be considered to involve client-server communication only when the internal data model is unable to fully or appropriately process or respond to a given input provided by the user. Therefore, when the nested MVP architecture is implemented, the total number of client-to-server and back-to-client communication rounds can be reduced compared to existing technologies. In other words, the specific implementation of the nested MVP architecture can improve the problem of excessive communication delays encountered by existing technologies.

[0057] In various embodiments, the cloud component of the computerized tool can electronically generate or create a nested MVP architecture by utilizing various automated operations (such as code compilation, syntax parsing, code introspection, or data type matching), any of which can be driven by preprocessor instructions.

[0058] Specifically, the cloud component may execute one or more first preprocessor instructions, wherein these one or more first preprocessor instructions may cause the cloud component to perform code compilation or syntax parsing on the desktop application. In various aspects, such compilation or parsing may generate a tree hierarchy that represents or indicates a hierarchical structure of the desktop application. More specifically, the tree hierarchy may be a directed graph, the nodes of which (e.g., root nodes, composite nodes, leaf nodes) represent functionally different blocks, fragments, modules, or lines of code within the desktop application (e.g., different blocks, fragments, modules, or lines of code may define specific variables or parameters used by the desktop application, may define specific algorithms used by the desktop application, may define specific loops or parts of the algorithms of the desktop application), and the edges of the directed graph represent which of those different blocks, fragments, modules, or lines of code contain, in turn, which other blocks, fragments, modules, or lines of code in those different blocks, fragments, modules, or lines of code depend on. In some cases, the tree hierarchy can be viewed as indicating the organization and content of the entire or overall script of the desktop application (e.g., indicating where each different block, snippet, module, or line of code is located in the desktop application's script; what each different block, snippet, module, or line of code in the desktop application's script does; and which different blocks, snippets, modules, or lines of code in the desktop application's script depend on each other).

[0059] In various aspects, the cloud component may store, maintain, or otherwise access multiple code repositories that correspond to different components of the nested MVP architecture, wherein each of those code repositories may contain common, pre-written rendering or viewing logic organized by data type. In various cases, by introspecting the data types of different blocks, fragments, modules, or lines of code indicated in the tree hierarchy, and by identifying any common, pre-written rendering or viewing logic in the code repository that corresponds to a data type that matches the data type of the tree hierarchy, the cloud component may automatically populate the scripts of the various components of the nested MVP architecture. In various cases, such automatic population may generate a nested MVP architecture.

[0060] As a non-limiting example, multiple code repositories may include an internal view code repository. The internal view code repository can be viewed as a list, set, or collection of prewritten code logic that performs common view-related functions. In various cases, the list, set, or collection of prewritten code logic can be collated by data type. That is, each prewritten code logic in the internal view code repository can be viewed as mapped or otherwise linked to a corresponding data type. In various aspects, the cloud component can perform code introspection on the tree hierarchy of the desktop application, and such introspection can reveal the corresponding data type of each node in the tree hierarchy. Therefore, for each given node in the tree hierarchy, the cloud component can identify prewritten code logic in the internal view code repository that is mapped or linked to any data type represented by the given node. In some cases, more than one prewritten code logic in the internal view repository can be mapped or linked to the data type of a given node. In such cases, any one of those more than one prewritten code logic can be selected randomly or otherwise according to any suitable priority order. In any case, the cloud component can identify the corresponding prewritten code logic from the internal view code repository for each node in the tree hierarchy. The pre-written code logic identified in this way can be considered to collectively form their own hierarchy, which can be considered a hierarchy of scripts for the internal view. In this way, by leveraging code introspection and data type matching / association with respect to the internal view code repository, the cloud component can automatically construct the internal view.

[0061] As another non-limiting example, multiple code repositories may include an internal renderer code repository. Similar to the above, the internal renderer code repository may be viewed as a list, set, or collection of pre-written code logic that performs common renderer-related functions, and the list, set, or collection of pre-written code logic may be organized by data type. As described above, for each given node in the tree hierarchy, the cloud component may identify (via introspection) the data type of the given node, and the cloud component may identify the pre-written code logic in the internal renderer code repository that is mapped or linked to that data type. The pre-written code logic so identified may be viewed as collectively forming their own hierarchical structure, which may be viewed as a hierarchical structure of the scripts of the internal renderer. In this way, by utilizing code introspection and data type matching / association with respect to the internal renderer code repository, the cloud component may automatically construct the internal renderer.

[0062] As yet another non-limiting example, multiple code repositories may include an external renderer code repository. As described above, the external renderer code repository may be viewed as a list, set, or collection of pre-written code logic that performs common renderer-related functions, and the list, set, or collection of pre-written code logic may be organized by data type. As described above, for each given node in the tree hierarchy, the cloud component may identify (via introspection) the data type of the given node, and the cloud component may identify the pre-written code logic in the external renderer code repository that is mapped or linked to the data type. The pre-written code logic so identified may be viewed as collectively forming their own hierarchical structure, which may be viewed as a hierarchical structure of the script of the external renderer. In this way, the cloud component may automatically construct the external renderer by utilizing code introspection and data type matching / association with respect to the external renderer code repository.

[0063] As another non-limiting example, multiple code repositories may include a reduced code repository. Similar to the above, the reduced code repository can be viewed as a list, set, or collection of pre-written code logic that performs any common functionality considered to be associated with a reduced-form desktop application, and the list, set, or collection of pre-written code logic can be checked by data type. As described above, for each given node in the tree hierarchy, the cloud component can identify (via introspection) the data type of the given node, and the cloud component can identify the pre-written code logic in the reduced code repository that is mapped or linked to the data type. Such identified pre-written code logic can be viewed as collectively forming their own hierarchical structure, which can be viewed as a hierarchical structure of the scripts of the reduced-form desktop application. In this way, by utilizing code introspection and data type matching / association with respect to the reduced code repository, the cloud component can automatically construct a reduced-form desktop application. However, this is merely a non-limiting example. In other embodiments, the reduced-form desktop application may not exist. Instead, the hierarchical structure of the reduced-form desktop application can be a reduced or sparse version of the tree hierarchy of the desktop application. In practice, the cloud component may iterate through each node in the tree hierarchy and may decide whether to keep the node in the compact desktop application. In various cases, the desktop application may decide to delete any node whose introspected data type belongs to the substantial underlying algorithm of the desktop application.

[0064] In any case, the cloud component can automatically populate the decoding scripts of the internal view, internal renderer, external renderer, and the streamlined desktop application. Once such decoding scripts are generated via automatic filling, the cloud component can distribute them in the cloud computing environment as described above. That is, the cloud component can transfer the completed decoding scripts of the internal view, internal renderer, and internal data model (e.g., the streamlined desktop application) to the client device for hosting, and the cloud component can transfer the completed decoding script of the external renderer and the script of the desktop application to the server device for hosting. Therefore, by utilizing code compilation, syntax parsing, code introspection, and data type matching, a nested MVP architecture can be automatically created and deployed in a cloud computing environment. Therefore, unlike existing technologies, engineers or technicians on the back end or server side can focus on writing or debugging desktop applications without being distracted by paying attention to the front end or client.

[0065] The various embodiments described herein may be used to solve problems that are highly technical in nature (e.g., to facilitate improved desktop-to-cloud application migration), non-abstract, and not executable by humans as a set of mental activities, using hardware or software. Additionally, some of the processes performed may be performed by specialized computers (e.g., client devices, server devices, preprocessor instructions) configured to perform defined actions associated with cloud computing.

[0066] For example, such defined actions may include: accessing a desktop application by a device operatively coupled to a processor; and deploying the desktop application in a cloud computing environment based on generating a nested model-view-renderer software architecture with the desktop application as an external data model by the device. In various aspects, the device may generate the nested model-view-renderer software architecture by identifying a tree hierarchy of the desktop application by the device and via code compilation or syntactic parsing facilitated by one or more first preprocessor instructions; and synthesizing corresponding portions of the nested model-view-renderer software architecture based on the tree hierarchy by the device and via code introspection and data type association facilitated by one or more second preprocessor instructions. In various cases, the cloud computing environment may include a server device and a client device, wherein the server device may host a portion of the external renderer and the desktop application, and wherein the client device may host another portion of the external renderer and the external view. In various cases, the external view may include an internal view, an internal renderer, and a reduced form of the desktop application.

[0067] Actions defined in this way are inherently computerized. Indeed, desktop applications, MVP architectures, and cloud environments are inherently computerized, hardware-based or software-based constructs that cannot be implemented in any meaningful, appropriate, feasible, or reasonable way by a human mind or a person with a pen and paper. Furthermore, the very act of migrating or deploying a computer program to a cloud environment is inherently computerized and cannot be accomplished in any way without a computer. Discussing cloud computing deployment or cloud migration without reference to computers simply doesn't make sense.

[0068] In addition, the various embodiments described herein can incorporate various teachings related to improved desktop to cloud application migration into practical applications. As described above, the inventors have recognized that when implementing prior art to migrate a given desktop application to the cloud, such prior art requires a complete client-to-server and back-to-client communication round every time a user desires to interact with the desktop application in any way. Unfortunately, this can cause communication delays to accumulate excessively. Also as described above, the inventors have recognized that when implementing prior art to migrate a given desktop application to the cloud, back-end engineers are often distracted by trying to solve or compensate for front-end problems with which they have little or no experience (e.g., client devices often utilize different decoding syntax or network protocols than server devices). Unfortunately, this can waste valuable time and effort of such back-end engineers. For at least these reasons, the prior art can be viewed as suffering from various technical problems.

[0069] The various embodiments described herein may help improve one or more of these technical issues. Specifically, the various embodiments described herein may involve deploying a given desktop application on a cloud computing environment via a nested MVP architecture. As described herein, a nested MVP architecture may be automatically generated by performing various operations (such as code compilation, syntax parsing, code introspection, or data type matching) on ​​a given desktop application. Also as described herein, a nested MVP architecture may include an external MVP and an internal MVP. In various aspects, the external MVP may consist of the desktop application itself, an external renderer, and an external view. In various cases, the external view may be or include an internal MVP, which may consist of an internal view, an internal renderer, and a reduced-profile desktop application. In various cases, at least a portion of the external renderer and the desktop application may be hosted on a server device in the cloud computing environment. In contrast, the external view (and potentially the remainder of the external renderer) may be hosted on a client device in the cloud computing environment. Thus, a user of the client device may provide input or selections to the internal view, which may forward those inputs or selections to the internal renderer, and the internal renderer may determine whether the reduced-profile desktop application is able to satisfactorily process or respond to those inputs or selections. If so, the internal renderer can extract the response data from the compact desktop application and instruct the internal view to display or present the response data to the user. If not, the internal renderer can instead forward those inputs or selections to the external renderer. Thus, the external renderer can extract the response data from the desktop application and pass it back to the internal renderer, which, as described above, can instruct the internal view to display or present the response data to the user. In this way, the client-to-server and back-to-client communication round can only be performed when the compact desktop application is unable to process or respond to the input or selection provided by the user, rather than performing this communication round every time the user provides such input or selection. Therefore, the various embodiments described herein can reduce communication latency compared to existing technologies. Furthermore, because the nested MVP architecture can be automatically generated (e.g., via compilation, parsing, introspection, or data type matching), backend engineers do not need to waste any time or effort worrying about client-side issues (e.g., client syntax, client network protocols) for which they lack experience or expertise. For at least these reasons, the various embodiments described herein can be considered concrete and tangible technical improvements in the field of cloud computing. Therefore, the various embodiments described herein certainly qualify as useful and practical applications of computers.

[0070] Figure 1 An example non-limiting block diagram of a scientific instrument module 102 is illustrated, in accordance with various embodiments described herein.

[0071] In various embodiments, the scientific instrument module 102 may be implemented by circuitry (e.g., including electrical or optical components), such as a programmed computing device. The logical components of the scientific instrument module 102 may be included in a single computing device, or may be distributed across multiple computing devices that communicate with each other, as appropriate. Figure 17 and Figure 19 Examples of computing devices that may implement the scientific instrument module 102, either alone or in combination, are discussed and reference is made to Figure 18 and Figure 20 Examples of systems or networks of interconnected computing devices that may implement the scientific instrument module 102 across one or more of the computing devices are discussed.

[0072] The scientific instrument module 102 may include a first logic component 104 and a second logic component 106. As used herein, the term "logic component" may include a device that performs a set of operations associated with logic. For example, any of the logic elements included in the scientific instrument module 102 may be implemented by one or more computing devices that are programmed with instructions to cause one or more processing devices of the computing devices to perform an associated set of operations. In certain embodiments, the logic elements may include one or more non-transitory computer-readable media having instructions thereon that, when executed by one or more processing devices of the one or more computing devices, cause the one or more computing devices to perform an associated set of operations. As used herein, the term "module" may refer to a collection of one or more logic elements that together perform a function associated with the module. Different logic elements in a module may take the same form or may take different forms. For example, some logic elements in a module may be implemented by a programmed general-purpose processing device, while other logic elements in the module may be implemented by an application-specific integrated circuit (ASIC). As another example, different logic elements in a module may be associated with different instruction sets executed by one or more processing devices. A module may omit one or more of the logic elements shown in the associated figures; for example, when a module is to perform a subset of the operations discussed herein with reference to the module, the module may include a subset of the logic elements depicted in the associated figures.

[0073] In various embodiments, there may be a scientific instrument corresponding to the scientific instrument module 102. In various aspects, the scientific instrument can be any suitable computerized device that can electronically measure some scientifically relevant, clinically relevant or research-related characteristics, properties or attributes of (e.g., a set of known or unknown mixtures, compounds or substances) an analytical sample. As a non-limiting example, the scientific instrument can be a mass spectrometer operatively coupled to a gas chromatograph or a liquid chromatograph. In such cases, the scientific instrument can measure or determine the ion spectrum (e.g., relative ion abundance as a function of mass-to-charge ratio) of the analytical sample. As another non-limiting example, the scientific instrument can be a scanning electron microscope. In such cases, the scientific instrument can measure or determine the surface morphology of the analytical sample. As another non-limiting example, the scientific instrument can be a transmission electron microscope. In such cases, the scientific instrument can measure or determine the internal structure details of the analytical sample. As a more general non-limiting example, the scientific instrument can be a charged particle microscope of any suitable type (e.g., some types of microscopes can use non-electron ion beams to capture images).

[0074] In various embodiments, the first logic component 104 can access a desktop application associated with the scientific instrument. In various aspects, the desktop application can be any suitable computer program that is substantially related to the scientific instrument in any suitable manner. As a non-limiting example, in some cases, the desktop application can be configured or designed to analyze or otherwise process measurements captured by the scientific instrument. As another non-limiting example, in some cases, the desktop application can be configured or designed to predict or forecast the behavior, performance, or degradation of the scientific instrument.

[0075] In various embodiments, based on a nested MVP software architecture, the second logic component 106 can deploy a desktop application to a cloud computing environment. In various aspects, the nested MVP software architecture can include an external MVP and an internal MVP. In various cases, the external MVP can include an external view hosted on a client device in the cloud computing environment, an external renderer hosted on a server device in the cloud computing environment, or on both the client device and the server device, and the desktop application itself hosted on the server device. In various cases, the internal MVP can be equivalent to the external view or otherwise included within the external view. In various aspects, the internal MVP can include an internal view, an internal renderer, and a streamlined desktop application. In various cases, a user of the client device can provide any suitable input to the internal view, and the internal view can forward these inputs to the internal renderer. In various cases, the internal renderer can determine whether the streamlined desktop application can appropriately process or respond to those inputs. If so, the internal renderer can instruct the streamlined desktop application to generate output responsive to the user-provided input, and the internal renderer can accordingly instruct the internal view to display such output to the user. If not, the internal renderer may instead pass the user-supplied input to the external renderer, which may instruct the desktop application to generate output responsive to the input, and the external renderer may pass those outputs to the internal renderer, which may in turn instruct the internal view to display such output to the user. In this way, such nested MVP software may reduce or otherwise improve the accumulation of communication delays by only executing or conducting client-to-server and back-to-client communication rounds for user-supplied input to which the lite version of the desktop application cannot appropriately respond.

[0076] In addition, in some aspects, the second logic component 106 can involve automatically generating a nested MVP software architecture by utilizing preprocessor instructions. Specifically, one or more first preprocessor instructions can be executed, which can cause code compilation or syntax parsing to be performed on the desktop application, thereby generating a tree hierarchy representing the internal structure or organization of the desktop application. Then, one or more second preprocessor instructions can be executed, which can cause scripts corresponding to internal views, internal renderers, streamlined desktop applications, and external renderers to be automatically populated with appropriate prewritten view-related or rendering-related logic mapped to any data type introspected from the tree hierarchy.

[0077] Thus, the scientific instrument module 102 may facilitate improved desktop to cloud application migration.

[0078] Figure 2is an example, non-limiting flowchart of a computer-implemented method 200 according to various embodiments described herein. The operations of the computer-implemented method 200 may be used in any suitable context to perform any suitable operations (e.g., may be performed by a computer program). Figure 1 、 Figure 16 、 Figure 17 、 Figure 18 、 Figure 19 and Figure 20 Any of the various modules, computing devices, or graphical user interfaces described herein may be executed or used in conjunction with them). Figure 2 In the examples, the operations are each illustrated once in a particular order, but the operations may be reordered or repeated as needed and appropriate (eg, different operations may be performed in parallel where appropriate).

[0079] In various aspects, act 202 may include performing a first operation of accessing a desktop application (eg, which may correspond to or otherwise be associated with a scientific instrument). In various circumstances, first logic component 104 may perform or otherwise facilitate act 202 .

[0080] In various cases, act 204 can include performing a second operation of deploying the desktop application in the cloud computing environment based on generating a nested model-view-renderer software architecture with the desktop application as an external data model. In various cases, second logic component 106 can perform or otherwise facilitate act 204.

[0081] Thus, the computer-implemented method 200 may facilitate improved desktop-to-cloud application migration.

[0082] Figure 3 Illustrated is a block diagram of an example non-limiting system 312 that can facilitate desktop to cloud application migration according to one or more embodiments described herein.

[0083] In various embodiments, there may be a scientific instrument 304. In various aspects, the scientific instrument 304 may be as described above. That is, the scientific instrument 304 may be any suitable computerized device that can electronically measure any suitable scientifically relevant, clinically relevant or research-related characteristics, attributes or properties of any suitable analytical sample. As a non-limiting example, the scientific instrument 304 may be a mass spectrometer that can be equipped with or equipped with a gas chromatograph or liquid chromatograph. In such cases, the scientific instrument 304 may utilize its component hardware (e.g., a syringe, an oven heating column, a carrier fluid valve or pump, an ion beam emitter, an ion optical device lens or shield, a mass analyzer) to electronically determine the chemical composition or composition of any given analytical sample. As another non-limiting example, the scientific instrument 304 may be a scanning or transmission electron microscope. In such cases, the scientific instrument 304 can utilize its component hardware (e.g., electron source, anode, focusing lens, focusing aperture, scanning coil, objective lens, objective aperture, deflector, condenser, astigmatism correction device, electron detector, X-ray detector, actuatable sample stage) to electronically determine or map the surface structure or internal structure of any given analytical sample.

[0084] In various embodiments, there may be a desktop application 302. In various aspects, the desktop application 302 may be any suitable computer program written in any suitable coding syntax (eg, C++) and associated with the scientific instrument 304 in any suitable method or manner.

[0085] As a non-limiting example, desktop application 302 may be a computer program configured or designed to process or otherwise analyze any electronic data (e.g., chemical composition spectra, spectral images) measured or recorded by scientific instrument 304. For example, desktop application 302 may include or otherwise incorporate any suitable machine learning algorithm (e.g., a deep learning neural network, a support vector machine, a Bayesian belief network, a fuzzy logic model, a data fusion engine, a decision tree, a random forest model, or any suitable combination or collection thereof) that may be trained (e.g., in a supervised manner, an unsupervised manner, a reinforcement learning manner, a semi-supervised manner) to perform classification on any electronic data measured or recorded by scientific instrument 304 (e.g., to generate a classification label indicating to which of two or more defined categories a given data segment measured by scientific instrument 304 belongs). In another case, the desktop application 302 may include or otherwise incorporate any suitable machine learning algorithm that can be trained to perform segmentation on any electronic data measured or recorded by the scientific instrument 304 (e.g., to generate a segmentation mask that indicates to which of two or more defined categories each respective portion of a given piece of data measured by the scientific instrument 304 belongs). As yet another case, the desktop application 302 may include or otherwise incorporate any suitable machine learning algorithm that can be trained to perform any suitable regression task on any electronic data measured or recorded by the scientific instrument 304 (e.g., to denoise, enhance the resolution of, or otherwise transform a given piece of data measured by the scientific instrument 304).

[0086] As another non-limiting example, the desktop application 302 may be a computer program configured or designed to predict, track, or otherwise forecast any suitable behavior or performance of the scientific instrument 304. For example, the desktop application 302 may include or otherwise include any suitable digital twin of the scientific instrument 304. In various aspects, such a digital twin may be any suitable collection or set of any suitable mathematical or physics-based models that collectively simulate, forecast, or otherwise predict any suitable behavioral details or aspects of the scientific instrument 304. In some cases, the digital twin may include any suitable mass continuity equation, inequality, or formula that pertains in some way to the scientific instrument 304. In other cases, the digital twin may include any suitable energy balance equation, inequality, or formula that pertains in some way to the scientific instrument 304. In even other cases, the digital twin may include any suitable heat transfer equation, inequality, or formula that pertains in some way to the scientific instrument. In yet other cases, the digital twin may include any suitable fluid flow equation, inequality, or formula that pertains in some way to the scientific instrument 304. In still other cases, the digital twin may include any suitable dynamic or kinematic equations, inequalities, or formulas that pertain in some way to scientific instrument 304. In other cases, the digital twin may include any suitable Newtonian or quantum mechanical equations, inequalities, or formulas that pertain in some way to scientific instrument 304. In even other cases, the digital twin may include any suitable corrosion or degradation equations, inequalities, or formulas that pertain in some way to scientific instrument 304.

[0087] In any case, the desktop application 302 may include any appropriate number of any appropriate type of underlying or substantive algorithms that are related in some way to the scientific instrument 304 (e.g., the above-mentioned machine learning algorithms for performing classification, segmentation, or regression on data recorded by the scientific instrument 304; or the above-mentioned digital twin algorithms for predicting or forecasting the behavior of the scientific instrument 304).

[0088] Now, in various aspects, there can be a cloud computing environment 306. In various cases, as shown, the cloud computing environment 306 can include a server device 308 and a client device 310.

[0089] In various cases, client device 310 can be any suitable computing device that can be operated by a user. As a non-limiting example, client device 310 can be a desktop computer. As another non-limiting example, client device 310 can be a laptop computer. As another non-limiting example, client device 310 can be a mobile computing device, such as a smartphone or a smart tablet. As yet another non-limiting example, client device 310 can be a wearable computing device, such as smart glasses or a smart watch. As another non-limiting example, client device 310 can be a vehicle-integrated computing device, such as a dashboard computer. In any case, client device 310 can include any suitable human-machine interface for receiving input from a user or for presenting output to a user. Non-limiting examples of such human-machine interfaces can include: a touch screen; other electronic screen or display; a keyboard, keypad, joystick; a microphone; or a speaker.

[0090] In various aspects, the server device 308 can be any suitable computing device that can be physically remote from the client device 310 but can perform computing services for or on behalf of the client device 310. In various cases, the server device 308 can communicate electronically with the client device 310 (e.g., transmit data to it, receive data from it) via any suitable one or more wireless electronic connections. Non-limiting examples of such wireless electronic connections can include an Internet connection, a local area network (LAN) connection, or a wide area network (WAN) connection. In various cases, whatever electronic connection or communication channel exists between the client device 310 and the server device 308 can be public (e.g., unencrypted) or private (e.g., encrypted). It should be understood that any suitable intermediate computing device (not shown) can be implemented to facilitate a wireless connection or communication channel between the client device 310 and the server device 308, such as a router, a modem, or an Internet access point.

[0091] In any case, system 312 can be electronically integrated (e.g., via any suitable wired or wireless electronic connection) with desktop application 302 and cloud computing environment 306. In various aspects, it may be desirable to deploy desktop application 302 on or migrate to cloud computing environment 306. In various cases, system 312 can facilitate such deployment or migration, as described herein.

[0092] In various aspects, the system 312 can include a processor 314 (e.g., a computer processing unit, a microprocessor) and a non-transitory computer-readable memory 316 operatively or operatively or communicatively connected or coupled to the processor 314. The non-transitory computer-readable memory 316 can store computer-executable instructions that, when executed by the processor 314, can cause the processor 314 or other components of the system 312 (e.g., the access component 318, the cloud component 320) to perform one or more actions. In various embodiments, the non-transitory computer-readable memory 316 can store computer-executable components (e.g., the access component 318, the cloud component 320), and the processor 314 can execute these computer-executable components.

[0093] In various embodiments, system 312 may include an access component 318. In various aspects, access component 318 may electronically access desktop application 302. That is, access component 318 may electronically receive, electronically retrieve, or otherwise electronically obtain desktop application 302 from any suitable electronic source or database (not shown). Thus, access component 318 may be considered an agent or conduit through which other components of system 312 may interact with, execute, or otherwise manipulate desktop application 302. Furthermore, in various instances, access component 318 may electronically access cloud computing environment 306. That is, access component 318 may electronically communicate with or otherwise electronically interact with server device 308 or client device 310 (e.g., transmit electronic instructions or commands to, receive electronic data from). Thus, access component 318 may be considered an agent or conduit through which other components of system 312 may interact with, communicate with, or otherwise manipulate server device 308 or client device 310. However, these are merely non-limiting examples. In other cases, the access component 318 can be omitted, and any other component of the system 312 can communicate or interact directly with the desktop application 302 or the cloud computing environment 306.

[0094] In various embodiments, system 312 can include cloud component 320. In various aspects, cloud component 320 can electronically deploy desktop application 302 onto cloud computing environment 306 based on a nested MVP software architecture, as described herein.

[0095] Figure 4 A block diagram illustrating an example non-limiting system including a nested model-view-renderer architecture that can facilitate desktop-to-cloud application migration according to one or more embodiments described herein is shown. As shown, in some cases, system 312 can include a nested model-view-renderer architecture 402 (hereinafter referred to as "nested MVP architecture 402").

[0096] In various embodiments, the cloud component 320 can electronically generate a nested MVP architecture 402 based on analyzing the desktop application 302, and the cloud component 320 can electronically utilize or exploit the nested MVP architecture 402 to deploy the desktop application 302 in or on the cloud computing environment 306. Figures 5 to 7 Various non-limiting aspects are described.

[0097] Figure 5 An example non-limiting block diagram of a nested MVP architecture 402 is illustrated according to one or more embodiments described herein.

[0098] In various embodiments, the nested MVP architecture 402 can include an external model-view-renderer architecture 502 (hereinafter referred to as the "external MVP architecture 502") and an internal model-view-renderer architecture 508 (hereinafter referred to as the "internal MVP architecture 508"). In various aspects, as shown, the internal MVP architecture 508 can be contained within the external MVP architecture 502, or can be otherwise considered to be internal to the external MVP architecture. Therefore, the term "nested" can be appropriate.

[0099] Recall that the MVP architecture can be thought of as a software coding pattern or prototype for streamlining the development of software interfaces. Specifically, the MVP architecture can be composed of three components: a data model; a view; and a renderer; hence the name "pattern-view-renderer." A data model can be any discrete portion of code that defines or generates the underlying data to be displayed or presented to a user. A view can be any discrete portion of code that actually displays or presents the data so that it can be viewed by a user. A renderer can be a discrete portion of code that acts as an intermediary between the view and the data model. Specifically, the view can forward user commands or inputs to the renderer, the renderer can extract outputs responsive to those user commands or inputs from the data model, and the renderer can instruct the view to display those extracted outputs to the user.

[0100] In view of this, both the external MVP architecture 502 and the internal MVP architecture 508 can be viewed as consisting of corresponding data models, views, and renderers. Specifically, the view of the external MVP architecture 502 can be referred to as the external view 506, the renderer of the external MVP architecture 502 can be referred to as the external renderer 504, and the data model of the external MVP architecture 502 can be viewed as the desktop application 302. In addition, the view of the internal MVP architecture 508 can be referred to as the internal view 514, the renderer of the internal MVP architecture 508 can be referred to as the internal renderer 512, and the data model of the internal MVP architecture 508 can be referred to as the streamlined desktop application 510. In various cases, as shown, the external view 506 can be or otherwise include the internal MVP architecture 508. In other words, in some cases, the external view 506 can be viewed as the collective whole of the internal view 514, the internal renderer 512, and the streamlined desktop application 510.

[0101] Now, as described above, desktop application 302 can be any suitable computer program that can include, contain, or otherwise implement any suitable underlying algorithms that are in some way related to scientific instrument 304. In various aspects, as conveyed by the term "lite," lean desktop application 510 can be a pruned, compressed, compacted, or otherwise computationally smaller version of desktop application 302. In other words, lean desktop application 510 can include fewer lines of code than desktop application 302 (e.g., in some cases, one or more orders of magnitude fewer).

[0102] As a non-limiting example, in some aspects, the streamlined desktop application 510 may exclude or lack one or more of the underlying algorithms of the desktop application 302 (e.g., machine learning models, digital twin formulations). As a result, in such cases, the streamlined desktop application 510 may be unable to compute or generate outputs that the desktop application 302 can compute or generate. However, in such cases, the streamlined desktop application 510 may still include metadata about or pertaining to those underlying algorithms. For example, the streamlined desktop application 510 may indicate or specify how many or what types of underlying algorithms the desktop application 302 has. As another example, the streamlined desktop application 510 may indicate or specify how many or what types of parameters (e.g., weight matrices, convolution kernels, aberration coefficients, Hamiltonian elements) the underlying algorithms of the desktop application 302 have. As another example, the streamlined desktop application 510 may indicate or specify how many or what types of independent variables (e.g., voltage, current, temperature, pressure, chemical spectra, spectral images) the underlying algorithms of the desktop application 302 operate on. As yet another example, the streamlined desktop application 510 may instruct or specify how many or what types of outputs (e.g., classification labels, segmentation masks, regressions, predicted instrument behavior, predicted instrument wear) are to be computed by the underlying algorithms of the desktop application 302. In some cases, the streamlined desktop application 510 may electronically store or otherwise electronically maintain any specific output computed or generated by the underlying algorithms of the desktop application 302, even though the streamlined desktop application 510 may not be able to compute or generate such specific outputs on its own. Furthermore, even though the streamlined desktop application 510 may exclude or lack the underlying algorithms of the desktop application 302, the streamlined desktop application 510 may still include any suitable data exploration or post-processing algorithms (e.g., Fourier transform algorithms, trend line algorithms, hypothesis testing algorithms, histogram calculation algorithms) that may be implemented to explore or post-process any specific outputs stored or maintained in the streamlined desktop application 510.

[0103] As another non-limiting example, in some aspects, rather than excluding or omitting the underlying algorithms of the desktop application 302, the streamlined desktop application 510 may include or incorporate smaller, compressed, or simpler versions of those underlying algorithms. For example, assume that the desktop application 302 includes a deep learning segmenter that is configured to generate segmentation masks for spectral images recorded or measured by the scientific instrument 304. In such a case, the streamlined desktop application 510 may include its own deep learning segmenter that is also configured to generate segmentation masks for spectral images recorded or measured by the scientific instrument 304. However, the deep learning segmenter of the streamlined desktop application 510 may include fewer layers (e.g., in some cases, one or more orders of magnitude fewer) than the deep learning segmenter of the desktop application 302. As another example, assume that desktop application 302 includes a physics-based wear formula that predicts the cumulative wear of scientific instrument 304 based on numerous properties or characteristics of scientific instrument 304 (e.g., the physics-based wear formula may have coefficients representing the size, mass, stiffness, yield strength, thermal conductivity, heat capacity, resistance, and impedance of scientific instrument 304). In such an example, streamlined desktop application 510 may include its own physics-based wear formula that predicts the cumulative wear of scientific instrument 304. However, the physics-based wear formula of streamlined desktop application 510 may be based on fewer properties or characteristics of scientific instrument 304 (e.g., the physics-based wear formula may have coefficients representing only the size, mass, and thermal conductivity of the scientific instrument). In either of these examples, streamlined desktop application 510 may be considered capable of calculating or generating output that may be calculated or generated by desktop application 302, but may facilitate such calculation or generation more quickly and less accurately than desktop application 302.

[0104] Now, as described above, the lean desktop application lean desktop application 510 can be considered a data model for the internal MVP architecture 508, the internal view 514 can be considered a view of the internal MVP architecture 508, and the internal renderer 512 can be considered a renderer of the internal MVP architecture 508. Thus, in various aspects, the internal view 514 can be any suitable script or line of code that can forward user-provided input to the internal renderer 512 and can display to the user any data passed from the internal renderer 512 to the internal view; and the internal renderer 512 can be any suitable script or line of code that can receive user-provided input from the internal view 514, extract data responsive to those user-provided inputs from the lean desktop application 510, and provide that data back to the internal view 514 for display to the user.

[0105] Likewise, as described above, the desktop application 302 can be considered a data model for the external MVP architecture 502, the external view 506 can be considered a view of the external MVP architecture 502, and the external renderer 504 can be considered a renderer of the external MVP architecture 502. Thus, in various aspects, the external renderer 504 can be any suitable script or line of code that can receive user-provided input from the external view 506, extract data responsive to those user-provided inputs from the desktop application 302, and provide that data back to the external view 506 for display to the user.

[0106] Now, as described above, the external view 506 can be considered to include, contain, or otherwise be equivalent to the internal MVP architecture 508, which includes the internal renderer 512. In various aspects, any user-provided input received by the external renderer 504 from the external view 506 can be more finely or more specifically considered to come from the internal renderer 512. Specifically, the internal renderer 512 can include any suitable code lines that, when given any user-provided input from the internal view 514, can determine whether the streamlined desktop application 510 is capable of processing or responding to the given user-provided input. If so, the internal renderer 512 can proceed by interacting with the streamlined desktop application 510. If not, the internal renderer 512 can alternatively proceed by interacting with the external renderer 504.

[0107] As a non-limiting example, assume that the streamlined desktop application 510 omits the underlying algorithms of the desktop application 302 (e.g., in such a case, the streamlined desktop application 510 is able to post-process or explore any data output by the desktop application 302, but the streamlined desktop application 510 itself is not able to output such data). Now, the user can provide a given input to the internal view 514. In various cases, the given input can be any suitable electronic data exhibiting any suitable format, size, or dimension. That is, the given input can be one or more scalars, one or more vectors, one or more matrices, one or more tensors, one or more strings, or any suitable combination thereof. In any case, the given input can be substantially related to the desktop application 302 in some way. For example, in some cases, the given input can request the computation of new data (e.g., new classification labels, new segmentation masks, new regressions, new predicted instrument behavior, new predicted instrument wear accumulation). In other cases, a given input may instead request exploration or post-processing of already computed data (e.g., already computed classification labels, already computed segmentation masks, already computed regressions, already computed predicted instrument behavior, already computed predicted instrument wear accumulation). In various aspects, the internal view 514 can pass or forward the given input to the internal renderer 512, and the internal renderer 512 can evaluate or determine whether the lean desktop application 510 is able to process, respond to, or otherwise satisfy the given input.

[0108] Assume that a given input requests the computation of new data that is not already stored in the streamlined desktop application 510. In such a case, the internal renderer 512 may conclude that the streamlined desktop application 510 is unable to process, respond to, or satisfy the given input. Therefore, the internal renderer 512 may pass or forward the given input to the external renderer 504. Therefore, the external renderer 504 may instruct or command the desktop application 302 to compute or generate any new data requested by the given input, which the desktop application 302 may do, and the external renderer 504 may pass or forward such new data to the internal renderer 512. At this point, the internal renderer 512 may instruct or command the internal view 514 to display or present such new data to the user. In some cases, the internal renderer 512 may also instruct or command the streamlined desktop application 510 to store or retain the new data in case the user wishes to explore or post-process the new data in the future.

[0109] Alternatively, assume that a given input requests exploration or post-processing of prior data already stored in the lean desktop application 510. In such a case, the internal renderer 512 may conclude that the lean desktop application 510 is able to process, respond to, or satisfy the given input. Accordingly, the internal renderer 512 may instruct or command the lean desktop application 510 to explore or post-process the prior data requested by the given input, which the lean desktop application 510 may do, and the internal renderer 512 may instruct or command the internal view 514 to display or present the results of such exploration or post-processing to the user.

[0110] As another non-limiting example, assume that the streamlined desktop application 510 includes a smaller or simpler version of the underlying algorithm of the desktop application 302 (e.g., in such a case, the streamlined desktop application 510 is capable of computing or generating new data faster but less accurately than the desktop application 302). Now, the user can provide specific input to the internal view 514. As above, the specific input can be any suitable electronic data in any suitable format, size, or dimension (e.g., it can be one or more scalars, one or more vectors, one or more matrices, one or more tensors, one or more strings, or any suitable combination thereof). In any case, the specific input can be substantially related to the desktop application 302 in some way. For example, in some cases, the specific input can request a computation using new data with at least a threshold level of accuracy. In other cases, the given input can alternatively: request a computation using new data with less than a threshold level of accuracy; or request exploration or post-processing of already computed data. In various aspects, the internal view 514 can pass or forward the given input to the internal renderer 512, and the internal renderer 512 can evaluate or determine whether the streamlined desktop application 510 is capable of processing, responding to, or otherwise satisfying the given input.

[0111] Assume that a particular input requests the computation of new data using at least a threshold level of accuracy. In such a case, the internal renderer 512 may conclude that the streamlined desktop application 510 is unable to process, respond to, or satisfy the particular input. Therefore, the internal renderer 512 may pass or forward the particular input to the external renderer 504. Thus, the external renderer 504 may instruct or command the desktop application 302 to compute or generate any new data requested by the given input, which the desktop application 302 may do, and the external renderer 504 may pass or forward such new data to the internal renderer 512. At this point, the internal renderer 512 may instruct or command the internal view 514 to display or present such new data to the user. As above, in some cases, the internal renderer 512 may instruct or command the streamlined desktop application 510 to store or retain the new data in case the user desires to explore or post-process the new data in the future.

[0112] Alternatively, assume that a particular input requests the computation of new data below a threshold level of accuracy, or requests the exploration or post-processing of previous data already stored in the lean desktop application 510. In such cases, the internal renderer 512 may conclude that the lean desktop application 510 is capable of processing, responding to, or satisfying the particular input. Accordingly, the internal renderer 512 may instruct or command the lean desktop application 510 to compute, explore, or post-process as requested by the particular input, which the lean desktop application 510 may do, and the internal renderer 512 may instruct or command the internal view 514 to display or present the results of this computation, exploration, or post-processing to the user.

[0113] Figure 6 An example non-limiting block diagram illustrating how a nested MVP architecture 402 may be distributed in or across a cloud computing environment 306 is illustrated according to one or more embodiments described herein.

[0114] In various embodiments, the cloud component 320 can distribute or allocate the nested MVP architecture 402 across the cloud computing environment 306, such as Figure 6 As shown. Specifically, the desktop application 302 can be electronically hosted, electronically executed, electronically run, or otherwise electronically compiled by or on a server device 308. In various aspects, the external view 506, and therefore the internal MVP architecture 508, can alternatively be electronically hosted, electronically executed, electronically run, or otherwise electronically compiled by or on a client device 310. In various cases, the client device 310 can utilize any suitable handoff platform to compile the external view 506, and thereby compile the internal MVP architecture 508. As a non-limiting example, the client device 310 can utilize WebAssembly to compile the external view 506, and thereby compile the internal MVP architecture 508.

[0115] In various cases, as shown, the external renderer 504 can be electronically hosted, executed, run, or otherwise electronically compiled by or on both the server device 308 and the client device 310. More specifically, in various cases, the external renderer 504 can be divided, broken down, or decomposed into two distinct parts: a client synchronizer 602 and a server synchronizer 604. In various aspects, the server synchronizer 604 can be any line of code belonging to the external renderer 504 that is hosted, executed, run, or compiled by the server device 308. In contrast, the client synchronizer 602 can be any line of code belonging to the external renderer 504 that is hosted, executed, run, or compiled by the client device 310. Note that in some cases, this bifurcation of the external renderer 504 into the client synchronizer 602 and the server synchronizer 604 can be viewed as a generalized way to overcome possible or potential mismatches in the default communication protocols between the server device 308 and the client device 310.

[0116] In practice, assume that client device 310 and server device 308 utilize different but known communication protocol standards. In some of these cases, client-side synchronizer 602 may include any suitable code that can convert any known communication protocol used by client device 310 to match or be consistent with any known communication protocol used by server device 308. In other such cases, server-side synchronizer 604 may include any suitable code that can convert any known communication protocol used by server device 308 to match or be consistent with any known communication protocol used by client device 310. In even other of these cases, client-side synchronizer 602 may include any suitable code capable of converting any known communication protocol used by client device 310 into some third communication protocol standard, and server-side synchronizer 604 may include any suitable code capable of converting any known communication protocol used by server device 308 into the same third communication protocol standard. Thus, the fork of external renderer 504 to client synchronizer 602 and server synchronizer 604 may be considered an indication that a known communication protocol mismatch can be accounted for or otherwise corrected for the client, the server, or both.

[0117] However, this is merely a non-limiting example. In other cases, there may not be any mismatch between the known communication protocols of the client device 310 and the server device 308. In such cases, the external renderer 504 may not be forked. Instead, the entirety of the external renderer 504 may be electronically hosted, executed, run, or otherwise electronically compiled, either solely on the server device 308 or solely on the client device 310.

[0118] In any case, distributing or allocating the nested MVP architecture 402 in or across the cloud computing environment 306 in this manner can be viewed as helping to reduce the accumulation of server-client communication delays. Figure 7 Further description.

[0119] Figure 7 An example non-limiting communication diagram illustrating how a nested MVP architecture 402 may operate is illustrated in accordance with one or more embodiments described herein.

[0120] In various aspects, action 702 may involve receiving input (e.g., a scalar, vector, matrix, tensor, string, or any combination thereof) by internal view 514 from a user of client device 310. In various cases, the user may provide such input via any suitable human interface of client device 310, such as a keyboard, keypad, or touch screen.

[0121] In various cases, action 704 may involve passing or forwarding the input by the internal view 514 to the internal renderer 512 .

[0122] In various cases, action 706 can involve determining, by the internal renderer 512, whether the lean desktop application 510 is able to process or respond to the input. As described above, this can be based on whether the input requests: computing new output that cannot be generated by the lean desktop application 510; or exploring or post-processing previous output that has been stored or maintained in the lean desktop application 510. If the internal renderer 512 determines that the lean desktop application 510 is not able to process or respond to the input, the actions encompassed by reference numeral 708 can begin. On the other hand, if the internal renderer 512 instead determines that the lean desktop application 510 is able to process or respond to the input, the actions encompassed by reference numeral 710 can begin.

[0123] First, consider the actions encompassed by numeral 708 .

[0124] In various aspects, action 712 may involve passing or forwarding, by the internal renderer 512 , the input to the external renderer 504 (eg, to the client-side synchronizer 602 , which may commensurately pass or forward the input to the server-side synchronizer 604 ).

[0125] In various cases, action 714 may involve instructing or commanding, by the external renderer 504 , the desktop application 302 to compute, generate, produce, or otherwise return any resulting data requested by the input.

[0126] In various cases, action 716 may involve computing, generating, producing, or otherwise returning the resulting data by the desktop application 302 .

[0127] In various aspects, action 718 may involve passing or forwarding, by the desktop application 302 , the resulting data to the external renderer 504 .

[0128] In various cases, action 720 may involve passing or forwarding, by the external renderer 504 , the resulting data to the internal renderer 512 .

[0129] In some cases, action 722 may involve instructing or commanding the thin desktop application 510 to store or persist the resulting data in case future exploration or post-processing of the resulting data is subsequently desired or requested by the user.

[0130] Now, consider the actions encompassed by reference numeral 710 .

[0131] In various aspects, action 724 may involve instructing or commanding, by the internal renderer 512 , the thin desktop application 510 to compute, generate, produce, or otherwise return any resulting data requested by the input.

[0132] In various cases, action 726 may involve computing, generating, producing, or otherwise returning, by the lean desktop application 510 , the resulting data.

[0133] In various cases, action 728 may involve passing or forwarding, by the lean desktop application 510 , the resulting data to the internal renderer 512 .

[0134] Once the actions encompassed by reference numeral 708 or reference numeral 710 are completed, the internal renderer 512 may be considered to have or possess any resulting data responsive to the input provided by the user.

[0135] In various aspects, act 730 may involve determining how the resulting data should be formatted visually or audibly (eg, visual size, visual font style, visual color, audible volume).

[0136] In various cases, action 732 may involve instructing or commanding, by the internal renderer 512 , the internal view 514 to visually display, audibly play, or otherwise present the resulting data on the client device 310 .

[0137] Note that because the desktop application 302 can be hosted by the server device 308, and because the streamlined desktop application 510 can be hosted by the client device 310, the actions encompassed by reference numeral 708 can involve an electronic communication round between the client device 310 and the server device 308, while the actions encompassed by reference numeral 710 may alternatively not involve such an electronic communication round between the client device 310 and the server device 308. Thus, when implementing the nested MVP architecture 402 as described herein, a client-server communication round can be conducted only for user-provided input that the internal renderer 512 determines cannot be processed or responded to by the streamlined desktop application 510. This can ultimately reduce the total number of client-server communication rounds that occur compared to prior art techniques that require a different client-server communication round for each user-provided input.

[0138] Figures 8 to 10 Flowcharts illustrating example non-limiting computer-implemented methods 800, 900, and 1000 that can facilitate desktop-to-cloud application migration according to one or more embodiments described herein. In various cases, system 312 can facilitate computer-implemented methods 800, 900, and 1000.

[0139] First, consider Figure 8 In various embodiments, action 802 may include deploying a desktop application (e.g., 302) in a cloud environment (e.g., 306) by a device operatively coupled to a processor (e.g., 314) (e.g., via 312) via a nested MVP software architecture (e.g., 402), the nested MVP software architecture treating the desktop application as an external data model (e.g., as a data model of 502). In various aspects, the cloud environment may include a client device (e.g., 310) and a server device (e.g., 308). In various cases, the server device may host a portion (e.g., 604) of an external renderer (e.g., 504) and the desktop application. In various cases, the client device may host another portion (e.g., 602) of the external renderer and an external view (e.g., 506). In various aspects, the external view may include an internal view (e.g., 514), an internal renderer (e.g., 512), and a reduced form of the desktop application (e.g., 510).

[0140] In various cases, action 804 can include accessing, by the internal view, user input associated with the desktop application.

[0141] In various cases, act 806 may include transmitting, by the internal view, the user input to the internal renderer.

[0142] In various aspects, act 808 can include determining, by the internal renderer, whether the compact version of the desktop application is capable of processing or resolving the user input. If not, the computer-implemented method 800 can proceed to act 902 of the computer-implemented method 900. If so, the computer-implemented method 800 can alternatively proceed to act 912 of the computer-implemented method 900.

[0143] Now, consider Figure 9 In various embodiments, act 902 may include transmitting, by the internal renderer, the user input to the external renderer.

[0144] In various aspects, act 904 may include updating, adjusting, or otherwise instructing, by the external renderer, the desktop application based on the user input.

[0145] In various cases, act 906 may include generating, by the desktop application, a result in response to an update, adjustment, or instruction by the external renderer.

[0146] In various cases, act 908 may include transmitting, by the desktop application, the results to the external renderer.

[0147] In various aspects, act 910 may include transmitting, by the external renderer, the results to the internal renderer.In various cases, the computer-implemented method 900 may then proceed to act 1002 of the computer-implemented method 1000.

[0148] In various cases, action 912 may include updating, adjusting, or otherwise directing, by the internal renderer, the compact version of the desktop application based on the user input.

[0149] In various cases, act 914 may include generating, by the thin version of the desktop application, a result in response to an update, adjustment, or instruction of the internal renderer.

[0150] In various cases, act 916 may include transmitting, by the compact version of the desktop application, the results to the internal renderer.In various aspects, the computer-implemented method 900 may then proceed to act 1002 of the computer-implemented method 1000.

[0151] Now, consider Figure 10 In various embodiments, act 1002 may include formatting or otherwise preparing the results for visualization by an internal renderer.

[0152] In various aspects, act 1004 can include instructing the internal view, by the internal renderer, to visually render the formatted or prepared results on an electronic display of the client device.

[0153] In various cases, act 1006 may include visually presenting, by the internal view, the formatted or prepared results on an electronic display of the client device.

[0154] Thus far, much of the discussion has focused on how the nested MVP architecture 402 can be run and distributed in the cloud computing environment 306. Some of the following descriptions may be viewed as explaining how the nested MVP architecture 402 can be generated in the first place. In various aspects, the cloud component 320 can electronically generate the nested MVP architecture 402 by utilizing various automated operations such as code compilation, syntax parsing, code introspection, or data type matching / association. Figures 11 to 15 Various non-limiting details are described.

[0155] Figures 11 to 15 An example non-limiting block diagram showing how to generate a nested MVP architecture 402 is illustrated according to one or more embodiments described herein.

[0156] First, consider Figure 11 . In various aspects, cloud component 320 can apply or perform any suitable code compilation or syntax parsing technique on desktop application 302 in response to any suitable number of preprocessor instructions. In various cases, the application or execution of such compilation or parsing can produce a tree hierarchy 1102. In various cases, tree hierarchy 1102 can convey, indicate, or otherwise represent the internal structure or organization of the decoded script of desktop application 302. Specifically, tree hierarchy 1102 can be a directed graph, the nodes of which indicate different or discrete blocks, sections, or lines of code within the script of desktop application 302, and the edges of which indicate which blocks, sections, or lines of code include, rely on, or depend on each other. Thus, the application or execution of compilation or parsing can be viewed as a form of script reading that can reveal or reveal how the code of desktop application 302 is organized or arranged.

[0157] For example, tree hierarchy 1102 may indicate that desktop application 302 includes: node 1104 that depends on or relies on node 1106 and node 1108; wherein node 1106 depends on or relies on node 1110 and node 1112; and wherein node 1108 depends on or relies on node 1114. In various cases, each node may represent or otherwise correspond to one or more corresponding lines of code within a script of desktop application 302, wherein such one or more corresponding lines of code collectively serve a discrete, cohesive role within the overall or entire functionality of desktop application 302. As a non-limiting example, in some cases, node 1104 may represent a discrete section or loop (e.g., a for loop, an if loop, a while loop) of desktop application 302. In such cases, node 1106 may represent a first algorithm written in the discrete section or loop, and node 1108 may represent a second algorithm written in the discrete section or loop. Furthermore, in such cases, node 1110 may represent a first parameter utilized by the first algorithm represented by node 1106, and node 1112 may represent a second parameter utilized by the first algorithm represented by node 1106. Similarly, node 1114 may represent a third parameter utilized by the second algorithm represented by node 1108. Figure 11 Not explicitly shown, additional nodes may be downstream of node 1110, node 1112, or node 1114 (e.g., such additional downstream nodes may indicate corresponding attributes or characteristics of the first parameter, second parameter, and third parameter represented by node 1110, node 1112, and node 1114, respectively).

[0158] It should be understood that Figure 11 This is merely a non-limiting example of a tree hierarchy 1102. In various aspects, the tree hierarchy 1102 may include any suitable number of nodes of any suitable type arranged in any suitable manner or dependency order.

[0159] Note that in various cases, node 1104 can be viewed as a root node of the tree hierarchy 1102 (e.g., a node without a parent node); nodes 1106-1108 can be viewed as composite nodes of the tree hierarchy 1102 (e.g., as nodes with a parent node and child nodes); and nodes 1110-1114 can be viewed as leaf nodes (e.g., nodes without child nodes).

[0160] In any case, the cloud component 320 can generate a tree hierarchy 1102 by performing code compilation or syntactic parsing on the desktop application 302 (e.g., in C++ or any other suitable coding language), and the tree hierarchy 1102 can represent or indicate the internal organization or arrangement of any components, fragments, modules, blocks, or lines of code that make up the script of the desktop application 302.

[0161] Now, consider Figure 12 . In various aspects, the cloud component 320 can electronically store, electronically maintain, or otherwise electronically access the internal view logic repository 1201. In various cases, the internal view logic repository 1201 can be a list, set, group, or collection of any suitable pre-written logic, where each pre-written logic can be one or more lines of code that perform or facilitate any suitable general-purpose function that is typically, normally, or otherwise frequently associated with an MVP view. In various cases, the internal view logic repository 1201 can be collated by data type. In other words, each pre-written logic in the internal view logic repository 1201 can be considered to be linked, mapped, or otherwise associated with a corresponding data type. In other words, each pre-written logic in the internal view logic repository 1201 can be considered to be appropriately used to view the corresponding data type.

[0162] In various aspects, cloud component 320 can perform code introspection on tree hierarchy 1102. Such introspection can reveal the corresponding data type of each node in tree hierarchy 1102. As a non-limiting example, such introspection can reveal: a first data type represented by node 1104; a second data type represented by node 1106; a third data type represented by node 1108; a fourth data type represented by node 1110; a fifth data type represented by node 1112; and a sixth data type represented by node 1114.

[0163] In various cases, the cloud component 320 can then perform data type matching or association between the tree hierarchy 1102 and the internal view logic repository 1201. In various cases, such matching or association can be facilitated by iterating through the tree hierarchy 1102, and such iteration can incrementally generate the internal view tree hierarchy 1202.

[0164] For example, cloud component 320 may start at node 1104. Due to the above-described introspection, cloud component 320 may be aware of any data type represented by node 1104. In various aspects, cloud component 320 may search the internal view logic repository 1201 for pre-written logic that is linked, mapped, or associated to the same data type. In some cases, cloud component 320 may only identify a single pre-written logic that is linked, mapped, or associated to the same data type. In other cases, cloud component 320 may identify multiple pre-written logics that are linked, mapped, or associated to the same data type, and cloud component 320 may select any one of those multiple pre-written logics based on any suitable selection priority (e.g., may be randomly selected). In any case, cloud component 320 may identify pre-written logic in internal view logic repository 1201 that corresponds to the data type represented by node 1104, and the pre-written logic may be referred to as internal view node 1204.

[0165] Next, cloud component 320 can iterate to node 1106 in tree hierarchy 1102. As above, introspection can make cloud component 320 aware of any data type represented by node 1106, and cloud component 320 can search for pre-written logic that links, maps, or associates to the same data type in internal view logic repository 1201. In various cases, this pre-written logic can be referred to as internal view node 1206.

[0166] Similarly, cloud component 320 can iterate to node 1108 in tree hierarchy 1102. As described above, introspection can make cloud component 320 aware of any data type represented by node 1108, and cloud component 320 can search for pre-written logic that links, maps, or associates to the same data type in internal view logic repository 1201. In various cases, this pre-written logic can be referred to as internal view node 1208.

[0167] Additionally, cloud component 320 can iterate to node 1110 in tree hierarchy 1102. As above, introspection can make cloud component 320 aware of any data type represented by node 1110, and cloud component 320 can search for pre-written logic that links, maps, or associates to the same data type in internal view logic repository 1201. In various cases, this pre-written logic can be referred to as internal view node 1210.

[0168] Additionally, cloud component 320 can iterate to node 1112 in tree hierarchy 1102. As above, introspection can make cloud component 320 aware of any data type represented by node 1112, and cloud component 320 can search for pre-written logic that links, maps, or associates to the same data type in internal view logic repository 1201. In various cases, this pre-written logic can be referred to as internal view node 1212.

[0169] Similarly, cloud component 320 can iterate to node 1114 in tree hierarchy 1102. As above, introspection can make cloud component 320 aware of any data type represented by node 1114, and cloud component 320 can search for pre-written logic that links, maps, or associates to the same data type in internal view logic repository 1201. In various cases, this pre-written logic can be referred to as internal view node 1214.

[0170] In various aspects, internal view nodes 1204 through 1214 can collectively be considered to form an internal view tree hierarchy 1202. Note how internal view tree hierarchy 1202 can be considered to be synchronized with or otherwise have the same dependency structure as tree hierarchy 1102. Such synchronization or symmetry can be considered to be the result of a node-by-node iteration performed by cloud component 320. In various cases, cloud component 320 can perform operations on internal view tree hierarchy 1202 that are the opposite or inverse of code compilation or syntax parsing, which can produce a script for internal view 514. In other words, internal view tree hierarchy 1202 can be considered to indicate the internal organization or structure of the script for internal view 514. In this way, cloud component 320 can automatically generate internal view 514 based on tree hierarchy 1102.

[0171] Now, consider Figure 13 . In various aspects, the cloud component 320 can electronically store, electronically maintain, or otherwise electronically access the internal renderer logic repository 1301. In various cases, the internal renderer logic repository 1301 can be a list, set, group, or collection of any suitable pre-written logic, where each pre-written logic can be one or more lines of code that perform or facilitate any suitable general-purpose functionality typically, normally, or otherwise frequently associated with an MVP renderer. In various cases, the internal renderer logic repository 1301 can be collated by data type. In other words, each pre-written logic in the internal renderer logic repository 1301 can be considered to be linked, mapped, or otherwise associated with a corresponding data type. In other words, each pre-written logic in the internal renderer logic repository 1301 can be considered to be appropriately used to render the corresponding data type.

[0172] As described above, the cloud component 320 can iteratively perform data type matching or association between the tree hierarchy 1102 and the internal renderer logic repository 1301. In various cases, such matching or association can incrementally generate the internal renderer tree hierarchy 1302.

[0173] For example, cloud component 320 can start at node 1104. Due to the introspection described above, cloud component 320 can be aware of any data type represented by node 1104. In various aspects, cloud component 320 can search for pre-written logic that is linked, mapped, or associated to the same data type in internal renderer logic repository 1301. In various cases, this pre-written logic can be referred to as internal renderer node 1304.

[0174] Next, the cloud component 320 can iterate to the node 1106 in the tree hierarchy 1102. As above, introspection can make the cloud component 320 aware of any data type represented by the node 1106, and the cloud component 320 can search the internal renderer logic repository 1301 for pre-written logic that is linked, mapped, or associated to the same data type. In various cases, this pre-written logic can be referred to as the internal renderer node 1306.

[0175] Similarly, cloud component 320 can iterate to node 1108 in tree hierarchy 1102. As described above, introspection can make cloud component 320 aware of any data type represented by node 1108, and cloud component 320 can search for pre-written logic linked, mapped, or associated to the same data type in internal renderer logic repository 1301. In various cases, this pre-written logic can be referred to as internal renderer node 1308.

[0176] Additionally, the cloud component 320 can iterate to the node 1110 in the tree hierarchy 1102. As above, introspection can make the cloud component 320 aware of any data type represented by the node 1110, and the cloud component 320 can search the internal renderer logic repository 1301 for pre-written logic that is linked, mapped, or associated to the same data type. In various cases, this pre-written logic can be referred to as an internal renderer node 1310.

[0177] Additionally, the cloud component 320 can iterate to a node 1112 in the tree hierarchy 1102. As above, introspection can make the cloud component 320 aware of any data type represented by the node 1112, and the cloud component 320 can search the internal renderer logic repository 1301 for pre-written logic that is linked, mapped, or associated to the same data type. In various cases, this pre-written logic can be referred to as an internal renderer node 1312.

[0178] Similarly, cloud component 320 can iterate to node 1114 in tree hierarchy 1102. As above, introspection can make cloud component 320 aware of any data type represented by node 1114, and cloud component 320 can search for pre-written logic linked, mapped, or associated to the same data type in internal renderer logic repository 1301. In various cases, this pre-written logic can be referred to as internal renderer node 1314.

[0179] In various aspects, the internal renderer nodes 1304-1314 can be collectively considered to form an internal renderer tree hierarchy 1302. Note how the internal renderer tree hierarchy 1302 can be considered to be synchronized with or otherwise have the same dependency structure as the tree hierarchy 1102. Such synchronization or symmetry can be considered to be the result of the node-by-node iteration performed by the cloud component 320. In various cases, the cloud component 320 can perform operations on the internal renderer tree hierarchy 1302 that are the opposite or inverse of code compilation or syntactic parsing, which can produce a script for the internal renderer 512. In other words, the internal renderer tree hierarchy 1302 can be considered to indicate the internal organization or structure of the script for the internal renderer 512. In this way, the cloud component 320 can automatically generate the internal renderer 512 based on the tree hierarchy 1102.

[0180] Now, consider Figure 14 . In various aspects, the cloud component 320 can electronically store, electronically maintain, or otherwise electronically access the external renderer logic repository 1401. In various cases, the external renderer logic repository 1401 can be a list, set, group, or collection of any suitable pre-written logic, where each pre-written logic can be one or more lines of code that perform or facilitate any suitable general-purpose functionality that is typically, normally, or otherwise frequently associated with an MVP view. In various cases, the external renderer logic repository 1401 can be collated by data type. In other words, each pre-written logic in the external renderer logic repository 1401 can be considered to be linked, mapped, or otherwise associated with a corresponding data type. In other words, each pre-written logic in the external renderer logic repository 1401 can be considered to be appropriately used to render the corresponding data type.

[0181] As described above, the cloud component 320 can iteratively perform data type matching or association between the tree hierarchy 1102 and the external renderer logic repository 1401. In various cases, such matching or association can incrementally generate the external renderer tree hierarchy 1402.

[0182] For example, the cloud component 320 may start at node 1104. Due to the introspection described above, the cloud component 320 may be aware of any data types represented by the node 1104. In various aspects, the cloud component 320 may search the external renderer logic repository 1401 for pre-written logic that is linked, mapped, or associated to the same data type. In various cases, the pre-written logic may be referred to as the external renderer node 1404.

[0183] Next, the cloud component 320 can iterate to the node 1106 in the tree hierarchy 1102. As above, introspection can make the cloud component 320 aware of any data type represented by the node 1106, and the cloud component 320 can search the external renderer logic repository 1401 for pre-written logic that is linked, mapped, or associated to the same data type. In various cases, this pre-written logic can be referred to as the external renderer node 1406.

[0184] Similarly, the cloud component 320 can iterate to the node 1108 in the tree hierarchy 1102. As described above, introspection can make the cloud component 320 aware of any data type represented by the node 1108, and the cloud component 320 can search the external renderer logic repository 1401 for pre-written logic that is linked, mapped, or associated to the same data type. In various cases, this pre-written logic can be referred to as the external renderer node 1408.

[0185] Additionally, the cloud component 320 can iterate to the node 1110 in the tree hierarchy 1102. As above, introspection can make the cloud component 320 aware of any data type represented by the node 1110, and the cloud component 320 can search the external renderer logic repository 1401 for pre-written logic that is linked, mapped, or associated to the same data type. In various cases, this pre-written logic can be referred to as an external renderer node 1410.

[0186] Additionally, the cloud component 320 can iterate to the node 1112 in the tree hierarchy 1102. As above, introspection can make the cloud component 320 aware of any data type represented by the node 1112, and the cloud component 320 can search the external renderer logic repository 1401 for pre-written logic that is linked, mapped, or associated to the same data type. In various cases, this pre-written logic can be referred to as an external renderer node 1412.

[0187] Similarly, cloud component 320 can iterate to node 1114 in tree hierarchy 1102. As above, introspection can make cloud component 320 aware of any data type represented by node 1114, and cloud component 320 can search for pre-written logic that is linked, mapped, or associated to the same data type in external renderer logic repository 1401. In various cases, this pre-written logic can be referred to as external renderer node 1414.

[0188] In various aspects, the external renderer nodes 1404-1414 are collectively considered to form an external renderer tree hierarchy 1402. Note how the external renderer tree hierarchy 1402 can be considered to be synchronized with or otherwise have the same dependency structure as the tree hierarchy 1102. Such synchronization or symmetry can be considered to be the result of a node-by-node iteration performed by the cloud component 320. In various cases, the cloud component 320 can perform operations on the external renderer tree hierarchy 1402 that are the opposite or inverse of code compilation or syntax parsing, which can produce a script for the external renderer 504. In other words, the external renderer tree hierarchy 1402 can be considered to indicate the internal organization or structure of the script of the external renderer 504. In this way, the cloud component 320 can automatically generate the external renderer 504 based on the tree hierarchy 1102.

[0189] Now, consider Figure 15 . In various aspects, the cloud component 320 can electronically store, electronically maintain, or otherwise electronically access the reduced logic repository 1501. In various cases, the reduced logic repository 1501 can be a list, set, group, or collection of any suitable pre-written logic, where each pre-written logic can be one or more lines of code that perform or facilitate any suitable general-purpose functionality considered to be associated with a reduced form of desktop application. In various cases, the reduced logic repository 1501 can be collated by data type. In other words, each pre-written logic in the reduced logic repository 1501 can be considered to be linked, mapped, or otherwise associated with a corresponding data type. In other words, each pre-written logic in the reduced logic repository 1501 can be considered to be a reduced implementation appropriately for the corresponding data type.

[0190] As described above, the cloud component 320 can iteratively perform data type matching or association between the tree hierarchy 1102 and the reduced logical repository 1501. In various cases, this matching or association can incrementally generate the reduced tree hierarchy 1502.

[0191] For example, cloud component 320 may start at node 1104. Due to the introspection described above, cloud component 320 may be aware of any data types represented by node 1104. In various aspects, cloud component 320 may search reduced logic repository 1501 for pre-written logic that is linked, mapped, or associated to the same data type. In various cases, the pre-written logic may be referred to as reduced node 1504.

[0192] Next, cloud component 320 can iterate to node 1106 in tree hierarchy 1102. As above, introspection can make cloud component 320 aware of any data type represented by node 1106, and cloud component 320 can search reduced logic repository 1501 for pre-written logic that links, maps, or associates to the same data type. In various cases, this pre-written logic can be referred to as reduced node 1506.

[0193] Similarly, cloud component 320 can iterate to node 1108 in tree hierarchy 1102. As described above, introspection can make cloud component 320 aware of any data type represented by node 1108, and cloud component 320 can search reduced logic repository 1501 for pre-written logic that links, maps, or associates to the same data type. In various cases, this pre-written logic can be referred to as reduced node 1508.

[0194] Additionally, cloud component 320 may iterate to node 1110 in tree hierarchy 1102. As above, introspection may allow cloud component 320 to know any data type represented by node 1110, and cloud component 320 may search reduced logic repository 1501 for pre-written logic that links, maps, or associates to the same data type. In various cases, this pre-written logic may be referred to as reduced node 1510.

[0195] Additionally, cloud component 320 may iterate to node 1112 in tree hierarchy 1102. As above, introspection may enable cloud component 320 to learn any data type represented by node 1112, and cloud component 320 may search reduced logic repository 1501 for pre-written logic that links, maps, or associates to the same data type. In various cases, this pre-written logic may be referred to as reduced node 1512.

[0196] Similarly, cloud component 320 can iterate to node 1114 in tree hierarchy 1102. As above, introspection can make cloud component 320 aware of any data type represented by node 1114, and cloud component 320 can search reduced logic repository 1501 for pre-written logic that links, maps, or associates to the same data type. In various cases, this pre-written logic can be referred to as reduced node 1514.

[0197] In various aspects, reduced nodes 1504 through 1514 can collectively be considered to form reduced tree hierarchy 1502. Note how reduced tree hierarchy 1502 can be considered to be synchronized with or otherwise have the same dependency structure as tree hierarchy 1102. Such synchronization or symmetry can be considered a result of the node-by-node iteration performed by cloud component 320. In various cases, cloud component 320 can perform operations on reduced tree hierarchy 1502 that are the opposite or inverse of code compilation or syntactic parsing, which can produce the script for reduced desktop application 510. In other words, reduced tree hierarchy 1502 can be considered to indicate the internal organization or structure of the script for reduced desktop application 510. In this way, cloud component 320 can automatically generate reduced desktop application 510 based on tree hierarchy 1102.

[0198] Note that in various embodiments, the reduced logic repository 1501 can be omitted, and the cloud component 320 can generate the reduced tree hierarchy 1502 by pruning or trimming the tree hierarchy 1102. As a non-limiting example, the reduced tree hierarchy 1502 can initially be empty, and the cloud component 320 can iterate through each node of the tree hierarchy 1102. For each node of the tree hierarchy 1102, the cloud component 320 can decide whether to include a copy of the node in the reduced tree hierarchy 1502 or whether to omit the node from the reduced tree hierarchy 1502. In various cases, the cloud component 320 can make such a decision or determination based on the introspected data type of the node. For example, if the introspected data type of the node indicates that the node belongs to an underlying, substantive, or computationally intensive algorithm of the desktop application 302, the cloud component 320 can omit the node from the reduced tree hierarchy 1502. In contrast, if the introspected data type of the node indicates that the node does not belong to the underlying, substantive, or computationally intensive algorithm of the desktop application 302 , the cloud component 320 can include or insert the node into the reduced tree hierarchy 1502 .

[0199] In any case, by leveraging automated operations such as code compilation, syntax parsing, code introspection, and data type matching (e.g., any of which may be facilitated or initiated by preprocessor directives), the cloud component 320 may automatically generate a nested MVP architecture 402 based on the desktop application 302. In various cases, such automatic generation may be considered beneficial because the desktop application 302, regardless of which engineer is responsible for writing or debugging it, does not need to worry about or be distracted by manually coding or creating the nested MVP architecture 402.

[0200] Although the disclosure herein primarily describes desktop application 302 as belonging to or otherwise associated with scientific instrument 304, this is merely a non-limiting example for ease of illustration and explanation. In various cases, the various embodiments described herein can be extrapolated or applied to any suitable desktop application, even to desktop applications that are not scientific instruments.

[0201] The scientific instrument systems, methods, or techniques disclosed herein may include (e.g., Figure 18 The user local computing device 1820 discussed herein interacts with a human user. These interactions may include providing information to the user (e.g., about scientific instruments such as Figure 18 information about the operation of a scientific instrument such as a scientific instrument 1810, information about samples being analyzed or other tests or measurements being performed by the scientific instrument, information retrieved from a local or remote database, or other information) or provide the user with the option of inputting commands (e.g., controlling a scientific instrument such as Figure 18 In some embodiments, these interactions may be performed via a graphical user interface (GUI) that includes a display device (e.g., a graphical user interface such as a display device (e.g., a graphical user interface such as a display device such as a computer program product) or a display device such as a computer program product. Figure 17 1710) that provides output to and / or prompts the user (e.g., via the herein referenced display device 1710). Figure 17 Input may be provided by one or more input devices, such as a keyboard, mouse, trackpad, or touch screen, included in the other I / O devices 1712 discussed herein. The scientific instrument systems, methods, or techniques disclosed herein may include any GUI suitable for interacting with a user.

[0202] Figure 16 An example graphical user interface 1600 (hereinafter referred to as "GUI 1600") is depicted that can be used to perform some or all of the supporting methods or techniques disclosed herein, according to various embodiments. In various aspects, GUI 1600 can be provided on a scientific instrument support system (e.g., as described herein with reference to Figure 18 The computing device of the scientific instrument support system 1800 discussed herein (e.g., Figure 17 Any suitable electronic display (e.g., the computing device 1700 discussed herein) Figure 17 The display device 1710 discussed herein) and the user or technician may use any suitable input device (e.g., Figure 17The user interface 1602 may interact with the GUI 1600 using any of the other I / O devices 1712 discussed and input technologies (e.g., cursor movement, motion capture, facial recognition, gesture detection, voice recognition, button activation).

[0203] GUI 1600 may include a data display area 1602 , a data analysis area 1604 , a scientific instrument control area 1606 , and a settings area 1608 . Figure 16 The specific number and arrangement of regions depicted are merely exemplary, and any number and arrangement of regions (including any desired features) may be included in other embodiments of GUI 1600.

[0204] The data display area 1602 may display data generated by a scientific instrument (e.g., Figure 18 Data generated by the scientific instrument in question 1810).

[0205] Data analysis area 1604 can display any suitable data analysis results (e.g., the results of analyzing the data illustrated in data display area 1602 or other data). In some embodiments, data display area 1602 and data analysis area 1604 can be combined in GUI 1600 (e.g., including data output from a scientific instrument and some analysis of the data in a common graph or area).

[0206] The scientific instrument control area 1606 may include options that allow a user or technician to control the scientific instrument (e.g., Figure 18 For example, the scientific instrument control area 1606 may include configurable parameters that control the operation of such a scientific instrument (e.g., a configurable parameter that controls voltage or current to the scientific instrument, a configurable parameter that controls the internal temperature of the scientific instrument, or a configurable parameter that controls the flow rate of a fluid to the scientific instrument).

[0207] The settings area 1608 may include options that allow the user or technician to control any features or functions of the GUI 1600 (or other GUIs) or to perform common computational operations with respect to the data display area 1602 and the data analysis area 1604 (e.g., saving data to a storage device (such as a computer system described herein)). Figure 17 The storage device 1704 in question), sending the data to another user, marking the data).

[0208] As described above, the scientific instrument module 102 may be implemented by one or more computing devices. Figure 17is a block diagram of a computing device 1700 that can execute some or all of the scientific instrument support methods or techniques disclosed herein, according to various embodiments. In some embodiments, the scientific instrument module 102 can be implemented by a single instance of the computing device 1700 or multiple instances of the computing device 1700. In addition, as discussed below, the computing device 1700 (or multiple instances of the computing device) that implements the scientific instrument module 102 can be Figure 18 A portion of one or more of a scientific instrument 1810, a user local computing device 1820, a service local computing device 1830, or a remote computing device 1840.

[0209] The computing device 1700 is illustrated as having multiple components, but any one or more of these components may be omitted or duplicated depending on the application and settings. In some embodiments, some or all of the components included in the computing device 1700 may be attached to one or more motherboards and enclosed in a housing (e.g., comprising plastic, metal, or other materials). In some embodiments, some of these components may be constructed onto a single system on a chip (SoC) (e.g., the SoC may include one or more instances of the processing device 1702 and one or more instances of the storage device 1704). Additionally, in various embodiments, the computing device 1700 may omit the processor. Figure 17 One or more of the illustrated components may include interface circuitry (not shown) for coupling to one or more omitted components using any suitable interface (e.g., a universal serial bus (USB) interface, a high-definition multimedia interface (HDMI) interface, a controller area network (CAN) interface, a serial peripheral interface (SPI) interface, an Ethernet interface, a wireless interface, or any other suitable interface). For example, computing device 1700 may omit display device 1710, but may include display device interface circuitry (e.g., a connector and driver circuitry) to which display device 1710 may be coupled.

[0210] Computing device 1700 may include a processing device 1702 (e.g., one or more processing devices). As used herein, the term "processing device" may refer to any device or portion of a device that processes electronic data from a register or memory to convert the electronic data into other electronic data that can be stored in the register or memory. Processing device 1702 may include one or more digital signal processors (DSPs), application-specific integrated circuits (ASICs), central processing units (CPUs), graphics processing units (GPUs), cryptographic processors (specialized processors that execute cryptographic algorithms in hardware), server processors, or any other suitable processing devices.

[0211] The computing device 1700 may include a storage device 1704 (e.g., one or more storage devices). The storage device 1704 may include one or more memory devices, such as random access memory (RAM) (e.g., static RAM (SRAM) devices, magnetic RAM (MRAM) devices, dynamic RAM (DRAM) devices, resistive RAM (RRAM) devices, or conductive bridging RAM (CBRAM) devices), hard drive-based memory devices, solid-state memory devices, networked drives, cloud drives, or any combination of memory devices. In some embodiments, the storage device 1704 may include memory that shares a die with the processing device 1702. In such embodiments, the memory may function as a cache memory and may include, for example, embedded dynamic random access memory (eDRAM) or spin-transfer torque magnetic random access memory (STT-MRAM). In some embodiments, the storage device 1704 may include a non-transitory computer-readable medium having instructions thereon that, when executed by one or more processing devices (e.g., processing device 1702), cause the computing device 1700 to perform any appropriate method or portion of the methods disclosed herein.

[0212] Computing device 1700 may include interface device 1706 (e.g., one or more instances of interface device 1706). Interface device 1706 may include one or more communication chips, connectors, or other hardware and software to manage communications between computing device 1700 and other computing devices. For example, interface device 1706 may include circuitry for managing wireless communications for transferring data to and from computing device 1700. The term "wireless" and its derivatives may be used to describe circuits, devices, systems, methods, techniques, or communications channels that can transmit data through a non-solid medium using modulated electromagnetic radiation. The term does not imply that the associated device does not contain any wires, although in some embodiments, it may not. The circuitry included in the interface device 1706 for managing wireless communications may implement any of a variety of wireless standards or protocols, including, but not limited to, Institute of Electrical and Electronics Engineers (IEEE) standards, including Wi-Fi (IEEE 802.11 series), IEEE 802.16 standards (e.g., IEEE 802.16-2005 amendments), Long Term Evolution (LTE) projects, and any amendments, updates, and / or revisions (e.g., LTE-Advanced projects, Ultra Mobile Broadband (UMB) projects (also known as "3GPP2"). In some embodiments, the circuitry included in the interface device 1706 for managing wireless communications may operate according to Global System for Mobile Communications (GSM), General Packet Radio Service (GPRS), Universal Mobile Telecommunications System (UMTS), High Speed ​​Packet Access (HSPA), Evolved HSPA (E-HSPA), or LTE networks. In some embodiments, the circuitry included in the interface device 1706 for managing wireless communications may operate in accordance with Enhanced Data for GSM Evolution (EDGE), GSM EDGE Radio Access Network (GERAN), Universal Terrestrial Radio Access Network (UTRAN), or Evolved UTRAN (E-UTRAN). In some embodiments, the circuitry included in the interface device 1706 for managing wireless communications may operate in accordance with Code Division Multiple Access (CDMA), Time Division Multiple Access (TDMA), Digital Enhanced Cordless Telecommunications (DECT), Evolution-Data Optimized (EV-DO), and their derivatives, as well as any other wireless protocols designated as 3G, 4G, 5G, and higher. In some embodiments, the interface device 1706 may include one or more antennas (e.g., one or more antenna arrays) to receive and / or transmit wireless communications.

[0213] In some embodiments, interface device 1706 may include a circuit for managing wired communication, such as an electrical communication protocol, an optical communication protocol, or any other suitable communication protocol. For example, interface device 1706 may include a circuit for supporting communication according to Ethernet technology. In some embodiments, interface device 1706 may support both wireless and wired communication, or may support multiple wired communication protocols or multiple wireless communication protocols. For example, a first group of circuits of interface device 1706 may be dedicated to shorter-range wireless communication such as Wi-Fi or Bluetooth, while a second group of circuits of interface device 1706 may be dedicated to longer-range wireless communication such as global positioning system (GPS), EDGE, GPRS, CDMA, WiMAX, LTE, EV-DO, etc. In some embodiments, a first group of circuits of interface device 1706 may be dedicated to wireless communication, while a second group of circuits of interface device 1706 may be dedicated to wired communication.

[0214] Computing device 1700 may include battery / power circuitry 1708. Battery / power circuitry 1708 may include one or more energy storage devices (e.g., batteries or capacitors) or circuitry for coupling components of computing device 1700 to an energy source separate from computing device 1700 (e.g., AC line power).

[0215] Computing device 1700 may include a display device 1710 (e.g., multiple display devices). Display device 1710 may include any visual indicator, such as a heads-up display, a computer monitor, a projector, a touch screen display, a liquid crystal display (LCD), a light-emitting diode display, or a flat panel display.

[0216] The computing device 1700 may include other input / output (I / O) devices 1712. For example, the other I / O devices 1712 may include one or more audio output devices (e.g., speakers, headphones, earbuds, alarms), one or more audio input devices (e.g., microphones or microphone arrays), a positioning device (e.g., a GPS device that communicates with a satellite-based system to receive the location of the computing device 1700), an audio codec, a video codec, a printer, sensors (e.g., thermocouples or other temperature sensors, humidity sensors, pressure sensors, vibration sensors, accelerometers, gyroscopes), an image capture device such as a camera, a keyboard, a cursor control device such as a mouse, stylus, trackball, or touchpad, a barcode reader, a Quick Response (QR) code reader, or a Radio Frequency Identification (RFID) reader.

[0217] The computing device 1700 may have any suitable form factor suitable for its applications and settings, such as a handheld or mobile computing device (e.g., a cell phone, a smartphone, a mobile internet device, a tablet computer, a laptop computer, a netbook computer, an ultrabook computer, a personal digital assistant (PDA), an ultra-mobile personal computer), a desktop computing device, or a server computing device or other networked computing component.

[0218] One or more computing devices implementing any of the scientific instrument modules, methods, or techniques disclosed herein may be part of a scientific instrument support system. Figure 18 is a block diagram of an example scientific instrument support system 1800 in which some or all of the scientific instrument support methods disclosed herein may be performed, according to various embodiments. The scientific instrument modules, methods, or techniques disclosed herein (e.g., scientific instrument module 102, computer-implemented method 200, system 312, computer-implemented methods 800-1000) may be implemented by one or more of a scientific instrument 1810, a user local computing device 1820, a service local computing device 1830, or a remote computing device 1840 of the scientific instrument support system 1800.

[0219] Any of the scientific instrument 1810, the user local computing device 1820, the service local computing device 1830, or the remote computing device 1840 may include any of the implementations of the computing device 1700, and any of the scientific instrument 1810, the user local computing device 1820, the service local computing device 1830, or the remote computing device 1840 may take the form of any appropriate implementation of the implementation of the computing device 1700.

[0220] Scientific instrument 1810, user local computing device 1820, service local computing device 1830, or remote computing device 1840 may each include a processing device 1802, a storage device 1804, and an interface device 1806. Processing device 1802 may take any suitable form, including any form of processing device 1702, and processing devices 1802 included in different devices among scientific instrument 1810, user local computing device 1820, service local computing device 1830, or remote computing device 1840 may take the same form or different forms. Storage device 1804 may take any suitable form, including any form of storage device 1704, and storage devices 1804 included in different devices among scientific instrument 1810, user local computing device 1820, service local computing device 1830, or remote computing device 1840 may take the same form or different forms. The interface device 1806 may take any suitable form, including any form of the interface device 1706, and the interface devices 1806 included in different devices among the scientific instrument 1810, the user local computing device 1820, the service local computing device 1830, or the remote computing device 1840 may take the same form or different forms.

[0221] The scientific instrument 1810, the user local computing device 1820, the service local computing device 1830, and the remote computing device 1840 can communicate with other elements of the scientific instrument support system 1800 via a communication path 1808. The communication path 1808 can communicatively couple an interface device 1806 to different ones of the elements of the scientific instrument support system 1800, as shown, and can be a wired or wireless communication path (e.g., according to any of the communication technologies discussed herein with reference to the interface device 1706). Figure 18 The particular scientific instrument support system 1800 depicted includes communication paths between each pair of devices among the scientific instrument 1810, the user local computing device 1820, the service local computing device 1830, and the remote computing device 1840, but this "fully connected" implementation is merely illustrative, and in various embodiments, various of the communication paths 1808 may not be present. For example, in some embodiments, the service local computing device 1830 may lack a direct communication path 1808 between its interface device 1806 and the interface device 1806 of the scientific instrument 1810, but may instead communicate with the scientific instrument 1810 via the communication paths 1808 between the service local computing device 1830 and the user local computing device 1820, as well as the communication paths 1808 between the user local computing device 1820 and the scientific instrument 1810.

[0222] Scientific instruments 1810 may include any suitable scientific instruments, such as scientific instruments 304 .

[0223] The user-local computing device 1820 can be a computing device local to the user of the scientific instrument 1810 (e.g., according to any of the embodiments of the computing device 1700). In some embodiments, the user-local computing device 1820 can also be local to the scientific instrument 1810, but this is not necessarily the case; for example, the user-local computing device 1820 in the user's home or office can be remote from the scientific instrument 1810 but in communication with the scientific instrument so that the user can use the user-local computing device 1820 to control or access data from the scientific instrument 1810. In some embodiments, the user-local computing device 1820 can be a laptop, smartphone, or tablet device. In some embodiments, the user-local computing device 1820 can be a portable computing device.

[0224] The service-local computing device 1830 can be a computing device local to the entity serving the scientific instrument 1810 (e.g., according to any of the embodiments of the computing device 1700). For example, the service-local computing device 1830 can be a device local to the manufacturer of the scientific instrument 1810 or a third-party service company. In some embodiments, the service-local computing device 1830 can communicate (e.g., via a direct communication path 1808 or via multiple "indirect" communication paths 1808, as discussed above) with the scientific instrument 1810, the user-local computing device 1820, or the remote computing device 1840 to receive data regarding the operation of the scientific instrument 1810, the user-local computing device 1820, or the remote computing device 1840 (e.g., self-test results of the scientific instrument 1810, calibration coefficients used by the scientific instrument 1810, measurements of sensors associated with the scientific instrument 1810). In some embodiments, the service local computing device 1830 can communicate with the scientific instrument 1810, the user local computing device 1820, or the remote computing device 1840 (e.g., via a direct communication path 1808 or via multiple "indirect" communication paths 1808, as discussed above) to transfer data to the scientific instrument 1810, the user local computing device 1820, or the remote computing device 1840 (e.g., to update programming instructions (such as firmware) in the scientific instrument 1810, to initiate execution of a test or calibration sequence in the scientific instrument 1810, to update programming instructions (such as software) in the user local computing device 1820 or the remote computing device 1840). A user of the scientific instrument 1810 can utilize the scientific instrument 1810 or the user local computing device 1820 to communicate with the service local computing device 1830 to report a problem with the scientific instrument 1810 or the user local computing device 1820, to request a technician visit to improve the operation of the scientific instrument 1810, to order consumables or replacement parts associated with the scientific instrument 1810, or for other purposes.

[0225] Remote computing device 1840 can be a computing device remote from scientific instrument 1810 or user local computing device 1820 (e.g., according to any of the embodiments of computing device 1700 discussed herein). In some embodiments, remote computing device 1840 can be included in a data center or other large-scale server environment. In some embodiments, remote computing device 1840 can include a network attached storage device (e.g., as part of storage device 1804). Remote computing device 1840 can store data generated by scientific instrument 1810, perform analysis on data generated by scientific instrument 1810 (e.g., according to programming instructions), facilitate communication between user local computing device 1820 and scientific instrument 1810, or facilitate communication between service local computing device 1830 and scientific instrument 1810.

[0226] In some embodiments, the Figure 18 One or more of the illustrated elements of the scientific instrument support system 1800. Additionally, in some embodiments, Figure 18 Multiple of the various elements of the scientific instrument support system 1800 may be present. For example, the scientific instrument support system 1800 may include multiple user-local computing devices 1820 (e.g., different user-local computing devices 1820 associated with different users or located in different locations). As another example, the scientific instrument support system 1800 may include multiple scientific instruments 1810, all of which communicate with a service local computing device 1830 and / or a remote computing device 1840; in such an embodiment, the service local computing device 1830 may monitor these multiple scientific instruments 1810, and the service local computing device 1830 may cause updates or other information to be "broadcasted" to multiple scientific instruments 1810 simultaneously. The different scientific instruments 1810 in the scientific instrument support system 1800 may be located near each other (e.g., in the same room) or far away from each other (e.g., on different floors of a building, in different buildings, in different cities, etc.). In some embodiments, the scientific instrument 1810 can be connected to an Internet of Things (IoT) stack that allows the scientific instrument 1810 to be directed and controlled through a web-based application, a virtual or augmented reality application, a mobile application, or a desktop application. Any of these applications can be accessed by a user operating a user-local computing device 1820 that communicates with the scientific instrument 1810 through an intermediary remote computing device 1840. In some embodiments, the scientific instrument 1810 can be sold by a manufacturer along with one or more associated user-local computing devices 1820 as part of a local scientific instrument computing unit 1812.

[0227] In some embodiments, the different scientific instruments 1810 included in the scientific instrument support system 1800 may be different types of scientific instruments 1810; for example, one scientific instrument 1810 may be a mass spectrometer, while another scientific instrument 1810 may be a chromatograph or an autosampler. In some such embodiments, the remote computing device 1840 or the user's local computing device 1820 may combine data from the different types of scientific instruments 1810 included in the scientific instrument support system 1800.

[0228] In various cases, the machine learning algorithm or model can be implemented in any suitable manner to facilitate any suitable aspect described herein. To facilitate some of the above-mentioned machine learning aspects of the various embodiments, consider the following discussion of artificial intelligence (AI). The various embodiments described herein can employ artificial intelligence to facilitate the automation of one or more features or functions. These components can employ various AI-based schemes to perform the various embodiments / examples disclosed herein. In order to provide or assist in the numerous determinations described herein (e.g., determining, ascertaining, inferring, computing, predicting, prognosing, estimating, deriving, forecasting, detecting, calculating), the components described herein can examine all or a subset of the data to which they are granted access rights, and can provide a method for inferring or determining the state of a system or environment from a set of observations such as those captured via events or data. For example, determinations can be employed to identify a specific context or action, or a probability distribution of states can be generated. These determinations can be probabilistic; that is, a probability distribution of states of interest is calculated based on a consideration of data and events. Determination can also refer to the techniques employed to compose higher-level events from a collection of events or data.

[0229] Such determination can result in constructing new events or actions from a collection of observed events or stored event data, regardless of whether the events are closely related in time and whether the events and data come from one or several event and data sources. The components disclosed herein can employ various classification (explicitly trained (e.g., via training data) as well as implicitly trained (e.g., via observing behavior, preferences, historical information, receiving external information, etc.)) schemes or systems (e.g., support vector machines, neural networks, expert systems, Bayesian belief networks, fuzzy logic, data fusion engines, etc.) in connection with performing automatic or determined actions related to the claimed subject matter. Thus, the classification scheme or system can be used to automatically learn and perform multiple functions, actions, or determinations.

[0230] The classifier can take the input attribute vector z=(z1,z2,z3,z4,z n) is mapped to the confidence that the input belongs to a certain class, such as f(z) = confidence(class). This classification can use probabilistic or statistical-based analysis (for example, taking into account the utility and cost of the analysis) to determine the action to be automatically performed. Support vector machines (SVM) can be an example of a classifier that can be used. SVM operates by finding a hypersurface in the space of possible inputs, where the hypersurface attempts to separate triggering criteria from non-triggering events. Intuitively, this makes the classification correct for test data that is close to but not the same as the training data. Other directed and non-directed model classification methods include, for example, naive Bayes, Bayesian networks, decision trees, neural networks, fuzzy logic models, or probabilistic classification models that provide different independent patterns, any of which can be used. The classification used in this article also includes statistical regression for developing priority models.

[0231] To provide additional context for the various embodiments described herein, Figure 19 The following discussion is intended to provide a brief, general description of a suitable computing environment 1900 in which various embodiments of the embodiments described herein may be implemented. Although the embodiments have been described above in the general context of computer-executable instructions that may be executed on one or more computers, those skilled in the art will recognize that the embodiments may also be implemented in conjunction with other program modules or as a combination of hardware and software.

[0232] Generally, program modules include routines, programs, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the methods of the present invention can be practiced with other computer system configurations, including single-processor or multi-processor computer systems, minicomputers, mainframe computers, Internet of Things (IoT) devices, distributed computing systems, as well as personal computers, handheld computing devices, microprocessor-based or programmable consumer electronics, etc., each of which is operatively coupled to one or more associated devices.

[0233] The embodiments shown herein can also be practiced in distributed computing environments where certain tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

[0234] Computing devices typically include various media, which may include computer-readable storage media, machine-readable storage media, or communication media, as used herein differently, as shown below. A computer-readable storage medium or machine-readable storage medium can be any available storage medium that can be accessed by a computer, and includes volatile and non-volatile media, removable and non-removable media. By way of example and not limitation, a computer-readable storage medium or machine-readable storage medium can be implemented in conjunction with any method or technology for storing information, such as computer-readable or machine-readable instructions, program modules, structured data, or unstructured data.

[0235] Computer-readable storage media may include, but are not limited to, random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD ROM), digital versatile disc (DVD), Blu-ray disc (BD) or other optical disc storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, solid-state drives or other solid-state storage devices, or other tangible or non-transitory media that can be used to store the desired information. In this regard, the terms "tangible" or "non-transitory" as applied to storage, memory, or computer-readable media herein should be understood as excluding only the propagation of transient signals themselves as a modifier and not as a disclaimer of all standard storage, memory, or computer-readable media that are not merely propagation of transient signals themselves.

[0236] Computer-readable storage media can be accessed by one or more local or remote computing devices, eg, via access requests, queries, or other data retrieval protocols, for various operations regarding the information stored by the media.

[0237] Communication media typically embodies computer-readable instructions, data structures, program modules, or other structured or unstructured data in a data signal (such as a modulated data signal, such as a carrier wave or other transport mechanism), and includes any information delivery or transmission media. The term "modulated data signal" or signal refers to a signal that has one or more of its characteristics set or changed so as to encode information in one or more signals. By way of example, and not limitation, communication media includes wired media (such as a wired network or direct-wired connection) and wireless media (such as acoustic, RF, infrared, and other wireless media).

[0238] Reference again Figure 19, an example environment 1900 for implementing various embodiments of various aspects described herein includes a computer 1902 including a processing unit 1904, a system memory 1906, and a system bus 1908. The system bus 1908 couples system components including, but not limited to, the system memory 1906 to the processing unit 1904. The processing unit 1904 can be any of various commercially available processors. Dual microprocessors and other multi-processor architectures can also be used as the processing unit 1904.

[0239] The system bus 1908 can be any of several types of bus structures and can further be interconnected with a memory bus (with or without a memory controller), a peripheral bus, and a local bus using any of a variety of commercially available bus architectures. The system memory 1906 includes ROM 1910 and RAM 1912. A basic input / output system (BIOS), containing the basic routines that help transfer information between elements within the computer 1902, such as during startup, can be stored in a nonvolatile memory such as ROM, erasable programmable read-only memory (EPROM), or EEPROM. RAM 1912 can also include high-speed RAM, such as static RAM for caching data.

[0240] Computer 1902 also includes an internal hard disk drive (HDD) 1914 (e.g., EIDE, SATA), one or more external storage devices 1916 (e.g., a magnetic floppy disk drive (FDD) 1916, a memory stick or flash drive reader, a memory card reader, etc.), and a drive 1920 (e.g., such as a solid-state drive, an optical drive) that can read from or write to a disk 1922 (such as a CD-ROM disk, a DVD, a BD, etc.). Alternatively, in the case of a solid-state drive, disk 1922 would not be included unless it is separate. Although internal HDD 1914 is illustrated as being located within computer 1902, internal HDD 1914 can also be configured for use externally in a suitable chassis (not illustrated). In addition, although not shown in environment 1900, a solid-state drive (SSD) can be used in addition to or in place of HDD 1914. The HDD 1914, external storage device 1916, and drive 1920 can be connected to the system bus 1908 via an HDD interface 1924, an external storage interface 1926, and a drive interface 1928, respectively. Interface 1924 for an external drive implementation may include at least one or both of Universal Serial Bus (USB) and Institute of Electrical and Electronics Engineers (IEEE) 1394 interface technologies. Other external drive connection technologies are also contemplated by the embodiments described herein.

[0241] The drives and their associated computer-readable storage media provide non-volatile storage of data, data structures, computer-executable instructions, and the like. For computer 1902, the drives and storage media accommodate the storage of any data in a suitable digital format. Although the above description of computer-readable storage media refers to a corresponding type of storage device, those skilled in the art will appreciate that other types of storage media (whether currently existing or developed in the future) that can be read by a computer may also be used in the example operating environment, and further, any such storage media may contain computer-executable instructions for performing the methods described herein.

[0242] A number of program modules may be stored in the drives and RAM 1912, including an operating system 1930, one or more application programs 1932, other program modules 1934, and program data 1936. All or portions of the operating system, application programs, modules, or data may also be cached in RAM 1912. The systems and methods described herein may be implemented using various commercially available operating systems or combinations of operating systems.

[0243] Computer 1902 may optionally include emulation technology. For example, a hypervisor (not shown) or other middleware may emulate the hardware environment for operating system 1930, and the emulated hardware may optionally be different from the hardware of the operating system. Figure 19 1902. In this embodiment, operating system 1930 may comprise one of multiple virtual machines (VMs) hosted at computer 1902. In addition, operating system 1930 may provide a runtime environment, such as a Java runtime environment or a .NET framework, for application 1932. A runtime environment is a consistent execution environment that allows application 1932 to run on any operating system that includes a runtime environment. Similarly, operating system 1930 may support containers, and application 1932 may be in the form of containers, which are lightweight, standalone, executable software packages that include, for example, the application's code, runtime, system tools, system libraries, and settings.

[0244] Furthermore, computer 1902 may be equipped with a security module, such as a Trusted Processing Module (TPM). For example, using a TPM, a boot component hashes the next boot component in time and waits for the hash to match a secure value before loading the next boot component. This process can be performed at any layer in the code execution stack of computer 1902, for example, at the application execution level or the operating system (OS) kernel level, thereby achieving security for code execution at any level.

[0245] A user can enter commands and information into the computer 1902 through one or more wired / wireless input devices (e.g., a keyboard 1938, a touch screen 1940, and a pointing device such as a mouse 1942). Other input devices (not shown) may include a microphone, an infrared (IR) remote control, a radio frequency (RF) remote control, or other remote control, a joystick, a virtual reality controller or headset, a game controller, a stylus, an image input device (e.g., a camera), a gesture sensor input device, a visual movement sensor input device, an emotion or facial detection device, a biometric input device (e.g., a fingerprint or iris scanner), and the like. These and other input devices are typically connected to the processing unit 1904 through an input device interface 1944, which can be coupled to the system bus 1908, but may also be connected through other interfaces such as a parallel port, an IEEE 1394 serial port, a game port, a USB port, an IR port, a memory card ... Interfaces, etc.

[0246] A monitor 1946 or other type of display device may also be connected to the system bus 1908 via an interface, such as a video adapter 1948. In addition to the monitor 1946, computers typically include other peripheral output devices (not shown), such as speakers, printers, and the like.

[0247] Computer 1902 can operate in a networked environment using logical connections to one or more remote computers, such as remote computer 1950, via wired or wireless communications. Remote computer 1950 can be a workstation, server computer, router, personal computer, portable computer, microprocessor-based entertainment device, peer device, or other common network node, and typically includes many or all of the elements described with respect to computer 1902, with only memory / storage device 1952 being illustrated for simplicity. The depicted logical connections include wired / wireless connections to a local area network (LAN) 1954 or a larger network, such as a wide area network (WAN) 1956. Such LAN and WAN networking environments are common in offices and companies and facilitate the establishment of enterprise-wide computer networks, such as intranets, all of which can be connected to a global communication network, such as the Internet.

[0248] When used in a LAN networking environment, the computer 1902 can be connected to the local network 1954 through a wired or wireless communication network interface or adapter 1958. The adapter 1958 can facilitate wired or wireless communication with the LAN 1954, which can also include a wireless access point (AP) provided thereon for communicating with the adapter 1958 in a wireless mode.

[0249] When used in a WAN networking environment, the computer 1902 may include a modem 1960 or may be connected to a communication server on the WAN 1956 via other means for establishing communications over the WAN 1956 (such as over the Internet). The modem 1960 may be connected to the system bus 1908 via the input device interface 1944 and may be internal or external and may be a wired or wireless device. In a networked environment, program modules depicted relative to the computer 1902 or portions thereof may be stored in the remote memory / storage device 1952. It will be appreciated that the network connections shown are exemplary and other means for establishing a communications link between the computers may be used.

[0250] When used in a LAN or WAN networking environment, computer 1902 can access cloud storage systems or other network-based storage systems, such as, but not limited to, network virtual machines that provide one or more aspects of storage or processing of information, in addition to or in lieu of external storage devices 1916 as described above. Typically, a connection between computer 1902 and a cloud storage system can be established over LAN 1954 or WAN 1956, for example, via adapter 1958 or modem 1960, respectively. When computer 1902 is connected to an associated cloud storage system, external storage interface 1926 can manage the storage provided by the cloud storage system with the assistance of adapter 1958 or modem 1960, just as it would other types of external storage. For example, external storage interface 1926 can be configured to provide access to cloud storage sources as if they were physically connected to computer 1902.

[0251] The computer 1902 is operable to communicate with any wireless device or entity that is arranged in a wireless communication manner, such as a printer, a scanner, a desktop or portable computer, a portable data assistant, a communication satellite, any equipment or location associated with a wirelessly detectable tag (e.g., an information kiosk, a newsstand, a store shelf, etc.), and a telephone. This may include Wireless Fidelity (Wi-Fi) and Wireless technology. Therefore, the communication can be a predefined structure like a traditional network or an ad hoc communication between at least two devices.

[0252] Figure 20is a schematic block diagram of an example computing environment 2000 with which the disclosed subject matter can interact. The example computing environment 2000 includes one or more clients 2010. Clients 2010 can be hardware or software (e.g., threads, processes, computing devices). The example computing environment 2000 also includes one or more servers 2030. Servers 2030 can also be hardware or software (e.g., threads, processes, computing devices). For example, servers 2030 can accommodate threads to perform transformations by employing one or more embodiments described herein. One possible communication between clients 2010 and servers 2030 can take the form of data packets suitable for transmission between two or more computer processes. The example computing environment 2000 includes a communication framework 2050 that can be used to facilitate communication between clients 2010 and servers 2030. Clients 2010 are operably connected to one or more client data repositories 2020 that can be used to store information local to the clients 2010. Similarly, servers 2030 are operably connected to one or more server data repositories 2040 that can be used to store information local to the servers 2030.

[0253] Various embodiments can be systems, methods, devices, or computer program products at any possible level of technical detail integration. A computer program product can include a computer-readable storage medium (or medium) having computer-readable program instructions thereon for causing a processor to execute various aspects of the various embodiments. A computer-readable storage medium can be a tangible device that can retain and store instructions for use by an instruction execution device. A computer-readable storage medium can be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media can also include the following: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disk (DVD), a memory stick, a floppy disk, a mechanical encoding device (such as a punched card with instructions recorded on it or a raised structure in a groove), and any suitable combination of the foregoing. Computer-readable storage media as used herein should not be construed as transient signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses transmitted through fiber optic cables), or electrical signals transmitted through wires.

[0254] Computer-readable program instructions as described herein can be downloaded to corresponding computing / processing equipment from a computer-readable storage medium or downloaded to an external computer or external storage device via a network (for example, the Internet, local area network, wide area network or wireless network).The network may include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers or edge servers.Network adapter cards or network interfaces in each computing / processing equipment receive computer-readable program instructions from the network, and forward computer-readable program instructions to be stored in the computer-readable storage medium in the corresponding computing / processing equipment.The computer-readable program instructions for performing the operation of various embodiments can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, configuration data of an integrated circuit, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​(such as, Smalltalk, C++ etc.) and procedural programming languages ​​(such as " C " programming language or similar programming languages). Computer readable program instructions can be executed entirely on the user's computer, partially on the user's computer, as an independent software package, partially on the user's computer, partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or can be connected to an external computer (for example, using an internet service provider via the internet). In some embodiments, the electronic circuit includes, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), and the electronic circuit can be personalized by utilizing the state information of the computer readable program instructions, thereby executing the computer readable program instructions, to perform various aspects.

[0255] Various aspects are described herein with reference to the flowchart illustration or block diagram of the method, device (system) and computer program product according to various embodiments.It should be understood that the combination of each frame in the flowchart illustration or block diagram and the frame in the flowchart illustration or block diagram can be realized by computer-readable program instructions.These computer-readable program instructions can be provided to the processor of a general-purpose computer, a special-purpose computer or other programmable data processing device to produce a machine so that the instruction executed via the processor of a computer or other programmable data processing device creates a component for implementing the function / action specified in one or more frames of a flowchart or block diagram.These computer-readable program instructions can also be stored in a computer-readable storage medium, which can guide a computer, a programmable data processing device or other equipment to run in an ad hoc manner, and the computer-readable storage medium storing instructions includes manufacturing products, which includes instructions for implementing the various aspects of the function / action specified in one or more frames of a flowchart or block diagram.Computer-readable program instructions can also be loaded onto a computer, other programmable data processing devices or other equipment so that a series of operational actions are performed on a computer, other programmable devices or other equipment, thereby producing a computer-implemented process so that the instruction executed on a computer, other programmable devices or other equipment implements the function / action specified in one or more frames of a flowchart or block diagram.

[0256] The flow chart and block diagram in the figure illustrate the architecture, function and operation of the possible specific implementation of the system, method and computer program product according to various embodiments. In this regard, each box in the flow chart or block diagram can represent a module, segment or partial instruction, which contains one or more executable instructions for implementing a specified logical function. In some alternative specific implementations, the function marked in the box may not occur in the order marked in the figure. For example, two blocks shown in succession can actually be performed substantially simultaneously, or sometimes can be performed in the opposite order, depending on the function involved. It should also be noted that each box in the block diagram or flow chart and the combination of boxes in the block diagram or flow chart can be implemented by a dedicated hardware system that performs a specified function or action or performs a combination of dedicated hardware and computer instructions.

[0257] Although subject matter has been described above in the general context of computer-executable instructions of a computer program product running on a computer, those skilled in the art will recognize that the present disclosure may also or may be implemented in combination with other program modules. Typically, a program module includes routines, programs, components, data structures, etc. that perform specific tasks or implement specific abstract data types. In addition, those skilled in the art will recognize that various aspects can be put into practice using other computer system configurations, including single-processor or multi-processor computer systems, small computing devices, mainframe computers, and computers, handheld computing devices (e.g., PDAs, phones), microprocessor-based or programmable consumer or industrial electronics, etc. The illustrated aspects can also be put into practice in a distributed computing environment, where tasks are performed by a remote processing device connected through a communication network. However, some aspects of the present disclosure (if not all aspects) can be put into practice on a stand-alone computer. In a distributed computing environment, program modules can be located in both a local memory storage device and a remote memory storage device.

[0258] The terms "component", "system", "platform", "interface" and the like used in this application may refer to or include computer-related entities or entities related to an operating machine having one or more specific functions. The entities disclosed herein may be hardware, a combination of hardware and software, software, or software in execution. For example, a component may be, but is not limited to, a process, a processor, an object, an executable program, a thread of execution, a program, or a computer running on a processor. As an example, both an application running on a server and the server may be components. One or more components may reside within a process or thread of execution, and a component may be located on a single computer or distributed between two or more computers. As another example, corresponding components may be executed from various computer-readable media having various data structures stored thereon. These components may communicate via local or remote processes, such as according to signals having one or more data packets (for example, data from one component interacts with another component in a local system, a distributed system via signals, or interacts with other systems via a network such as the Internet). As another example, a component may be a device having a specific function provided by a mechanical part operated by an electrical or electronic circuit, which is operated by a software or firmware application executed by a processor. In such cases, the processor may be inside or outside the device and may execute at least a portion of the software or firmware application. As another example, a component can be a device that provides a specific functionality without mechanical parts through electronic components, where the electronic components may include a processor or other means for executing software or firmware that at least partially imparts the functionality of the electronic components. In one aspect, the component can emulate the electronic components via a virtual machine within a cloud computing system, for example.

[0259] In addition, the term "or" is intended to mean an inclusive "or" rather than an exclusive "or". That is, unless specified otherwise, or clear from the context, "X employs A or B" is intended to mean any natural inclusive arrangement. That is, if X employs A; X employs B; or X employs both A and B, then "X employs A or B" is satisfied under any of the foregoing examples. As used herein, the term "and / or" is intended to have the same meaning as "or". In addition, unless specified otherwise, or clear from the context to refer to a singular form, the articles "a" and "an" as used in this specification and the drawings should generally be interpreted to mean "one or more". As used herein, the terms "example" or "exemplary" are used to mean serving as an example, instance, or illustration. For the avoidance of doubt, the subject matter disclosed herein is not limited to such examples. In addition, any aspect or design described herein as "example" or "exemplary" is not necessarily to be construed as preferred or advantageous over other aspects or designs, nor is it meant to exclude equivalent exemplary structures and techniques known to those of ordinary skill in the art.

[0260] The content disclosed herein describes non-limiting examples. For ease of description or explanation, the various parts disclosed herein use the terms "each," "each," or "all" when discussing various examples. The usage of terms such as "each," "each," or "all" is not restrictive. In other words, when the content disclosed herein provides a description of "each," "each," or "all" applicable to a particular object or component, it should be understood that this is only a non-limiting example, and it should also be understood that in various other examples, such a description may be applicable to a description of "each," "each," or "all" less than that particular object or component.

[0261] As used in this specification, the term "processor" may refer to substantially any computational processing unit or device, including but not limited to a single-core processor; a single processor with software multi-threaded execution capability; a multi-core processor; a multi-core processor with software multi-threaded execution capability; a multi-core processor with hardware multi-threading technology; a parallel platform; and a parallel platform with distributed shared memory. In addition, a processor may refer to an integrated circuit, an application-specific integrated circuit (ASIC), a digital signal processor (DSP), a field-programmable gate array (FPGA), a programmable logic controller (PLC), a complex programmable logic device (CPLD), discrete gate or transistor logic components, discrete hardware components, or any combination thereof, designed to perform the functions described herein. Furthermore, the processor may utilize nanoscale architectures, such as (but not limited to) molecular and quantum dot-based transistors, switches, and gates, to optimize space usage or enhance the performance of user equipment. The processor may also be implemented as a combination of computational processing units. In this disclosure, terms such as "repository," "storage device," "data repository," "data storage device," "database," and substantially any other information storage component related to the operation and functionality of the component are used to refer to a "memory component," an entity embodied in "memory," or a component that includes memory. It should be understood that the memory and / or memory components can be volatile memory or non-volatile memory, or can include both volatile memory and non-volatile memory. By way of example and not limitation, non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable ROM (EEPROM), flash memory, or non-volatile random access memory (RAM) (e.g., ferroelectric RAM (FeRAM)). Volatile memory can include RAM, which can, for example, act as external cache memory. By way of example and not limitation, RAM takes many forms, such as synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), direct Rambus RAM (DRRAM), direct Rambus dynamic RAM (DRDRAM), and Rambus dynamic RAM (RDRAM). In addition, the memory components of the systems or computer-implemented methods disclosed herein are intended to include, but are not limited to, these and any other suitable types of memory.

[0262] The foregoing includes only examples of systems and computer-implemented methods. Of course, it is not possible to describe every conceivable combination of components or computer-implemented methods for purposes of describing the present disclosure, but many further combinations and permutations of the present disclosure are possible. Furthermore, with respect to the use of the terms "including," "having," "having," and the like in the detailed description, claims, appendices, and drawings, these terms are intended to be inclusive in a manner similar to the way the term "comprising" is interpreted when used as a transitional word in a claim.

[0263] The descriptions of various embodiments have been presented for purposes of illustration, but are not intended to be exhaustive or limited to the embodiments disclosed herein. Many modifications and variations are apparent without departing from the scope and spirit of the described embodiments. The terminology used herein was chosen to best explain the principles of the embodiments, practical applications, or technical improvements over commercially available technologies, or to enable others of ordinary skill in the art to understand the embodiments disclosed herein.

[0264] Various non-limiting aspects are described in the following examples.

[0265] Embodiment 1: A system may include: a processor that executes computer-executable components stored in a non-transitory computer-readable memory, wherein the computer-executable components include: an access component that is capable of accessing a desktop application; and a cloud component that is capable of deploying the desktop application in a cloud computing environment based on generating a nested model-view-renderer software architecture that uses the desktop application as an external data model.

[0266] Embodiment 2: A system capable of implementing any of the preceding embodiments, wherein the cloud component generates the nested model-view-renderer software architecture by: identifying a tree hierarchy of the desktop application via code compilation or syntactic parsing facilitated by one or more first preprocessor directives; and synthesizing corresponding portions of the nested model-view-renderer software architecture based on the tree hierarchy via code introspection and data type association facilitated by one or more second preprocessor directives.

[0267] Embodiment 3: A system according to any of the preceding embodiments can be implemented, wherein the cloud computing environment can include a server device and a client device, wherein the server device can host a portion of the external renderer and the desktop application, and wherein the client device can host another portion of the external renderer and the external view.

[0268] Embodiment 4: The system according to any preceding embodiment can be implemented, wherein the external view can include an internal view, an internal renderer, and a compact version of the desktop application.

[0269] Embodiment 5: The system of any preceding embodiment can be implemented, wherein the client device can compile the internal view, the internal renderer, and the compact version of the desktop application via WebAssembly.

[0270] Embodiment 6: The system according to any preceding embodiment can be implemented, wherein the compact version of the desktop application can include metadata of the desktop application and resultant data output by the desktop application.

[0271] Embodiment 7: The system according to any of the preceding embodiments can be implemented, wherein the reduced version of the desktop application can exclude the underlying data calculation algorithm of the desktop application.

[0272] Embodiment 8: The system according to any preceding embodiment can be implemented, wherein the compact version of the desktop application can include a data exploration tool of the desktop application.

[0273] In various embodiments, any one or more combinations of Examples 1 to 8 can be implemented.

[0274] Example 9: A computer-implemented method may include accessing a desktop application by a device operatively coupled to a processor; and deploying the desktop application in a cloud computing environment by the device based on generating a nested model-view-renderer software architecture that uses the desktop application as an external data model.

[0275] Embodiment 10: A computer-implemented method capable of implementing any of the preceding embodiments, wherein the device generates the nested model-view-renderer software architecture by: identifying a tree hierarchy of the desktop application by the device via code compilation or syntactic parsing facilitated by one or more first preprocessor instructions; and synthesizing corresponding portions of the nested model-view-renderer software architecture based on the tree hierarchy by the device via code introspection and data type association facilitated by one or more second preprocessor instructions.

[0276] Embodiment 11: A computer-implemented method according to any of the preceding embodiments can be implemented, wherein the cloud computing environment can include a server device and a client device, wherein the server device can host a portion of the external renderer and the desktop application, and wherein the client device can host another portion of the external renderer and the external view.

[0277] Embodiment 12: The computer-implemented method of any preceding embodiment can be implemented, wherein the external view can include an internal view, an internal renderer, and a compact version of the desktop application.

[0278] Embodiment 13: The computer-implemented method of any preceding embodiment can be implemented, wherein the client device can compile the internal view, the internal renderer, and the compact version of the desktop application via WebAssembly.

[0279] Embodiment 14: The computer-implemented method of any preceding embodiment can be implemented, wherein the compact version of the desktop application can include metadata of the desktop application and resulting data output by the desktop application.

[0280] Embodiment 15: The computer-implemented method according to any preceding embodiment can be implemented, wherein the reduced version of the desktop application can exclude the underlying data calculation algorithm of the desktop application.

[0281] Embodiment 16: The computer-implemented method of any preceding embodiment can be implemented, wherein the compact version of the desktop application can include a data exploration tool of the desktop application.

[0282] In various embodiments, any one or more combinations of Examples 9 to 16 can be implemented.

[0283] Embodiment 17: A computer program product for facilitating desktop-to-cloud application migration can include a non-transitory computer-readable memory having program instructions embodied therein. In various aspects, the program instructions are executable by a processor to cause the processor to: access a computer program; identify a tree hierarchy of the computer program via code compilation or syntactic parsing facilitated by one or more first preprocessor instructions; and deploy the computer program in a nested model-view-renderer software architecture derived from the tree hierarchy via code introspection and data type association facilitated by one or more second preprocessor instructions.

[0284] Embodiment 18: A computer program product capable of implementing any of the preceding embodiments, wherein the nested model-view-renderer software architecture comprises: a portion of an external renderer and the computer program hosted by a server device; and the remainder of the external renderer and an external view hosted by a client device, wherein the external view comprises an internal view, an internal renderer, and a simplified form of the computer program.

[0285] Embodiment 19: A computer program product according to any preceding embodiment can be implemented, wherein the client device can compile the remaining portion of the external renderer and the external view in WebAssembly.

[0286] Embodiment 20: A computer program product according to any preceding embodiment can be implemented, wherein the simplified form of the computer program can include metadata of the computer program and resulting data output by the computer program, and wherein the simplified form of the computer program can exclude the underlying data calculation algorithm of the computer program.

[0287] In various embodiments, any one or more combinations of Examples 17 to 20 can be implemented.

[0288] In various embodiments, any one or more combinations of Examples 1 to 20 can be implemented.

Claims

1. A system, comprising: a processor that executes computer-executable components stored in a non-transitory computer-readable memory, wherein the computer-executable components include: an access component that accesses the desktop application; and A cloud component is provided for deploying the desktop application in a cloud computing environment based on generating a nested model-view-renderer software architecture with the desktop application as an external data model.

2. The system of claim 1 , wherein the cloud component generates the nested model-view-renderer software architecture by: identifying a tree hierarchy of the desktop application via code compilation or syntax parsing facilitated by one or more first preprocessor directives; and A corresponding portion of the nested model-view-renderer software architecture is synthesized based on the tree hierarchy via code introspection and data type association facilitated by one or more second preprocessor directives.

3. The system of claim 1 , wherein the cloud computing environment comprises a server device and a client device, wherein the server device hosts a portion of the external renderer and the desktop application, and wherein the client device hosts another portion of the external renderer and the external view. The system of claim 3 , wherein the external view comprises an internal view, an internal renderer, and a compact version of the desktop application. 5 . The system of claim 4 , wherein the client device compiles the internal view, the internal renderer, and the compact version of the desktop application via WebAssembly. 6 . The system of claim 4 , wherein the compact version of the desktop application includes metadata of the desktop application and resultant data output by the desktop application. The system of claim 4 , wherein the reduced version of the desktop application excludes underlying data computing algorithms of the desktop application.

8. The system of claim 4, wherein the compact version of the desktop application comprises a data exploration tool of the desktop application.

9. A computer-implemented method, comprising: accessing a desktop application by a device operatively coupled to the processor; as well as The device deploys the desktop application in a cloud computing environment based on generating a nested model-view-renderer software architecture with the desktop application as an external data model.

10. The computer-implemented method of claim 9, wherein the device generates the nested model-view-renderer software architecture by: identifying, by the device and via code compilation or syntax parsing facilitated by one or more first pre-processor directives, a tree hierarchy of the desktop application; and A corresponding portion of the nested model-view-renderer software architecture is synthesized based on the tree hierarchy by the apparatus and via code introspection and data type association facilitated by one or more second pre-processor directives.

11. The computer-implemented method of claim 9, wherein the cloud computing environment comprises a server device and a client device, wherein the server device hosts a portion of the external renderer and the desktop application, and wherein the client device hosts another portion of the external renderer and the external view. 12 . The computer-implemented method of claim 11 , wherein the external view comprises an internal view, an internal renderer, and a compact version of the desktop application.

13. The computer-implemented method of claim 12, wherein the client device compiles the internal view, the internal renderer, and the compact version of the desktop application via WebAssembly.

14. The computer-implemented method of claim 12, wherein the compact version of the desktop application includes metadata of the desktop application and resulting data output by the desktop application.

15. The computer-implemented method of claim 12, wherein the compact version of the desktop application excludes underlying data computation algorithms of the desktop application.

16. The computer-implemented method of claim 12, wherein the compact version of the desktop application comprises a data exploration tool of the desktop application.

17. A computer program product for facilitating desktop to cloud application migration, the computer program product comprising a non-transitory computer-readable memory having program instructions embodied therein, the program instructions being executable by a processor to cause the processor to: access to computer programs; identifying a tree hierarchy of the computer program via code compilation or syntax parsing facilitated by one or more first preprocessor directives; and The computer program is deployed in a nested model-view-renderer software architecture derived from the tree hierarchy via code introspection and data type association facilitated by one or more second preprocessor directives.

18. The computer program product of claim 17, wherein the nested model-view-renderer software architecture comprises: a portion of an external renderer and said computer program hosted by a server device; as well as The remainder of the external renderer and an external view are hosted by a client device, wherein the external view includes the internal view, the internal renderer, and the computer program in a compact form.

19. The computer program product of claim 18, wherein the client device compiles the remainder of the external renderer and the external view in WebAssembly.

20. The computer program product of claim 18, wherein the reduced form of the computer program includes metadata of the computer program and resultant data output by the computer program, and wherein the reduced form of the computer program excludes underlying data computation algorithms of the computer program.

Images