Improved Web browser engine

Abstract

An improved computing system is arranged for cross-origin network communication on a single computing device. The system includes: a processor; a networking module; and a memory having software instructions that are arranged to: operate local computing server resources on a first local domain; instantiate a relay mechanism having an embedded frame and an invisible window; instantiate a local web server on a second local domain; install a service worker on the invisible window; receive a request for information at the local web server; verify the existence of local computing server resources on the first local domain; communicatively connect the second local domain to the embedded frame; and directly transmit at least one message between the local computing server resources on the first local domain and the local web server on the second local domain using the relay mechanism via at least one networking module.

Description

[0001] Cross - Reference to Related Applications

[0002] This application claims the benefit of U.S. Provisional Application No. 63 / 149,664, filed on Feb. 16, 2021, which is hereby incorporated by reference in its entirety. Background Technical Field

[0004] The present disclosure generally relates to improved network computing. More specifically but not exclusively, the present disclosure relates to an improved web browser engine arranged with server-side functionality that allows for static information storage and retrieval via a single network link. Background Art

[0006] Traditional network computing includes a local computing device operated by a user, a network, and one or more computing servers located remotely from the local computing device. The local computing device is commonly referred to as a desktop computer, laptop computer, tablet computer, smart phone, or some other local computing device. The network is commonly referred to as a personal area network (PAN), local area network (LAN), wide area network (WAN), cellular network, wired network, wireless network, or any combination thereof. The one or more remotely located computing servers are commonly referred to individually and collectively as web servers, server farms, clouds, etc. In at least some cases, the combination of the network and the multiple computing servers is referred to as the "World Wide Web", "Internet", or other similar terms.

[0007] The local computing device, network, and computing server framework is suitable for a style of computing known as the server-based approach. The server-based approach allows complex computationally intensive operations to be performed in the cloud under the guidance of, and for the benefit of, a less complex local computing device. In this context, the local computing device may also be referred to as a "thin client". While a thin client can have any desired level of complexity, generally speaking, a thin client only requires basic processing capabilities, a suitable amount of memory, network connectivity, and a user interface.

[0008] A common approach to server-based thin client computing is to run any code that requires a certain minimum level of operating system (O / S) access on a cloud server. Then, after the cloud server executes the code, the cloud server downloads the static results of this execution to the web browser of the thin client. Some online development environments provide O / S resources in this way, for example, including GITHUB CODESPACES, REPL.IT, and CLOUD9. The web browser of the local computing device only displays the user interface, which serves as a remote display and remote control interface for the physical computing server running remotely in the cloud. Commands entered via the user interface of the local computing device do not use the memory or processor of the local computing device to be saved or executed. Instead, control information representing the desired command is sent to the remote computing server in the cloud, and the remote computing server sends back static information (e.g., terminal output, file system list, etc.).

[0009] Figure 1 FIG. is a block diagram illustrating a conventional server-based computing method 10. The local computing device 12 communicates with a cloud computing environment having a domain name server 16 and one or more remote computing servers 18 via a computing network 14.

[0010] The local computing device 12 includes various hardware structures formed by analog and digital electronic circuits. The hardware structures include a processor 20 and a memory 22. The memory 22 is directly or indirectly coupled to the processor 20 via a memory interface 24. Wired, wireless, or wired and wireless communication circuits 26 allow the local computing device 12 to communicate with the domain name server 16 and any one or more of the remote computing servers 18a - 18n via the computing network 14. A user interface circuit 28 (e.g., a display, keyboard, mouse, touch screen, microphone, speaker, haptic output device, haptic sensor, biosensor, etc.) allows a user 98 to interact with the local computing device. The user 98 can be a human user 98a, another computing device 98b, or some other user. Other hardware 30 (power supply, one or more data buses, timing circuits, security circuits, etc.) of the local computing device known to those skilled in the art is not explicitly identified to avoid unnecessarily cluttering the drawings.

[0011] The memory 22 of the local computing device 12 includes control information, fixed data, working data, and any other type of data typically found or created in a computing device. The memory 22 also includes software executable by the processor 20, such software including an operating system 32, a file system 34, a web browser 40, and user interface software 36. Other software and data 38 known to those skilled in the art (e.g., power control software, security software, firmware, user applications, user data, etc.) are not explicitly identified to avoid unnecessarily cluttering the figures.

[0012] In an exemplary scenario, user 98 desires to interact with the World Wide Web. The user's local computer 12 operates as a thin client in a client-server model. The World Wide Web is implemented via a computing network 14, at least one domain name server 16, and any number of remote computing servers 18. Software instructions stored in the memory 22 and accessed via the file system 34 are passed through the memory interface 24 and executed by the processor 20. The software instructions include code that performs the functions of the operating system 32, and the operating system 32 instantiates and manages the operation of various software applications. Some of the software applications instantiated and managed by the operating system 32 form a user interface, and another software application instantiated and managed by the operating system 32 is the web browser 40.

[0013] User 98 guides the operation of web browser 40 through the cooperation of user interface hardware 28 and user interface software 36. One operation performed by user 98 is to request the presentation of information from a specific website on the display screen. The user types the selected website name (such as WWW.MSN.COM), which is also commonly referred to as the Uniform Resource Locator (URL), using the keyboard. The request including the URL is formatted at a first level by the software of web browser 40 and further formatted at a second level by communication circuit 26. Communication circuit 26 cooperates with first two-way communication medium 42a to advance the request for information through computing network 14. The known hardware of computing network 14 recognizes the request as a URL (i.e., website name) and passes the requested URL to domain name server 16 via second two-way communication medium 42b. Domain name server 16 receives the URL (e.g., HTTP: / / WWW.MSN.COM), performs a lookup of the website name (i.e., URL), and returns the network computer address (e.g., Internet Protocol (IP) address, such as 204.79.197.203) of the web server corresponding to the desired website (e.g., HTTP: / / WWW.MSN.COM). Other known hardware of computing network 14 recognizes the data returned from domain name server 16 as an IP address and routes the request for information via third two-way communication medium 42c to the correct remote computing server 18a - 18n corresponding to the IP address. The appropriate remote computing server 18a - 18n operates web server software, which interprets the request for information and returns a file or other data to local computing device 12 through computing network 14. The received information is processed by the web browser and presented to user 98 via user interface hardware 28 (e.g., display circuit and display screen) and user interface software 36.

[0014] Figure 2 illustrates the architecture of a conventional web browser 40 communicating with the architecture of a conventional web server 70 Figure 1 is a block diagram. Any number of web servers 70 are instantiated within any one or more of the remote computing servers 18a - 18n.

[0015] Conventional web browser 40 is arranged to run on different types of local computing devices 12 ( Figure 1 ), and different types of local computing devices include desktop computers, tablet computers, smart phones, and other fixed and mobile computing devices. User 98 ( Figure 1)Deploy a web browser 40 to access resources stored on or otherwise available from a web server 70 of the World Wide Web (“web”). Each resource on the web is identified by a unique Uniform Resource Identifier (URI), Uniform Resource Locator (URL), or both a URI and a URL.

[0016] As is known to those skilled in the art, a Uniform Resource Identifier (URI) is a unique sequence of characters (e.g., hexadecimal numbers, American Standard Code for Information Interchange (ASCII) identifiers, etc.) that identifies a logical or physical resource available for use on the web. A URI can be used to identify anything, including real-world objects, computing hardware (e.g., printers, scanners, etc.), people and locations, concepts, and information resources such as web pages, programs, etc. In addition to identifying a particular resource, some URIs also provide a means of locating and accessing the resource (e.g., obtaining information from an information resource on the World Wide Web or some other network), and these URIs with address information are called Uniform Resource Locators (URLs). Thus, a URL provides the location of a particular resource, and a URI identifies the resource by specifying a name or URL at that location.

[0017] The user interacts with their web browser 40, which transmits URI information, URL information, or both URI and URL information to one or more web servers 70 operating in one or more remote computing servers 18. In this case, the user can request the transfer of multimedia (e.g., documents, videos, images, sounds, etc.) via the web browser 40 and the local computing server 12 to execute certain software or perform other functions.

[0018] Document resources on the web are typically written using Hypertext Markup Language (HTML), which allows the author to control the appearance of the transmitted document and embed hypertext links to other documents or different locations within the same document. Data is typically transmitted via the Hypertext Transfer Protocol (HTTP), which is a stateless and anonymous means of information exchange.

[0019] Although HTML is a relatively simple language for encoding web pages, other technologies can be used to improve the visual appearance and user experience of the web. Cascading Style Sheets (CSS), for example, allows web page authors to add layout and styling information to web pages without complicating the original structural markup. And JavaScript, for example, is a host environment for performing client-side computations. The script code is embedded within the HTML document, and the corresponding displayed web page is the result of evaluating the JavaScript code and applying it to the static HTML constructs. Some other types of content on the web (e.g., "flash" animations, "Java applets", etc.) cannot be directly rendered by the web browser 40, but "plugins" (i.e., applets that cooperate with the web browser 40) are used to embed such content within web pages. Other known features of the web browser 40 include software for keeping track of recently visited web pages, software for "bookmarking" certain web pages of interest to the user, the ability to store frequently used data and automatically populate certain fields of web pages with such data, software for blocking specific web content (e.g., pop-up windows, advertisements, malicious content, illegal content, etc.), software for maintaining communication with multiple websites simultaneously, and other features.

[0020] Return to Figure 2 , traditional web browsers include eight different and interdependent subsystems. The user interface 44 is the software layer between the user 98 ( Figure 1 ) and the browser engine 46. The user interface 44 software provides multimedia controls, which can include any one or more of toolbars, interactive dialog boxes, page load progress icons, videos, images, graphics, sounds, tactile feedback, etc. In at least some cases, the user interface 44 is integrated with other functions of the local computing device managed by the operating system 32, such as printing, downloading, and saving files, etc.

[0021] The browser engine 46 subsystem is an embedded or embeddable software component that provides a high-level interface to the rendering engine 48. By interacting with the user 98 via the user interface 44 ( Figure 1) To interact, the browser engine 46 can allow the input of Uniform Resource Locator (URL) and Uniform Resource Identifier (URI) information, and in some cases, the browser engine 46 of the traditional web browser 40 can also support basic browsing functions such as forward, backward, and reload. Alternatively or additionally, the browser engine 46 of the traditional web browser 40 is arranged to provide hooks for viewing any number of aspects of a browsing session (such as pop-up windows, current page load progress, JavaScript warnings, etc.). In some cases, the browser engine 46 can also implement queries and manipulations of the rendering engine 48 settings (such as zoom, pause, playback, playback speed, etc.).

[0022] The rendering engine 48 is a software subsystem arranged to generate multimedia (such as images, videos, audio, haptics) representations for a given URI. The rendering engine 48 can display representations generated from HTML and Extensible Markup Language (XML) documents. Such documents can further receive support from an optional HTML parsing module 50, an optional CSS module 52, and embedded content (such as images, audio, etc.). The rendering engine is further arranged to use one or more "reflow" algorithms to calculate an exact page layout, thereby adjusting the display of elements on the web page relative to the display hardware.

[0023] The networking module 54 implements any suitable number of file transfer protocols such as HTTP, Simple Mail Transfer Protocol (SMTP), Internet Message Access Protocol (IMAP), File Transfer Protocol (FTP), etc. This module is arranged to convert between different character sets, parse the Multipurpose Internet Mail Extensions (MIME) media types of files, and perform other communication support functions. In at least some cases, the networking module 50 is arranged to cache recently fetched resources for quick and efficient reuse. In at least some cases, the networking module 54 includes the communication circuit 26 ( Figure 3 ) in whole or at least in part.

[0024] The JavaScript interpreter 56 is software that is executed to interpret JavaScript code embedded in a web page. JavaScript is an object-oriented scripting language that was developed to allow web pages to go beyond static HTML / CSS content and add simple animations, video games, user interactions, etc. JavaScript facilitates adding interactive user behavior to web pages. In addition to websites and interactive user applications, software developers can also use JavaScript to build simple web servers and develop backend infrastructure using Node.js.

[0025] The Extensible Markup Language (XML) parser 58 parses an XML document into a Document Object Model (DOM) tree. As is known to those skilled in the art, XML is a human-readable and machine-readable markup language and is used to store and transmit data.

[0026] The display backend 60 subsystem provides support for rendering web pages on the associated display hardware. The display backend 60 provides drawing and windowing primitives, user interface widgets, fonts, and other display-centric tools.

[0027] Finally, the data persistence repository 62 stores any type, format, and quantity of data determined by the web page developer. The data stored in the data persistence repository 62 includes high-level data such as bookmarks, toolbar or other display settings, browser settings, etc., and low-level data such as cookies, security certificates, and cached web page content.

[0028] As disclosed previously, an architecture with any number of conventional web servers 70 is embodied in any number of remote computing servers 18. Although not illustrated in the current figure, those skilled in the art should understand that the computing servers 18a - 18n have a structure similar to that of the local computing device 12, as both devices include processing circuitry, memory, communication hardware, and other such circuitry, as well as corresponding software to enable the resident hardware. However, in at least some cases, the remote computing devices have enhanced computing resources, such as stronger processing capabilities, larger memory, faster memory, more efficient networking capabilities, etc. Thus, Figure 2 the conventional web server 70 includes software executed by the hardware in a known manner and other software of known types (not shown).

[0029] The conventional web server 70 is a collection of software modules arranged to accept HTTP requests from clients such as the web browser 40 and provide HTTP responses to the clients, along with optional data content such as HTML documents and link objects (e.g., images, videos, etc.). Known conventional web servers include APACHE, MICROSOFT IIS, and SUN JAVA SYSTEMS WEB SERVER.

[0030] The core functions of web server 70 include an HTTP protocol module 72, an HTTP core module 74, an HTTP main server loop 76, and an HTTP request module 78. The additional functions of web server 70 (which can itself be standalone or integrated with web server 70) include a server-side JavaScript runtime environment 80 (i.e., a "container"). The server-side JavaScript runtime environment 80 includes a JavaScript engine 82, a Node.js binding module 84, a Node.js core library 86, and a set of asynchronous input / output (I / O) 88 utilities.

[0031] In operation, a user 98 ( Figure 1 ) interacts with a local computing device 12 ( Figure 1 ) via a web browser 40. Information input by or otherwise directed by the user is input into web browser 40 via user interface 44. This information is passed to browser engine 46. Optionally, additionally or alternatively, the information is stored in data persistence repository 62. In at least some cases, the information from user 98 includes URI or URL information, which is transmitted as an HTTP request via computing network 14 in cooperation with networking module 54 to a remote computing server 18. The HTTP protocol module 72 of web server 70 preprocesses the HTTP request. The HTTP main server loop 76 queues the request for processing by the HTTP core module 74, and the HTTP request module 78 fulfills the request by providing a web page, which is transmitted back as static data via computing network 14 and networking module 54. The data of the web page is processed by the rendering engine 48 of web browser 40, with the help of any of the HTML module 50, CSS module 52, and XML parser 58 if needed. The multimedia data of the web page is presented to user 98 via display backend 60 and the corresponding hardware.

[0032] In some cases, the provided web page includes JavaScript software instructions that are processed by a JavaScript interpreter 56. In such cases, as is common in many cases, JavaScript invokes server-side resources by transmitting one or more additional HTTP requests back to the web server 70 over the computing network 14. Alternatively, data embedded in the web page is processed by the web server 70 before the web page data is transmitted back to the web browser 40. In either case, the HTTP request module 78 or some other code of the web server 70 transmits the JavaScript instructions to the JavaScript engine 82. The JavaScript engine 82 interprets the script, binds to specific resources via the Node.js binding module 84, invokes utilities of the Node.js core library, and performs the necessary actions, which optionally include asynchronous I / O 88. In many cases, the work performed by server-side JavaScript code is complex, substantial, resource-intensive, or otherwise suitable for implementation on the computing server 18 rather than the local computing device 12. The results of the executed JavaScript, which includes dynamic web page content in at least some cases, are transmitted back to the web browser 40.

[0033] All of the topics discussed in the background section are not necessarily prior art and should not be considered prior art solely due to their discussion in the background section. Along these lines, any recognition of prior art problems discussed in the background section or associated with such topics should not be considered prior art unless expressly stated as such. Instead, the discussion of any topic in the background section should be considered as part of the inventors' approach to a particular problem, which approach itself may also be inventive. Summary of the Invention

[0034] The following is an overview of the present disclosure to provide an introductory understanding of some features and context. This overview is not intended to identify key or important elements of the present disclosure or to demarcate the scope of the present disclosure. This overview presents certain concepts of the present disclosure in a simplified form as a prelude to a more detailed description presented later.

[0035] Traditional server - based network programming relies on operating system application programming interface (API) calls to perform certain functions. An exemplary and non - exhaustive list of such functions includes file system operations (e.g., read, write, create, delete, etc.), shell script operations, synchronous multi - threading operations, server operations (e.g., start, pause, reset, stop, etc. of Transmission Control Protocol (TCP) servers, Hypertext Transfer Protocol (HTTP) servers, and other servers), security operations (Transport Layer Security (TLS), Secure Sockets Layer (SSL), etc.), encryption / decryption operations, machine learning operations, image recognition operations, virtual / augmented reality operations, etc. To prevent or at least reduce the likelihood that any of these operations will erroneously or maliciously affect the functioning of another operation, these operations are performed within a secure container (e.g., sandbox, web security sandbox, isolated space, etc.). In at least some cases, the secure container is formed as an inline frame (iFrame). The device, method, and system embodiments described in this disclosure (i.e., the teachings of this disclosure) enable local execution of network - style software programs within the secure container of a web browser engine operating on a local computing device. In this way, the same arbitrary set of untrusted code that accesses the operating system API can be executed by either or both of a traditional web server 70 of a remote computing server 18 and an improved web browser 140 operating on an improved local computing device 112.

[0036] The Summary of the Invention has been provided to describe certain concepts in a simplified form that will be further described in more detail in the Detailed Description. The Summary of the Invention does not limit the scope of the claimed subject matter, which is determined by the words of the claims themselves. BRIEF DESCRIPTION OF THE DRAWINGS

[0037] Non - limiting and non - exhaustive embodiments are described with reference to the following drawings, in which, unless otherwise indicated, like reference numerals refer to like parts throughout the various views. The size and relative positions of the elements in the drawings are not necessarily drawn to scale. For example, the shapes of the various elements are selected, enlarged, and positioned to enhance the readability of the drawings. The particular shapes of the elements as drawn have been selected for ease of identification in the figures. One or more embodiments are described below with reference to the drawings, in which:

[0038] Figure 1 is a block diagram illustrating a traditional server - based computing method;

[0039] Figure 2 is a block diagram of the architecture of a traditional web browser that communicates with the architecture of a traditional web server Figure 1 ;

[0040] Figure 3is a block diagram illustrating an improved network-based computing method;

[0041] Figure 4 is a block diagram illustrating a browser architecture with an improved web browser architecture;

[0042] Figure 5 is an architecture diagram of an improved browser engine;

[0043] Figure 6 is another architecture diagram of an improved browser engine;

[0044] Figures 7A to 7B is a first data flow diagram illustrating the operation of an improved browser engine;

[0045] Figures 8A to 8C is a second data flow diagram illustrating the operation of an improved browser engine;

[0046] Figure 9A is a high-level architecture for a process to bootstrap a system with cross-origin domain communication;

[0047] Figure 9B 、 Figure 9C is in Figure 9A an exemplary communication performed during the bootstrap process; and

[0048] Figure 9D is a high-level architecture for a process to use the bootstrapped system with cross-origin domain communication.

[0049] In the present disclosure, for the sake of brevity, a set of related drawings may be referred to as a single multi-part drawing to facilitate a clearer understanding of the illustrated subject matter. For example, Figures 7A to 7B may be referred to individually or collectively as Figure 7. Figures 8A to 8C may be referred to individually or collectively as Figure 8. Figures 9A to 9D may be referred to individually or collectively as Figure 9. For the sake of brevity, previously identified structures will not be repeated. Detailed Description

[0050] The present disclosure can be more easily understood by reference to the present detailed description and the drawings. The terms used herein are for the purpose of describing specific embodiments only and do not limit the claims, unless a court of competent jurisdiction or a recognized institution determines that such terms are restrictive. Unless expressly defined in the present disclosure, the terms used herein shall be given their conventional meanings known in the relevant art.

[0051] In the following description, certain specific details are set forth in order to provide a thorough understanding of the various disclosed embodiments. However, one of ordinary skill in the relevant art will recognize that the embodiments may be practiced without one or more of these specific details or with other methods, components, materials, etc. In other instances, well-known structures associated with computing systems and networks, including client and server computing systems, are not shown or described in detail to avoid unnecessarily obscuring a more detailed description of the embodiments.

[0052] The present inventors have recognized certain deficiencies and drawbacks in traditional network computing, thin clients, and known server-based traditional JavaScript computing methods. For example, remote computing servers are expensive to operate, they introduce latency, and they require an Internet connection to fully function in the execution of server-based software. Traditional in-browser solutions fail to provide many application programming interfaces (APIs) that enable and implement useful functions for more advanced programming tasks. For example, a complete or near-complete Transmission Control Protocol (TCP) API is necessary in some cases, but the TCP API provided in web browsers (if any) is not built on a model similar to the shared atomic / synchronization process model available in a native operating system (O / S). The in-browser TCP API does not provide the complete API surface of a native operating system, and thus, significant modifications must be made to important software in order to operate under the constraints of a different API surface.

[0053] In short, existing in-browser OS options, whether connected to a wide area network or not, cannot provide performance equivalent to that provided by native environments and remote cloud service environments. To address these drawbacks, the present specification (i.e., the teachings of the present disclosure) provides several device, method, and system embodiments that enable a web browser engine to locally execute runtime software such as Node.js software, Python, Ruby, PHP, Deno, etc. This contrasts with traditional client-server architectures in which a web browser running on a local computing device is communicatively coupled via a computing network such as the Internet to a remote computing server that implements a server-side runtime environment.

[0054] Additionally, the present inventor also recognized that in many real-world technology implementation scenarios, people use their computing devices to interact with other computers, electronic devices, machines, etc. In some cases, these interactions are limited by communication infrastructure deficiencies and other reasons. For example, a user may want to perform computing operations equivalent to traditional client-server operations in a remote location, a location with network congestion, a location without a network, etc. In these environments, network communication may be slow, intermittent, temporarily non-existent, or even permanently non-existent (e.g., in a very crowded environment, in a valley, in a deep forest, underwater, in the open sea, at high altitude, in outer space, in a war zone, in an area controlled by an oppressive regime, in the interior space of a ship, in an airplane, in a factory, during or after a severe weather event (such as a storm, hurricane, flood, tsunami, earthquake, etc.), after a natural or man-made disaster, or in any other such environment).

[0055] Figure 3 is a block diagram illustrating an improved network-based computing method. Figure 3 The architecture of is not prior art, but this architecture is similar to Figure 1 the architecture of. Along this line of thought, Figure 3 some elements of (e.g., user 98, processor 20, operating system 32, user interface software 36, etc.) are formed to be the same as or substantially similar to Figure 1 the corresponding elements of, and these elements with the same reference numerals will not be discussed further. Instead, by describing Figure 1 and Figure 3 the differences between the architectures of and, those skilled in the art will recognize that the local computing device 112 is a new and improved, dedicated and non-general-purpose computing system, which includes a memory 122 loaded with improved web browser 140 software, and when the software is executed by a suitable processor, it forms a dynamic system with features hitherto unknown in the art.

[0056] Figure 4 is a more detailed block diagram illustrating the improved web browser 140 architecture of Figure 3 The architecture of is similar to Figure 4 the architecture of Figure 2 and along this line of thought, Figure 4 some elements of (e.g., networking module 54, XML parser 58, display backend 60, etc.) are formed to be the same as or substantially similar to Figure 2 the corresponding elements of. These same or similar elements with the same reference numerals will not be discussed further. Instead, by describing Figure 2 and Figure 4Regarding the differences between architectures, those skilled in the art will further recognize a new and improved, specialized and non - general - purpose computing system that includes a memory loaded with improved software 122, which, when executed by a suitable processor 20, forms a dynamic system with features hitherto unknown in the art.

[0057] In Figure 4 , the traditional web browser 40 ( Figure 2 ) of the computing system has been modified into an improved web browser 140. The improved web browser includes an improved browser engine 146 that, when operated, instantiates at least one runtime environment container 180. Optionally, the improved web browser 140 may also include a scripting language interpreter 156 (e.g., an improved JavaScript interpreter), and optionally, the improved web browser 140 may further or alternatively include an improved data persistence module 162. Alone or in cooperation with other modules, the improved browser engine 146 includes new and modified processor - executable instructions that, when stored in memory and additionally when executable and executed, form a new and improved computing system with hitherto unknown features.

[0058] Figure 4 The improved web browser 140 of Figure 2 can sometimes communicate with the architecture of a traditional web server 70, and such communication, when it occurs, can be performed in a traditional manner, but such communication is not necessary. Alternatively, some computing functions can now be executed in the local runtime environment container 180 instead of being executed in the server - side runtime environment container 80 ( Figure 2 ) on the remote web server 18.

[0059] As is well known, the traditional web browser 40 ( Figure 2 ) is capable of handling many types of web page resources. Web page software is written in many different software languages that create collaborative or otherwise co - existing resources. Hypertext Markup Language (HTML), Cascading Style Sheets (CSS), and JavaScript are examples of three different software languages used for web page programming, and there are other languages. In at least one case, software code initially created and written in all three languages works together to create a web page. In these web pages, HTML instructions can be executed to create the structure of the web page, instructions programmed in CSS format can be executed to style the HTML markup, and instructions written in JavaScript will create interactivity. Traditionally, complex HTML and JavaScript - like functions are executed in the remote server container 80 ( Figure 2) is performed in, however, in the improved web browser 140, similar complex runtime functions can be implemented on the local computing device 112 without the need to interact with the server-side runtime environment.

[0060] In Figure 4 the improved web browser 140, HTML and CSS code can also be implemented using local resources, and unlike the traditional web browser 40, the improved web browser 140 can implement JavaScript software in the local JavaScript runtime environment container 180. It should be understood that although JavaScript is often described in this disclosure, any other suitable dynamic programming language is also covered. Along these lines, a non-limiting and non-exhaustive list of content types that can be implemented via the local runtime environment container 180 includes JavaScript, "flash" animations, "Java applets", "plugins", etc.

[0061] In at least some cases, the script language interpreter 156 (e.g., an improved JavaScript interpreter) is optionally integrated with the improved web browser 140 or otherwise available to the improved web browser 140. The script language interpreter 156 can be arranged to parse JavaScript, convert or otherwise generate software calls into the local container 180 rather than a remote server-based container, transcribe the location or other information of JavaScript for local processing, or perform other interpretation tasks.

[0062] In at least some cases, an improved data persistence repository 162 can be additionally or alternatively implemented. When optionally included, the improved data persistence repository 162 can be arranged to store server-side control information, data information, etc., while the web server is communicatively coupled to the improved web browser 140, and the information can be used later when the remote server is unavailable. Additionally or alternatively, the improved data persistence repository 162 can also be used to store control information, data information, etc. associated with the improved JavaScript interpreter, the runtime environment container 180, or any other module of the improved web browser 140.

[0063] In operation, the user 98 ( Figure 3 ) via the improved web browser 140 with the improved local computing device 112 ( Figure 3) Interaction. Information input by or otherwise directed by user 98 is input into web browser 140 via user interface 44. This information is passed to improved browser engine 146. Optionally, additionally or alternatively, this information is stored in improved data persistence repository 162. In at least some cases, the information from user 98 includes URI or URL information that is transformed by improved browser engine 146, script language interpreter 156, or some other software to identify local computing resources rather than a remote computing server 18. This identification can be done by hard-coded addresses, dynamically updated addresses, linked lists, lookup functions, etc. In this way, data for the web page is generated locally. This data can be processed by rendering engine 48, if needed, with the help of any one of HTML module 50, CSS module 52, and XML parser 58. Multimedia data for the web page is presented to user 98 via display backend 60 and the corresponding hardware.

[0064] Figure 5 is an architectural diagram of improved browser engine 146. Parent application 190 runs on improved local computing device 112( Figure 3 ). This application instantiates improved web browser 140( Figure 4 ), which opens browser window 192. In at least some cases, parent application 190 navigates improved web browser 140 to a specific network-accessible server resource 194a via interaction with a software practitioner or other user. The network-accessible server resource 194a can be accessed via a uniform resource locator such as a website (e.g., HTTPS: / / WWW.STACKBLITZ.COM / EDIT / PROJECT-NAME), a specific network address, etc. The network-accessible server resource 194a can include a program, a public-facing website, a secure website, a proprietary and non-publicly accessible website, or some other resource.

[0065] Optionally, the improved web browser 140 or some module associated therewith may include one or more qualification functions to direct access to the network-accessible server resource 194a. For example, software variables that can be loaded automatically or via user control can be tested to determine whether the improved web browser 140 will be communicatively coupled to the remote computing server 18, or alternatively whether the improved web browser 140 will perform all actions locally. As another alternative, the qualification function can determine whether the remote computing server 18 is communicatively accessible. If the remote computing server 18 is communicatively accessible, then the improved web browser 140 will be communicatively coupled to the remote computing server 18. Alternatively, if the remote computing server 18 is not communicatively accessible (e.g., no network connection, no resolvable URL, no permission to access resources, etc.), then the improved web browser 140 will perform all actions locally. Of course, other types and operations of the qualification function are also conceivable. In Figure 5 the embodiment of, the remote computing server 18, the web server 70, and the computing network 14 are grayed out to indicate that they are inaccessible. Thus, in Figure 5 the embodiment of, all actions of the improved web browser 140 will be performed locally. The optional qualification function, if present, can be formed in the script language interpreter 156 ( Figure 4 ), the browser engine 146 ( Figure 4 ) or some other module.

[0066] In Figure 5 the improved browser engine 146 of, at the browser node indicated by the network-accessible server resource 194a, the improved browser engine 146 instantiates at least one local runtime environment container 180. The improved browser engine 146 also instantiates the local computing server resource 194b. In Figure 5 the embodiment of, the local computing server resource 194b is accessed via a uniform resource locator such as a website (e.g., HTTPS: / / UNIQUE-ID.WEBCONTAINER.IO). However, in other cases, the local computing server resource 194b can be accessed via a specific local memory address, a specific network address, a local circuit, a communication module, or any other suitable resource that can be accessed, directed, or otherwise controlled from the improved local computing device 112 ( Figure 3 ).

[0067] In addition to instantiating one or more local runtime environment containers 180 and one or more local computing server resources 194b, the improved browser engine 146 performs or otherwise directs other actions. For example, the improved browser engine 146 can further allocate certain local computing resources, including memory, to at least one local runtime environment container 180; the improved browser engine 146 can grant access to specific local computing resources to one or more local computing server resources and at least one local runtime environment container; and the improved browser engine 146 can isolate the allocated specific local computing resources from other functions of the improved computing system 112. Other actions can also be directed.

[0068] Via operating system application programming interface (API) calls, access at least some of certain local computing resources from the local runtime environment container 180 (i.e., the resources granted access by the improved browser engine 146). In these cases, the interpreted code in or accessible by the improved browser engine 146 (e.g., using the scripting language interpreter 156) identifies such calls and, rather than directing these calls to resources conventionally found on the web server 18, locally directs these calls to resources on or available to the improved computing system 112.

[0069] An exemplary and non-exhaustive list of local computing resource functions includes file system operations (e.g., read, write, create, delete, etc.), shell script operations, synchronous multi-threaded operations, server operations (e.g., start, pause, reset, stop, etc. of Transmission Control Protocol (TCP) servers, Hypertext Transfer Protocol (HTTP) servers, and other servers), security operations (Transport Layer Security (TLS), Secure Sockets Layer (SSL), etc.), encryption / decryption operations, machine learning operations, image recognition operations, virtual / augmented reality operations, etc. Any one or more of these operations may be useful in industrial applications, military applications, commercial applications, educational applications, or any other environment.

[0070] Memory is another local computing resource allocated to at least one local runtime environment container 180 from the improved data persistence repository 162 ( Figure 4 ). The memory can be random access memory (RAM), read-only memory (ROM), external memory (e.g., hard disk drive, flash drive, optical storage medium, etc.). The memory can be continuous or non-continuous. In at least some cases, the memory is allocated when needed, deallocated when no longer needed, and in other cases is dynamically available.

[0071] Other local computing resources to which the improved browser engine 146 may optionally be granted access include, but are not limited to, user interface resources, processing resources, interrupts, and data communication bandwidth. Other resources are also contemplated.

[0072] To prevent or at least reduce the likelihood that an operation from one container will incorrectly or maliciously affect another container or some other part of the improved computing system 112 from functioning, each runtime environment container 180 is formed as a secure container (e.g., sandbox, web security sandbox, isolation space, "Node.js container", etc.). In at least some cases, the secure container is formed as an inline frame within a framework. In at least some cases, such an inline frame is formed as a component (e.g., an HTML element) of a first network-accessible server resource 194a within a browser window 192.

[0073] In operation, Figure 5 Embodiments of the improved browser engine 146 may include an interface (e.g., a user or computer interface of an integrated development environment (IDE), programming software application, industrial machine, consumer device, kiosk, or any other useful application) that allows a parent application 190 to communicate with the runtime environment container 180. For example, in at least some cases, the parent application 190 uses the postMessage command to control any number of operations of the resources available within the runtime environment container 180. Other such communication and window control functions are also contemplated. Upon receipt of such communication, the resources available within the runtime environment container 180 will, in at least some cases, instantiate a runtime environment process (e.g., a Node.js process) that may be arranged as a "web worker" loaded within the core process of the runtime environment container 180. In this way, even third-party runtime software code can be loaded and executed within a given web worker process on the improved computing system 112.

[0074] In Figure 5In an embodiment, three local runtime environment web worker processes 196a, 196b, 196n are instantiated. In other embodiments, any other number of web worker processes may be instantiated. Each of the local runtime environment web worker processes 196a, 196b, 196n can be collectively, selectively, or individually controlled from the parent application 190 via a communication interface. Along these lines, each local runtime environment web worker process may optionally be arranged to bootstrap the operation of certain kernel-level functions. These kernel-level functions may include file system functions, spawned threads, access to hardware (e.g., interrupts, general-purpose input / output (GPIO), etc.), access to local wired or wireless communication functions (e.g., BLUETOOTH, USB, FIREWIRE, RS-232, RS-485, Ethernet, etc.), and other such functions.

[0075] In Figure 5 an embodiment, the kernel-level interface 198 is arranged to bootstrap the operation of any one or more kernel-level functions. In this implementation, each web worker process 196a, 196b, 196n can access a script language interpreter, a WebAssembly kernel module, and shared memory. The kernel-level interface 198 module may be implemented in the improved browser engine 146, the local runtime environment container 180, the script language interpreter 156, or any other suitable module. The kernel-level interface 198 module may include security features (e.g., encryption, hash functions (e.g., keys), cyclic redundancy check (CRC) codes, challenge functions (e.g., usernames and passwords), or other security means). In at least some embodiments, the shared memory functionality may be implemented by the improved data persistence module 162 ( Figure 4 ). For example, a SharedArrayBuffer may be implemented to schedule synchronous tasks.

[0076] Figure 6 is another architectural diagram of the improved browser engine 146. Figure 6 The architecture of Figure 5 includes the architectural elements of Figure 6 and, along these lines, at least some elements of

[0077] Figure 6Embodiments present at least one use case of the local runtime environment web worker process 196, which bootstraps the instantiation and control of any suitable number of local computing server resources. For example, Node.js can be used to bootstrap the instantiation and control of one or more HTTP servers. Traditional web browsers do not provide an API to perform such actions, but as taught herein, the improved browser engine 146 can use known API calls passed through the kernel-level interface 198 to call such a process via the local runtime environment web worker process 196. In traditional web browsers, web worker processes are stateless and are prohibited from accessing resources outside their allotted browser space, but in the embodiments described herein, the local runtime environment web worker process 196 can access such cross-origin resources via the kernel-level interface 198.

[0078] Figure 6 The kernel-level interface 198 includes a relay mechanism 198a and a kernel 198b. In at least one case, the relay mechanism 198a is arranged as a windowless module (e.g., an invisible inline frame). In at least one case, the kernel 198b is arranged as a WebAssembly program. The kernel 198b can be formed as a state machine, a task loop, a micro operating system, etc. The kernel 198b has elevated privileges, which allow the kernel 198b to access specific resources of the improved computing system 112 ( Figure 3 ) and bootstrap the control of said resources. Such resources can include specific memory, communication modules, interrupts, timers, etc.

[0079] In operation, the parent application 190 can make direct process calls through the runtime environment container 180. The received communication is processed by the local runtime environment web worker process 196 (e.g., a Node.js process). Depending on the content of the communication (which can be any available control information or data associated with the user 98 ( Figure 3 ), certain messages can be passed bidirectionally through the kernel-level interface. In at least one case, messages from the runtime environment container 180 are formatted by the local computing server resource 194b (e.g., HTTPS: / / UNIQUE-ID.WEBCONTAINER.IO), passed to the relay mechanism 198a (e.g., PROJECT-NAME.STACKBLITX.IO / ...RELAY.HTML), and passed bidirectionally between the kernel 198b (PROJECT-NAME.STACKBLITZ.IO / SW.JS) and the script language server process 200a (e.g., PROJECT-NAME.STACKBLITZ.IO / INDEX.HTML).

[0080] Figures 7A to 7B are first data flow diagrams 700a, 700b that illustrate the operation of the improved browser engine 146. In the present disclosure, Figures 7A to 7B they may be collectively referred to as FIG. 7. For the sake of brevity, previously identified structures will not be repeated. Referring to Figures 3 to 6 the structure of Figure 6 the embodiments will be further described.

[0081] In the embodiment of FIG. 7, various local computing resources are instantiated and accessed using two-way communication. In this non-limiting embodiment, TCP networking is implemented by mapping TCP calls to HTTP request / response objects, and the improved browser engine 146 uses these HTTP request / response objects to direct operations in the local runtime environment web worker processes 196. The web socket API of traditional browser engines is overridden by the improved browser engine 146 process (e.g., the scripting language interpreter 156), which allows direct communication with one or more locally instantiated scripting language server processes 200a, 200b, 200n (e.g., TCP servers). In short, the embodiment of FIG. 7 teaches a virtualized TCP network stack that can instantiate and communicate with a local HTTP server and web sockets from within the improved web browser 140 and without relying on a remote computing server.

[0082] In Figure 7A it, the first visible frame 704 is formed as the first tab in the improved web browser 140. This first visible frame 704 may correspond, for example, to the browser window 192 ( Figure 5 , Figure 6 ). The'main' document 716 is associated with the first visible frame 704. In Figure 7B it, the second visible window 706 is formed as the second tab in the improved web browser 140. The'request' document 728 is associated with the second visible window 706. Once an operation is performed, cross-domain communication occurs between these two window documents (i.e., the'main' document 716 and the'request' document 728) that are each associated with a different domain.

[0083] Above the initialization phase line 708 (i.e., the bold dashed line) of FIG. 7, the initialization operations for instantiating the virtualized TCP network stack are represented. Below the initialization phase line 708 of FIG. 7, certain "usage" operations implemented via messages transmitted through the virtualized TCP network stack are represented.

[0084] Processing starts at circle A, i.e., a first message 302 is passed from a certain browser node.

[0085] In at least some cases, the first message 302 is a GET LOCALHOST:3002 message, which is implemented in the software of the improved browser engine 146.

[0086] The action can start from a user input keyboard command, mouse command, motion command, automated computer command, or some other locally received command associated with the "main document" window of the browser node. For example, taking this action is to start the process that will allow messages to be passed through the TCP server. Starting the TCP server will also trigger the improved browser engine 146 to instantiate one or more locally hosted HTTP servers, web socket servers, and other such servers as described in this disclosure (e.g., the local service adapter 726).

[0087] As a next step, it is desired to instantiate a relay mechanism 198a (such as an inline frame) to allow communication from a first network-accessible server resource 194a (e.g., a first domain, the main browser window, tab 1, the first visible window 704) to a second local computing server resource 194b (e.g., a second domain, a second browser window, tab 2, the second visible window 706, the local service adapter 726). The communication between the first network-accessible server resource 194a and the second local computing server resource 194b can be considered "cross-origin" communication, "cross-domain" communication, "across-origin" communication, "across-domain" communication, "cross-border" communication, "cross-boundary" communication, etc. Traditionally, these communications would be passed between the local computing device 12 and the remote computing server 18. In the non-limiting embodiment described in FIG. 7, these communications are passed in the improved web browser 140 on the same improved local computing device 112.

[0088] In Figure 7A it, the instantiation of the relay mechanism (e.g., an inline frame) and the second local computing server resource 194b is implemented through the second message 304, the third message 306, the fourth message 308, and the fifth message 310. The web page of the first tab (tab 1) will communicate with the web page of the second tab (tab 2) using the relay mechanism.

[0089] In at least some cases, the second message 304 is a LOCALSERVICE.START(...) message, which is implemented in the software of the improved browser engine 146 and transmitted at the request of the improved browser engine 146 to a local service 718 started by the operating system of the improved local computing device 112. In at least some cases, the local service 718 is arranged to manage an account or administrator of a local network accessible service.

[0090] The third message 306 includes a single message call function or a set of instructions, which are implemented in the software of the improved browser engine 146 to add a 'communication relay' document 720 (e.g., an inline frame) for the local server being instantiated (e.g., HTTP, web socket, or others). In at least one case, the local web server being instantiated (e.g., the local service adapter 726) will be associated with a specific URL (e.g., TESTING.LOCAL.STACKBLITZ.IO). Subsequently, when a request is made to this URL (e.g., TESTING.LOCAL.STACKBLITZ.IO), the request will be forwarded to the local server process running in the first tab page, and the request will be obtained through the web page of the second tab page (tab page 2).

[0091] In at least some cases, the fourth message 308 is a WINDOW.ADDEVENTLISTENER message, which is implemented in the software of the improved browser engine 146 and transmitted to the window 722 of the relay mechanism 198a (i.e., the 'communication relay' document 720, inline frame, etc.). This message starts an autonomous service that is used to "listen" for messages and pass these messages to their designated destinations through the service worker 724 on the window 722 of the relay mechanism 198a (i.e., the 'communication relay' document 720, inline frame, etc.) and the local web server (e.g., the local service adapter 726). In some cases, the local service adapter 726 is implemented using, for example, local web server software installed on port 3002 as requested by the first message 302.

[0092] The fifth message 310 includes a single message call function or a set of instructions, which are implemented in the software of the improved browser engine 146 to install the service worker 724 on the server at a specific URL (e.g., TESTING.LOCAL.STACKBLITZ.IO). When a request is made to this specific URL, the request is forwarded to LOCALHOST.

[0093] Summarize the actions performed above line 708 during the initialization phase. For example, the first message 302 from a TCP server operating on the first local domain (Figure 8) attempts to connect to a port, which causes the improved browsing engine 146 to initiate the process of instantiating the relay mechanism and the local web server listener on the second local domain. The inline frame 720 is initialized, and once the inline frame 720 is loaded, the service worker 724 is installed on the window 722 of the inline frame 720. After the service worker 724 is installed, the local server is ready to start receiving requests (e.g., HTTP requests, web socket requests, or other local server requests), and the local server waits until these requests are received. At startup, the local server can be accessed in the browser via, for example, the second visible window 706 of the browser (e.g., the second domain, tab 2).

[0094] The message 312 (the sixth message) represents initialization information that is passed from the inline frame 720 to the web page of the second tab (tab 2) via the local web server (e.g., the local service adapter 726) to approach the user 98.

[0095] Consider the actions below line 708 during the initialization phase. The seventh message 314 is associated with the second visible window 706 (tab 2), and the startup of this second visible window is caused by the interaction with the local server instantiated via messages 302 - 312. In at least some cases, the seventh message 314 is the GETTESTING.LOCAL.STACKBLITZ.IO message implemented in the software of the improved browser engine 146.

[0096] In response to the seventh message 314 (i.e., the GET request), the eighth message 316, a fetch request (e.g., an HTTP fetch request, an initWebSocket() request, etc.), is sent to the service worker 724 to start operating the local web server (e.g., the local service adapter 726, LOCAL.STACKBLITZ.IO).

[0097] Upon receiving the eighth message 316, the service worker 724 executes specific query software and initiates various communications to determine whether the service worker 724 is connected to the relay mechanism 198a( Figure 6)(i.e., 'communication relay' document 720, iframe, etc.), this relay mechanism is attached to the local web server (e.g., local service adapter 726, LOCAL.STACKBLITZ.IO) and is located in the domain of the TCP server (Figure 8). In this embodiment, this interrogation via the ninth to fourteenth messages 318 - 328 is further arranged to determine whether the main window (e.g., the'main' document, the first visible window 704, tab 1) is associated with a local server such as the TCP server (Figure 8) that is arranged to receive the fetch request.

[0098] In at least some cases, the ninth message 318 is a CONTROLLERCONNECTED():BOOLEAN message, which is implemented in the software of the improved browser engine 146 and is passed from the service worker 724 to the local web server (e.g., local service adapter 726). Such a message is arranged to poll the local web server and receive a positive or contradictory (e.g., yes or no, 1 or 0, true or false, etc.) response.

[0099] In at least some cases, the tenth message 320 is a PROMISE <boolean>A message that is implemented in the software of the improved browser engine 146 and returned from a local web server (e.g., local service adapter 726) to the service worker 724. Such a message is a response to a polling request from the service worker 724.

[0100] In at least some cases, the eleventh message 322 is a CONTROLLERFETCH() message that is implemented in the software of the improved browser engine 146 and passed from the service worker 724 to a local web server (e.g., local service adapter 726).

[0101] In at least some cases, the twelfth message 324 is a SELF.CLIENTS.MATCHALL message that is implemented in the software of the improved browser engine 146 and is arranged to clearly capture server identification information.

[0102] In at least some cases, the thirteenth message 326 is a NEW MESSAGECHANNEL message that is implemented in the software of the improved browser engine 146 and is arranged to start creating a new message channel for sending outbound messages from a local web server (e.g., local service adapter 726).

[0103] And in at least some cases, the fourteenth message 328 is a PORT1 ONMESSAGE message that is implemented in the software of the improved browser engine 146 and is arranged to establish a message event handler that will receive messages from a TCP server.

[0104] After confirming the existence of a TCP server (Figure 8) accessible via the service worker 724, the service worker 724 formats a fetch request associated with the eighth message 316 to the TCP server via the fifteenth message 320 and the sixteenth message 332.

[0105] In at least some cases, the fifteenth message 330 is a CLIENT.POSTMESSAGE(MESSAGE,[PORT2]) message that is implemented in the software of the improved browser engine 146 and sent from a local web server (e.g., local service adapter 726) to the inline frame 720 of the window 722 (i.e., the 'communication relay' document) via the service worker 724.

[0106] In at least some cases, the sixteenth message 332 is a 'MESSAGE' LISTENER FIRED message, which is implemented in the software of the improved browser engine 146 and is arranged to transfer information from the inline frame 720 of the window 722 to the TCP server (FIG. 8) using the account credentials of the local service 718 associated with the'main' document 716 of the TCP server (FIG. 8). The fifteenth message 330 and the sixteenth message 332 will include the content of the original fetch request (i.e., the eighth message 316), which includes a port on the local web server (e.g., the local service adapter 726) that enables the TCP server to return a response.

[0107] The response from the TCP server (FIG. 8) includes a plurality of messages including the seventeenth message 336, the eighteenth message 338, and the nineteenth message 340, which are relayed back through the relay mechanism 198a ( Figure 6 )(e.g., the 'communication relay' document 720, the window 722, the service worker 724) of the'main' document 716, the local service 718, and the local web server (e.g., the local service adapter 726) of the first visible window 704 (tab 1).

[0108] In at least some cases, the seventeenth message 336 is a PORT2.POSTMESSAGE(SEND_RESPONSE) message implemented in the software of the improved browser engine 146, which enables cross-origin communication from the TCP server (FIG. 8) back to the local web server (e.g., the local service adapter 726).

[0109] In at least some cases, the eighteenth message 338 is a PORT2.POSTMESSAGE(STREAM_PUMP) message implemented in the software of the improved browser engine 146.

[0110] In at least some cases, the nineteenth message 340 is a PORT2.POSTMESSAGE(STREAM_END) message implemented in the software of the improved browser engine 146.

[0111] Messages from the TCP server (FIG. 8) (e.g., the seventeenth to nineteenth messages 336 - 340) are transferred as the twentieth message 342 and the twenty-first message 344 through the service worker 724 of the local web server (e.g., the local service adapter 726) to the'request' document 728 associated with the second visible window 706 of the user's improved web browser 140.

[0112] In at least some cases, the twelfth message 342 is a PROMISE <response>A message that is implemented in the software of the improved browser engine 146 and is passed from a local web server (e.g., local service adapter 726) to the service worker 724.

[0113] In at least some cases, the twenty-first message 344 is a RETURN RESPONSE message that is implemented in the software of the improved browser engine 146 and arrives from the service worker 724 at the second visible window 706 (tab 2) of the user's improved web browser 140.

[0114] Summarizing the actions performed under the initialization phase line 708, a request to enter a second local domain (e.g., the seventh message 314) is processed by the service worker 724 (e.g., the eighth message 316). A series of processing and communications (e.g., the ninth message to the fourteenth message 318 to 328) checks the 'communication relay' document 720 to determine whether a TCP server has been started on the first local domain. This check can be performed, for example, by verifying whether the 'communication relay' document 720 is the page connected to the service worker 724. If so, the second local domain is connected to the inline frame 720 using postMessage (e.g., the fifteenth message and the sixteenth message 330 to 332) with the request and mechanism (e.g., port number) of the TCP server on the first local domain to directly send a response back to the second visible window 706 (tab 2) of the user's improved web browser 140 through the service worker 724 (the seventeenth message to the twenty-first message 336 to 344).

[0115] Figures 8A to 8C Are second data flow diagrams 800a, 800b, 800c that further illustrate the operation of the improved browser engine 146. In the present disclosure, Figures 8A to 8C Can be collectively referred to as FIG. 8. For the sake of brevity, the previously identified structures will not be repeated.

[0116] The operation of the improved browser engine 146 in FIG. 8 virtualizes a TCP networking stack with HTTP and ServiceWorker support across source domains. However, in line with the concept of FIG. 7, the teachings of FIG. 8 can be applied to HTTP communications, web socket communications, and other such cross-source communications. However, beyond the embodiments of FIG. 7, FIG. 8 also shows the actions before the containerization of the cross-source communications shown in FIG. 7.

[0117] In Figure 8A In [the scenario], the process starts with a SERVER CREATE MESSAGE 400 at circle I. In at least some cases, the SERVER CREATE MESSAGE 400 is a CREATESERVER(TCP) message that is implemented in the software of the improved browser engine 146 and is passed into the browser node 802. The browser node 802 may be visible in the browser, visible in a software development environment, or not visible at all. The browser node 802 hosts a TCP wrapper function 814 that, in at least one embodiment, operates as a TCP server.

[0118] The TCP server embodied in the TCP wrapper function 814 Figure 8A may optionally provide a network access control list (ACL) system that filters network access to the Internet protocol server of the TCP server. Thus, the TCP wrapper function 814 can be used in some cases in software development or other environments to protect network communications (e.g., cross-origin communications) from malicious or otherwise unacceptable communications.

[0119] In some cases, the TCP wrapper function 814 of the browser node 802 is also arranged to host a Node.js instance along the lines of a runtime environment container 180 ( Figure 6 ). By using the TCP wrapper function 814, communications from one application can be placed in a first virtual container, while communications from other applications can each be placed in corresponding other virtual containers. In this way, the improved browser engine 146 can host any selected number of items while significantly reducing concerns about overlap, overload, disruption, or malicious activity. As further described herein with reference to FIG. 8, when a request is received from the local web server 826, the request is passed into the running TCP wrapper function 814 (e.g., the Node.js instance), and then a response from the wrapper is transmitted back to the service worker 824.

[0120] Along the lines of FIG. 7, initialization operations for instantiating a virtualized TCP network stack are shown above the initialization phase line 806 (i.e., the bold dashed line) in FIG. 8. Communication operations that utilize the virtualized TCP network stack are shown below the initialization phase line 806 in FIG. 8.

[0121] When creating a TCP server and running an instance of Node.js in the browser node 802, a first message 402 is formed and transmitted to effect [the operation] in the improved local computing device 112 ( Figure 3 )Cross - origin communication between a TCP server operating on [the device] and a local web server (e.g., local service adapter 826, LOCAL.STACKBLITZ.IO) also operating on the improved local computing device 112.

[0122] In at least some cases, the first message 402 is a WINDOW.POSTMESSAGE(SERVER_REQUEST) message implemented in the software of the improved browser engine 146. Such a command can be user - generated (e.g., keyboard command, mouse command, action command, etc.), computer - generated, or guided by some other command.

[0123] The first message 402 is received at the first visible frame 804 (e.g., the first tab) in the improved web browser 140. The first visible frame 804 can correspond to the browser window 192 associated with the TCP server managed by the TCP wrapper function 814 ( Figure 5 , Figure 6 ). The'main' document 816 is associated with the first visible frame 804 and thus with the TCP server.

[0124] In Figure 8C , the second visible frame 806 is formed as the second tab in the improved web browser 140. The'request' document 828 is associated with the second visible window 806. In operation, cross - origin communication may occur between the'main' document 816 and the'request' document 828, which are associated with the TCP server (i.e., TCP wrapper function 814) and the local web server (e.g., local service adapter 826) respectively.

[0125] As a next step, a relay mechanism 198a ( Figure 6 ) is instantiated as, for example, an inline frame. The instantiation of the relay mechanism (e.g., inline frame) begins with the second message 404, the third message 406, the fourth message 408, and the fifth message 410. The web page of the first tab (tab 1) uses the relay mechanism to communicate with the web page of the second tab (tab 2).

[0126] In at least some cases, the second message 404 is a LOCALSERVICE.START(...) message, which is implemented in the software of the improved browser engine 146 and transmitted to the local service 818 started by the operating system of the improved local computing device 112 at the request of the improved browser engine 146.

[0127] In at least some cases, the third message 406 includes a single message call function or a set of instructions that are implemented in the software of the improved browser engine 146 to associate an inline frame (e.g., the 'Communication Relay' document 820) with the local web server being launched. As shown in FIG. 7, the local web server (e.g., the local service adapter 826) can be associated with any selected URL (e.g., TESTING.LOCAL.STACKBLITZ.IO). A later request to this URL will be forwarded to LOCALHOST and retrieved by the web page of the second tab (Tab 2).

[0128] In at least some cases, the fourth message 408 is a WINDOW.ADDEVENTLISTENER message that is implemented in the software of the improved browser engine 146 and is sent to the inline frame window 822. This message causes a service worker 824 to be installed on the inline frame window 822 and starts the local web server (e.g., the local service adapter 826).

[0129] The fifth message 410 includes a single message call function or a set of instructions that are implemented in the software of the improved browser engine 146 to install the service worker 824 on the server at a specific URL (e.g., TESTING.LOCAL.STACKBLITZ.IO).

[0130] Considering the actions below the initialization phase line 708, the sixth message 414 is associated with the second visible window 806 (Tab 2), and the start of this second visible window is caused by the interaction with the local server instantiated via messages 402 - 412. In at least some cases, the sixth message 414 is a GETTESTING.LOCAL.STACKBLITZ.IO message that is implemented in the software of the improved browser engine 146.

[0131] In response to the sixth message 414, a seventh message 416, a fetch request (e.g., an HTTP fetch request, an initWebSocket() request, etc.), is sent to the service worker 424 to start using the local web server.

[0132] Upon receiving the seventh message 416, the service worker 824 executes specific query software and initiates various communications to determine whether the service worker 824 is connected to an inline frame that is attached to the local web server and is on the domain of the TCP server. This interrogation, which is carried out via the eighth to thirteenth messages 418 - 428 in this embodiment, is further arranged to determine whether the main window (e.g., the'main' document, the first visible window 804, Tab 1) is associated with the TCP server that will receive the fetch request.

[0133] Message 418-428 follows the line of thought of Message 318-328 (Figure 7) and will not be discussed further.

[0134] When it is determined that the TCP server can be accessed through the service worker 824, the service worker 824 formats a fetch request associated with the seventh message 416 to the TCP server via the fourteenth message 430, the fifteenth message 432, and the sixteenth message 434.

[0135] In at least some cases, the fourteenth message 430 is a CLIENT.POSTMESSAGE(MESSAGE,[PORT2]) message, which is implemented in the software of the improved browser engine 146 and sent from the local web server to the inline frame 820 via the service worker 424.

[0136] In at least some cases, the fifteenth message 432 is an FM ‘MESSAGE’ LISTENER FIRED message, which is implemented in the software of the improved browser engine 146 and is arranged to pass information from the inline frame 820 to the TCP server. The local service 818 of the TCP server provides credentials associated with the ‘main’ document 816 of the TCP server.

[0137] In at least some cases, the sixteenth message 434 is formatted with the credentials from the local service 818 to transfer the port opened on the local web server from the original fetch request (i.e., the eighth message 416) to the TCP server, thereby enabling direct cross-origin communication between the TCP server and the local web server.

[0138] Upon receiving the sixteenth message 434, the TCP server forms a response including a number of messages, which includes the seventeenth message 436, the eighteenth message 438, and the nineteenth message 440. These messages are relayed back through the ‘main’ document 816 of the first visible window 804 (tab 1), the local service 818, and the relay mechanism 198a of the inline frame including the local web server (e.g., the local service adapter 826) ( Figure 6 )

[0139] Messages 436-4440 follow the line of thought of messages 336-340 in the data stream of (Figure 7). The seventeenth message 436 initiates direct cross-origin communication from the TCP server through the service worker 824 of the local web server, where the communication can be accessed by the second visible window 806 (tab 2) of the user's improved web browser 140.

[0140] In at least some cases, the eighteenth message 438 generates a message pump mechanism for ongoing one-way or two-way messaging between the two servers. And the nineteenth message 440 optionally, temporarily, or permanently shuts down the messaging between the two servers. As will be understood by those skilled in the art, the eighteenth message 438 and the nineteenth message 440 may be separated by seconds, minutes, hours, days, or any suitable time period. In at least some cases, the nineteenth message 440 is not sent at all.

[0141] Messages 442 - 444 follow the lines of messages 342 - 344 (Figure 7) and will not be discussed further.

[0142] Further consider Figure 5 the features and benefits of the improved browser engine 146 architecture

[0143] The present disclosure teaches an API-complete Node.js or other such runtime that can execute entirely within the improved web browser engine 180 or otherwise control Node.js or other such applications. A kernel is provided that supports synchronous and atomic file system operations, thread spawn and control, supports local startup of a complete TCP / HTTP and other such servers accessible within the improved web browser 140, controls local hardware, and performs other such functions.

[0144] In particular, the present disclosure further teaches the structure and means for running a local computing server (e.g., an HTTP server) from within the improved web browser 140. A plurality of node APIs are provided to enable broad support for third-party Node.js and other such programs. Those skilled in the art will recognize that the embodiments described herein allow JavaScript, WebAssembly, and other such applications to run within a runtime environment container 180 (e.g., a secure sandbox) on the improved local computing device 112, and such applications may rely on operating system APIs typically provided in a Node.js or other such environment. Those skilled in the art will recognize that the improved web browser 140 is described herein, but other secure environments (e.g., CLOUDFLARE WORKERS, NETLIFY, FIREBASE, LAMBDA, etc.) supported by the improved browser engine 146 functionality are also within the scope of the present disclosure.

[0145] For a variety of reasons, it is desirable to run applications purely within an improved browser engine 146. For example, web browsers have inherent security, and web browser developers are constantly improving this security. The teachings of the present disclosure can be quickly ported to any new web browser, thereby creating an improved web browser 140 as described herein. Web browsers also serve as a fast and consistent cross-platform target, which allows third-party software practitioners to write an application once, and the application can be immediately opened in any improved web browser 140 without additional recompilation. For at least some users of the disclosed technology, a fully browser-internal development environment that does not rely on a remote computing server 18 for complex computational work is now available. This is the inverse model of traditional server-based IDEs.

[0146] To implement this technology, the inventors have recognized that executing Node.js and other similar runtime environments sometimes requires access to underlying operating system APIs, and traditional web browser engines do not provide traditional operating system primitives (e.g., POSIX APIs, shells / terminals, synchronous file system access, multithreading with synchronous operations, nor the ability to start a locally accessible TCP / HTTP web server). Although traditional Node.js is based on the CHROMIUM V8 engine, traditional environments deviate from CHROMIUM's sandbox execution model by exposing raw operating system APIs for developers to utilize. Powerful applications can be built, but this mechanism undermines the cross-platform advantages of traditional browser engines and also exposes the operating system of the local computing device to malicious exploitation during code execution.

[0147] Now, the disadvantages of traditional systems are overcome. For example, in one embodiment, the JavaScript / WebAssembly runtime of the improved browser engine uses a kernel-level interface. This architecture allows the full set of Node.js APIs to run from within a secure runtime environment container. Instead of attempting to port a complete or even streamlined operating system to a web browser, the inventors focused on the runtime environment (e.g., Node.js). Any known scripting language can be used to provide custom patches to APIs that typically access native local capabilities. And because this type of runtime environment scripting language is known to web browsers, these custom patches can be piggybacked onto existing web browser code, thereby creating an improved web browser rather than stripping the shell of native operating system functionality and exposing native operating system functionality.

[0148] In one embodiment, Node.js executes within an improved web browser by riding on an existing JavaScript / WebAssembly runtime hosted on an improved browser engine and providing a kernel with symmetric APIs that Node.js depends on internally. The system is capable of executing any untrusted third-party code entirely within the secure execution container of the improved web browser and without modifying third-party source code in any way, even when accessing operating system APIs.

[0149] Since the teachings in this disclosure include a system that runs all code inside a runtime environment container of a secure web browser, the system can also work offline or when traditional communication infrastructure is otherwise unavailable. The web environment disclosed herein is capable of generating and controlling local computing servers (e.g., HTTP servers) on demand without even leaving the secure sandbox of the improved web browser. The improved browser engine is capable of implementing synchronization processes and file locking via kernel-level interfaces and shared memory (e.g., shared array buffers). Along this line of thought, at least some of the APIs that can be used to implement non-limiting embodiments of the present invention are new additions to the web browser (e.g., service workers, shared array buffers, Atomics, WebAssembly, WebAssembly threads, etc.), and these APIs are deployed in new ways. For example, service workers are designed to support offline web applications by introducing a simple HTTP proxy API that web applications can register with. These service workers do not expose APIs for controlling the HTTP proxy API outside of their own scope.

[0150] Considering at least one practical application of the embodiments described herein, the techniques of this disclosure can be used to significantly improve the productivity, time efficiency, and cost-effectiveness of software developers. By applying the teachings herein, software practitioners can simply establish an entire software development environment by directing an improved web browser 146 to navigate to a single URL. Additionally, by simply directing each software practitioner's improved web browser 146 to the same URL on their respective local machines, an identical software development environment can be established for any number of software practitioners.

[0151] In traditional software development, software practitioners are required to download or otherwise obtain certain software, install the software on their local computing devices, start the new software, and configure the environment in which the software will be utilized or otherwise used. In many cases, configuring the environment will take minutes, hours, or even days. Now, as taught by the present disclosure, once the environment is configured, a single Uniform Resource Locator (URL) can be associated with the environment, and the URL can be sent to one or more software practitioners. When a software practitioner "opens" the URL in a tab or window of their improved web browser 140, the environment will be automatically downloaded and installed. As another benefit in terms of time savings, efficiency, and security, since all resources will be provided via the secure container environment of the local computing device, the installation is cybersecurity-compliant and nearly instantaneous.

[0152] As at least yet another example, the teachings of the present disclosure can be applied to any suitable number of computing servers, web servers, and other types of remote computing devices. In this way, any type of computing environment can be deployed on a large scale, securely, and quickly. Once the environment is created, the environment can be associated with a single URL, and the single URL can be transmitted (e.g., via email, direct download, file transfer, etc.) to a desired destination. When using an improved web browser 140 with an associated improved browser engine 146 to receive and navigate to the URL, the pre-loaded environment will be locally self-installed and self-deployed within the secure sandbox of the improved web browser, where the environment cannot access other memories or services of the rest of the machine. The remote computing device will be ready to be used almost instantaneously. One or thousands or more computer machines can be deployed with exactly the same environment running exactly the same code very consistently.

[0153] Figure 9A is the high-level architecture 900a of the process of bootstrapping a system with cross-origin domain communication. Figure 9B 、 Figure 9C are the exemplary communications 900b, 900c performed during the bootstrapping process. Figure 9D is the high-level architecture 900d of the process of using a bootstrapping system with cross-origin domain communication.

[0154] The architecture 900a of FIG. 9 can be implemented with the improved web browser 140 and its associated components disclosed with respect to Figures 4 to 6 While recognizing that the teachings of FIG. 9 can be suitably applied to any type of scripting language and other traditional server-side processing, the present disclosure describes an exemplary and non-limiting JavaScript architecture to avoid unnecessarily confusing the discussion presented herein.

[0155] In Figure 9A In an improved web browser 140 executing on an improved local computing device 112 ( Figure 3 ), a browser window 192 is opened. User 98 navigates to a network-accessible server resource 194c (e.g., STACKBLITZ.COM / EDIT <unique-id>)。However, the improved browser engine 146 of the improved web browser 140 begins to be used to create a process for another domain (i.e., cross - origin domain) that operates within a secure runtime environment container 180 (e.g., Node.js), rather than communicating outside the local computing device 112( Figure 3 ). The only network - accessible server resource 194c (which is arranged as a Uniform Resource Locator (URL) in this case) is used to create a second unique cross - origin URL 194d (e.g., <unique-id>.W.STACKBLITZ.COM / IFRAME.HTML), wherein the system will automatically or under the guidance of the user install a secure container and execute the selected software (e.g., the user's code).

[0156] As a first action 202 during the boot process, download a runtime environment application programming interface (API) 182 (e.g., a JavaScript API). As a second action 204 during the boot process, add a windowless inline frame. The windowless inline frame will be used for cross-domain communication. In this way, at a network-accessible server resource 194c URL (e.g., STACKBLITZ.COM / EDIT <unique-id>) The software executed in the main thread at will be operationally isolated from the software executed on a different domain, in this case, the different domain is the second unique cross-origin URL 194d (e.g., <unique-id>.W.STACKBLITZ.COM / IFRAME.HTML).

[0157] As a third action 206 in the boot process, the runtime environment API is initialized, and as a fourth action 208 in the boot process, any suitable number of web workers 924a are generated and initialized. In at least one case, the web worker 924a is a fetcher worker arranged to find, obtain, and transfer certain data on boot, but in other cases, the web worker is arranged to perform different actions. Operations inside the runtime environment container 180 bootstrapped by the improved browser engine 146 begin with a fifth action 210 in the boot process. Here, user code (e.g., JavaScript in this case, but many other types of software are also conceivable) is downloaded and transferred to one or more web workers 924a to be executed when or if called.

[0158] As a sixth action 212 in the boot process, zero or more additional web workers 924b can optionally be generated and initialized. In at least one case, a file system web worker is created. And at a seventh action 214, the kernel-level interface 198b (e.g., kernel WASM) is instantiated and initialized. The local kernel-level interface 198b is arranged to access any number of computing resources of the local computing device 112 ( Figure 3 ) while remaining isolated from one or more main operation threads of the network-accessible server resource 194c URL.

[0159] Go to Figure 9B 、 Figure 9C , and now describe a set of non-limiting exemplary communication messaging. Those skilled in the art will recognize Figure 9A the architecture in, particularly the windowless cross-origin inline frame 922 (i.e., created at the second action 204 in the boot process), the web workers 924a, 924b, and the kernel-level interface 198b and Figure 9B 、 Figure 9C the interrelated nature of the boot communication of.

[0160] In Figure 9B , the first domain runtime environment window 830 (e.g., Node.js runtime) is formed as the first tab in the improved web browser 140. The'main' thread 916 or a set of operation functions is associated with the first window 830, and these will bootstrap the operations of the boot process. In Figure 9C , the second domain execution window 832 is visible as the second tab in the improved web browser 140.

[0161] Processing begins on main thread 916 with a first message 502, a second message 504, and a third message 506.

[0162] In at least some cases, the first message 502 is arranged to download a runtime environment API (e.g., DOWNLOAD RUNTIME ENVIRONMENT WRAPPER VIA <script src＝"javascript">消息，所述消息在改进的浏览器引擎146的软件中实施)。

[0163] 在至少一些情况下，第二消息504被布置为添加跨源内嵌框架922(例如，ADDCONTAINER IFRAME CONST IFRAME＝DOCUMENT.CREATEELEMENT(‘IFRAME’))。

[0164] 在至少一些情况下，第三消息506被布置为产生并初始化任何合适数量的web工作者(例如，SPAWN FETCH WORKER VIA NEW WORKER())。

[0165] 一旦创建了跨源内嵌框架922，就用第四消息508通过下载特定用户代码来初始化运行时环境容器180。在至少一种情况下，第四消息508下载JavaScript，但是还可设想许多其他类型的软件(例如，DOWNLOAD CONTAINER VIA<SCRIPT SRC＝"...”>)。

[0166] 在已经建立了跨源内嵌框架并加载了具有可执行软件的内嵌框架之后，第五消息510、第六消息512和第七消息514在主线程916的第一域与用户代码将被安全执行的第二域之间创建消息通信机制。在至少一些情况下，第五消息510是由改进的浏览器引擎146执行的INIT()VIA POSTMESSAGE()消息；第六消息512是由改进的浏览器引擎146执行的INITIALIZE NEW CONNECTION CONST(PORT1,PORT2)＝NEW MESSAGECHANNEL()消息；并且第七消息514是由改进的浏览器引擎146执行的RETURN PORT2消息。

[0167] 一旦新页面被安装在内嵌框架922内部的单独跨源域上，就可以产生任何数量的web工作者924a、924b，并且可以初始化内核接口198b。web工作者924a、924b安全地传送回主线程916(并且反之亦然)，同时内核接口198b能够执行访问本地计算设备112(图3)的操作系统级资源的软件。域之间的通信和消息传递由第八消息516指示，所述第八消息在至少一些情况下包括由改进的浏览器引擎146执行的POSTMESSAGE()消息。任何数量的第八消息516被执行以安全地建立并在主线程916到分别位于跨源页面内部的web工作者924a、924b之间通信。

[0168] 利用第九消息518(例如，由改进的浏览器引擎146执行的INITWORKER()VIA NEWWORKER()消息)来建立共享存储器，并且利用第十消息520、第十一消息522和第十二消息524来建立内核接口198b。在至少一些情况下，第十消息是由改进的浏览器引擎146执行的INITIALIZE消息。在至少一些情况下，第十一消息522包括由改进的浏览器引擎146执行的INSTANTIATE KERNEL VIA NEW WEBASSEMBLY MEMORY(...)消息和WEBASSEMBLY.INSTANTIATE(...)消息。在至少一些情况下，第十二消息524包括由改进的浏览器引擎146执行的RETURN WEBASSEMBLY.MEMORY消息和WEBASSEMBLY.MODULE消息。在设置内核接口198b时，第十三消息526可以用于访问和运用共享存储器功能。在至少一些情况下，第十三消息526是由改进的浏览器引擎146执行的INIT(MEMORY,MODULE,...)VIAPOSTMESSAGE()消息。

[0169] 转到图9D，高级架构900d展示了使用具有在图9A至图9C中建立的跨源域通信的引导系统的非限制性过程。通常，产生新的工作者(例如，Node.js工作者)，并且该新的工作者可以使用改进的web浏览器140的内置特征(例如，EVAL())来访问WASM内核接口198b和共享存储器以执行模块。

[0170] 在跨源架构中的第一动作222中，基于给定的文件路径和可选实参来执行程序(例如，JavaScript程序)。在跨源架构中的第二动作224中，产生第一web工作者924a，并且在第三动作226中，执行用户代码(例如，Node.js)。在第四动作228中安装并连接内核接口198b，并且在跨源架构的第五动作230中执行程序。所述程序可以是由任何语言、配置和操作特性的运行时代码形成的任何合适的程序。

[0171] 本公开的教导给web技术领域带来了若干另外的益处。例如，可以降低瞬时成本。通过使用改进的本地计算设备的处理器和存储器，不会有远程计算服务器给最终用户带来的另外成本。另外，这些教导可以容易地扩展到数百万，而不会使网络通信和远程计算服务器的资源负担过重。另外，实时操作可以经由零时延实现。不需要远程计算服务器来代理往返命令和结果。替代地，所有的执行都发生在改进的本地计算设备上。另一个益处是，本文所描述的特征可以在基本上没有广域网(例如，因特网)连接的情况下执行。还有一个益处是，本文所描述的实施例可以提供快一个数量级的用户体验。执行程序不必等待远程计算服务器通过计算网络发送兆字节的未压缩开发构建、大文件、复杂计算的结果等——这本身可能会遭受不可控的延迟。简而言之，本公开教导了系统的至少一个实施例，该系统是快速的，提供实时执行而没有时延，并且提供实时反馈循环。这种系统具有极高的可扩展性和成本效益，因为它们不需要为每个用户提供任何远程计算服务器。这些系统为大规模多租户作准备，并且由于完全在改进的web浏览器的改进浏览器引擎中执行而是安全的。

[0172] 现在已经阐明了某些实施例，进一步澄清本文所使用的某些术语可以有助于提供对本公开中被视为具有发明性的实施例的更加完整的理解。

[0173] 各种附图包括图示了可以由本文所描述的改进的计算系统的实施例和改进的浏览器引擎实施例使用的非限制性过程的数据流图。在这方面，每个所描述的过程可以表示软件代码的模块、分段或一部分，该软件代码包括用于实施指定的一个或多个逻辑功能的一个或多个可执行指令。还应当注意，在一些实施方式中，过程中提到的功能可以以不同的顺序发生、可以包括另外的功能、可以同时发生和 / 或可以省略。

[0174] 本公开中的附图图示了一个或多个非限制性计算设备实施例的各部分，如web浏览器140的一个或多个部件。计算设备可以包括在传统计算设备装置中找到的操作硬件，如一个或多个处理器、易失性和非易失性存储器、符合各种标准和协议的串行和并行输入 / 输出(I / O)电路、有线和 / 或无线联网电路(例如，通信收发器)、一个或多个用户接口(UI)模块、逻辑电路和其他电子电路。

[0175] 如本文所描述的处理设备或"处理器”包括中央处理单元(CPU)、微控制器(MCU)、数字信号处理器(DSP)、专用集成电路(ASIC)、外围接口控制器(PIC)、状态机等。因此，如本文所描述的处理器包括控制至少一个操作的任何设备、系统或其一部分，并且这种设备可以在硬件、固件或软件或者其中的至少两个的某种组合中实施。与任何特定处理器相关联的功能可以是集中式的，也可以是分布式的，无论是本地还是远程。处理器可以可互换地指代被配置为执行经过编程的软件指令的任何类型的电子控制电路。经过编程的指令可以是高级软件指令、编译软件指令、汇编语言软件指令、目标代码、二进制代码、微代码等。经过编程的指令可以驻留在内部或外部存储器中或者可以硬编码为状态机或一组控制信号。根据本文所引用的方法和设备，一个或多个实施例描述了可由处理器执行的软件，所述软件当被执行时执行方法动作中的一个或多个方法动作。

[0176] 本申请讨论了包括一个或多个计算设备或者以其他方式与一个或多个计算设备协作的若干实施例。应认识到，这些计算设备被布置为执行一个或多个算法来实施本文教导的各种概念。所述算法中的每一个被理解为用于解决逻辑或数学问题或执行任务的有限步骤序列。在本公开中教导的任何或所有算法可以通过公式、流程图、数据流图、说明书中的叙述以及在本公开中显而易见的其他这样的手段来展示。按照这个思路，执行本文所公开的算法的结构包括执行从至少一个存储器设备中取得的至少一个软件指令的至少一个处理设备。该结构可以视情况而进一步包括本领域技术人员已知的合适的输入电路(例如，键盘、按钮、存储器设备、通信电路、触摸屏输入装置和任何其他集成和外围电路输入装置(例如，加速度计、温度计、光检测电路和其他这样的传感器))、本领域技术人员已知的合适的输出电路(例如，显示器、光源、音频设备、触觉设备、控制信号、开关、继电器等)、以及本公开中教导的任何另外的电路或其他结构。为此，将在需要时清楚地叙述对权利要求中任一项所述的装置或步骤加功能元素的每次调用。

[0177] 如本领域技术人员已知的，计算设备具有一个或多个存储器，并且每个存储器包括用于读取和写入的易失性和非易失性计算机可读介质的任何组合。易失性计算机可读介质包括例如随机存取存储器(RAM)。非易失性计算机可读介质包括例如只读存储器(ROM)、如硬盘等磁性介质、光盘、闪速存储器设备、CD-ROM等。在一些情况下，特定存储器被虚拟地或物理地分离成单独的区域，如第一存储器、第二存储器、第三存储器等。在这些情况下，应当理解的是，不同存储器分区可以处于不同的设备中或体现在单个存储器中。在一些情况下，存储器是被配置为存储被布置为由处理器执行的软件指令的非暂态计算机介质。存储器的所存储内容中的一些或全部可以包括可由处理设备执行以执行一个或多个特定动作的软件指令。

[0178] 本文所图示的计算设备可以进一步包括在如操作系统或任务循环等传统计算设备中存在的操作软件、用于通过I / O电路、联网电路以及其他外围部件电路引导操作的软件驱动器。另外，计算设备可以包括操作应用软件，如用于与其他计算设备通信的网络软件、用于构建和维护数据库的数据库软件以及在适当的情况下用于在各种处理器之间分发通信和 / 或操作工作负载的任务管理软件。在一些情况下，计算设备是具有本文列出的至少一些硬件和软件的单个硬件机器，并且在其他情况下，计算设备是在服务器群中一起工作以执行本文所描述的一个或多个实施例的功能的硬件和软件机器的联网集合。为了简单起见，计算设备的传统硬件和软件的一些方面没有在图中示出。

[0179] 除其他外，本公开的示例性计算设备(例如，图3的本地计算设备112)可以配置在任何类型的移动或固定计算设备中，如远程云计算机、计算服务器、智能电话、平板计算机、膝上型计算机、可穿戴设备(例如，眼镜、夹克、衬衫、裤子、袜子、鞋子、其他衣物、帽子、头盔、其他头饰、手表、手镯、挂件、其他珠宝)、车载设备(例如，火车、飞机、直升机、无人驾驶飞行器、无人驾驶水下航行器、无人驾驶陆基交通工具、汽车、摩托车、自行车、踏板车、悬浮滑板、其他个人或商业运输设备)、工业设备(例如，工厂机器人设备、家用机器人设备、零售机器人设备、办公环境机器人设备)等。因此，计算设备包括未图示的其他部件和电路，例如显示器、网络接口、存储器、一个或多个中央处理器、相机接口、音频接口和其他输入 / 输出接口。在一些情况下，示例性计算设备也可以被配置在不同类型的低功率设备中，如安装的摄像机、物联网(IoT)设备、多媒体设备、运动检测设备、入侵者检测设备、安全设备、人群监控设备或某种其他设备。

[0180] 当如本文所描述的那样进行布置时，每个计算设备可以从通用的且非特定的计算设备转换为被布置为包括被配置用于具体且特定的目的的硬件和软件的组合设备，如以便提供确定的技术解决方案。当如本文所描述的那样进行布置时，在本文所描述的发明概念中的任何发明概念均被有裁定权的团体发现包括在抽象观念中的程度上，明确提出了元素和限制的有序组合以通过将抽象观念转换为所述抽象观念的有形且具体的实际应用来提供必要的发明概念。

[0181] 本文所描述的实施例使用计算机化技术来改进网络式计算的技术，但是还有其他技术和工具仍可用于实施运行时动态计算。因此，所要求保护的主题不排除整个或甚至相当大的网络式计算技术领域。本文所描述的创新使用以新的且有用的方式组合的新的且已知的构建块以及其他结构和限制来创建比迄今为止的传统上已知的更多的东西。这些实施例对计算系统进行了改进，即这些计算系统在未被编程或被不同地编程时不能执行或提供本文所要求保护的特定本地执行的服务器端系统特征。本公开中描述的实施例改进了已知的网络式过程和技术。本文的实施例中描述的计算机化动作不完全是传统的，并且尚未被很好地理解。替代地，这些动作对行业来说是新的。此外，如结合本公开实施例描述的动作组合提供了新的信息、动机和商业结果，并且该信息、动机和商业结果在单独考虑动作时是不存在的。对于构成抽象概念的内容，没有流行的公认的定义。在某种程度上，本公开中讨论的概念可以被认为是抽象的，权利要求呈现了所述所谓的抽象概念的明显更加有形、实用和具体的应用。并且所述权利要求还改进了先前已知的执行网络式操作的基于计算机的系统。

[0182] 软件可以包括完全可执行的软件程序、简单配置数据文件、到另外的方向的链路或已知软件类型的任何组合。当计算设备更新软件时，更新可大可小。例如，在一些情况下，计算设备下载小配置数据文件作为软件更新的一部分，并且在其他情况下，计算设备用新版本完全替换所述计算设备或另一个计算设备上的当前软件的大部分或全部。在一些情况下，出于包括安全、隐私、数据传输速度、数据成本等在内的原因，软件、数据或软件和数据被加密、编码和 / 或以其他方式压缩。

[0183] 如果本文所描述的计算系统中存在任何数据库结构，则该数据库结构可以在单个数据库或多个数据库中形成。在一些情况下，硬件或软件存储库在与它们相关联的一个或多个特定系统的各种功能之间共享。数据库可以形成为本地系统或局域网的一部分。可替代地或另外地，数据库可以远程地形成，如在可经由广域网或某个其他网络来访问的分布式"云”计算系统中形成。

[0184] 输入 / 输出(I / O)电路和用户接口(UI)模块包括串行端口、并行端口、通用串行总线(USB)端口、IEEE 802.11收发器和符合由一个或多个标准制定机构管理的协议的其他收发器、显示器、投影仪、打印机、键盘、计算机鼠标、麦克风、如加速度计等微机电(MEMS)设备，等等。

[0185] 在至少一个实施例中，如web浏览器140、联网模块54、改进的浏览器引擎146或某个其他模块或电路等设备可以经由网络上的通信而与其他设备通信。网络可以包括因特网连接或某个其他类型的局域网(LAN)或广域网(WAN)。实现或形成网络的各部分的结构的非限制性示例包括但不限于以太网、双绞线以太网、数字用户环路(DSL)设备、无线LAN、Wi-Fi、全球微波接入互联接入(WiMax)等。

[0186] 在本公开中，存储器可以以一种配置或另一种配置使用。存储器可以被配置为存储数据。可替代地或另外地，存储器可以是非暂态计算机可读介质(CRM)。CRM被配置为存储可由本地计算设备112(图3)的处理器20执行的计算指令。计算指令可以单独地或作为指令群组存储在文件中。文件可以包括功能、服务、库等。文件可以包括一个或多个计算机程序或者可以是较大计算机程序的一部分。替代性地或另外地，每个文件可以包括对执行改进的网络计算系统的计算功能有用的数据或其他计算支持材料。

[0187] 按钮、小键盘、计算机鼠标、存储卡、串行端口、生物传感器读取器、触摸屏等可以单独或协同地对编程改进的网络计算系统的软件从业者有用。例如，这些设备可以将控制信息输入到系统中。显示器、打印机、存储卡、LED指示器、温度传感器、音频设备(例如，扬声器、压电设备等)、振动器等都对向操作改进的网络计算系统的软件从业者呈现输出信息有用。在一些情况下，输入和输出设备直接耦接到本地计算设备112，并且电耦接到处理器或其他操作电路。在其他情况下，输入和输出设备经由一个或多个通信端口(例如，RS-232、RS-485、红外、USB等)传递信息。

[0188] 如本文所描述的，为了简单起见，在一些情况下，可能在男性性别的上下文中描述软件从业者。应理解，软件从业者可以具有任何性别，并且如本文所使用的术语"他”、"他的”等应当被广泛地解释为包括所有已知性别定义。如本公开中上下文可能要求的，除了上下文可能另外指明的情况，单数可意指复数，并且反之亦然；所有代词应意指并且包括其与之有关的人、实体、公司或企业；并且阳性词可意指阴性词，并且反之亦然。

[0189] 如本文和随后的权利要求所使用的术语"实时”或"即时”并不旨在暗示瞬时处理、发射、接收或其他(视情况而定)。替代地，术语"实时”意味着活动以数字方式在可接受的短时间段内(例如，在微秒或毫秒的时段内)发生，以及活动可以不断地或以其他方式数字持续地执行(例如，维持与远程计算服务器的持久的实际或虚拟连接)。不实时的活动的示例是在延长的时间段(例如，数小时或数天)内发生的活动、或基于软件从业者或其他活动的干预或引导而发生的活动。

[0190] 在没有对其在特定上下文中的明确使用作出任何具体澄清的情况下，当术语"基本上”或"约”或其任何同源词在本公开和任何所附权利要求中均用作修饰词(例如，以修饰结构、尺寸、量度或其他某种特性)时，应当理解，特性可以变化高达30％。例如，消息之间的时间可以被描述为约半秒。在这些情况下，正好是半秒的消息间隔正好是500毫秒。与术语"半秒”的确切精度不同，使用"基本上”或"约”来修饰特性允许"半秒”特性变化高达30％。因此，约半秒的消息间隔包括350毫秒与650毫秒之间的消息间隔。

[0191] 在提供了值范围的情况下，应当理解的是，介于该范围的上限与下限之间的每个中间值(到下限的单位的十分之一，除非另外明确说明)以及所述范围中的任何其他所述值或中间值都涵盖在本发明内。这些更小范围的上限和下限可以独立地包括在更小范围之内、还涵盖在本发明之内，这受制于在所述范围内任何确切排除的限制。在所述范围包括限制中的一个或两个的情况下，不包括那些所包括限制中的任一个或两个的范围也包括在本发明内。

[0192] 除非另外定义，否则本文所使用的技术和科学术语都具有与本发明所属领域的普通技术人员通常所理解相同的含义。尽管类似于或等同于本文所描述的方法和材料的任何方法和材料也可以用于实践或测试本发明，但是本文中仅描述了有限数量的示例性方法和材料。

[0193] 在本公开中，当元素(例如，部件、电路、设备、装置、结构、层、材料等)被称为"在另一个元素上”、"耦接到另一个元素”或"连接到另一个元素”时，这些元素可以直接在另一个元素上、直接耦接到另一个元素或直接连接到彼此，或者可以存在中间元素。相反，当元素被称为"直接位于另一个元素上”、"直接耦接到另一个元素”或"直接连接到另一个元素”时，不存在中间元素。

[0194] 术语"包括”和"包含”以及其派生词和变型在其所有句法环境中均应以开放的包括性意义非限制性地进行解释(例如，"包括但不限于”)。术语"或”是包括性的，意指和 / 或。短语"与……相关联”和"与其相关联”以及其派生词可以被理解为意指包括、被包括在……内、与……互连、包含、被包含在……内、连接到……或与……连接、耦接到……或与……耦接、可与……通信、与……协作、交错、并置、在……附近、被绑定到……或与……绑定、具有、具有……的性质等。

[0195] 贯穿本说明书引用的"一个实施例”或"实施例”及其变型意味着结合实施例描述的特定特征、结构或特性包括在至少一个实施例中。因此，在整个本说明书中各个地方出现的短语"在一个实施例中”或"在实施例中”不一定都是指同一个实施例。此外，在一个或多个实施例中，可以以任何适合的方式组合特定特征、结构或特性。

[0196] 在本公开中，术语第一、第二等可以用于描述各种元素，然而，这些元素不受这些术语的限制，除非上下文明确要求这种限制。这些术语仅仅是用来将一个元素与另一个元素进行区分。例如，在不偏离本发明概念的范围的情况下，第一机器可以被称为第二机器，并且类似地，第二机器可以被称为第一机器。

[0197] 除非内容和上下文另外清楚地指出，否则本公开中的单数形式的"一个”、"一种”和"该”包括复数指示物。除非内容和上下文清楚地指明包括性或排他性(视情况而定)，否则连接性术语"和”和"或”一般在最广泛的意义上用于包括"和 / 或”。"和”与"或”的组合当在本文中被记载为"和 / 或”时涵盖包括与其相关联的所有元素的实施例、以及包括少于与其相关联的所有元素的至少又一个可替代实施例。

[0198] 在本公开中，连接词列表利用逗号，所述逗号可以被称为牛津逗号、哈佛逗号、连续逗号或另一个类似术语。这种列表旨在连接词语、从句或句子，使得逗号后面的事物也包括在列表中。

[0199] 本文中提供的本公开的小标题和摘要仅仅是为了方便起见，而并非解释实施例的范围或含义。

[0200] 在本公开中描述的改进的网络计算系统和模块提供了网络式计算领域的若干技术效果和进步。

[0201] 在网络式计算(即，服务器式网络编程)中，本地客户端依赖于服务器端操作系统应用程序编程接口(API)调用来执行某些功能。这种功能的示例性且非详尽的列表包括文件系统操作(例如，读取、写入、创建、删除等)、外壳 / 终端脚本操作、同步多线程操作、服务器操作(例如，传输控制协议(TCP)服务器、超文本传输协议(HTTP)服务器和其他服务器的启动、暂停、重置、停止等)、安全操作(传输层安全(TLS)、安全套接字层(SSL)等)、加密 / 解密操作、机器学习操作、图像识别操作、虚拟 / 增强现实操作等。为了防止或至少降低这些操作中的任何一个错误地或恶意地影响另一操作发挥作用的可能性，这些操作在安全容器(例如，沙箱、web安全沙箱、隔离空间等)中执行。本公开中描述的设备、方法和系统实施例(即，本公开的教导)以及本公开的技术效果和益处使得能够于在本地计算设备上操作的web浏览器引擎的安全容器内本地执行网络式软件程序。以这种方式，对操作系统API进行访问的同一组任意的不可信代码可以由远程计算服务器18的传统web服务器70和在改进的本地计算设备112上操作的改进的web浏览器140中的任一个或两个来执行。

[0202] 例如，替代地，本公开教导软件从业者所解释的编程语言应用程序(例如，JavaScript、WebAssembly等)、CLOUDFLARE WORKERS、NETLIFY、FIREBASE、LAMBDA等(其依赖于可以以其他方式在如Node.js等服务器端运行时环境上实施的操作系统API)可以在改进的web浏览器引擎146的运行时环境容器180内部执行。迄今为止，执行Node.js需要访问底层操作系统API，这是传统的web浏览器引擎所不提供的(例如，操作系统原语，如便携式操作系统接口(POSIX)API、外壳 / 终端、同步文件系统访问、具有同步操作的多线程，启动可本地访问的TCP / HTTPweb服务器的能力等)。然而，如本文所教导的，改进的web浏览器140、尤其是改进的浏览器引擎146暴露这些原始操作系统API，以供软件从业者以安全、高效且有效的跨平台方式进行利用。

[0203] 在一个实施例中，改进的浏览器引擎146的JavaScript / WebAssembly(JS / WASM)运行时被用来使得Node.js的完整API集能够在运行时环境容器180(图4)内部运行。在该实施例中，本发明人向Node.js提供了定制的软件补丁，而不是将完整的操作系统移植到传统的web浏览器中。不是像移植完整的操作系统时将直接去除本机操作系统功能的外壳，而是这些补丁将API功能引导到浏览器引擎的现有JS / WASM运行时中。在至少一些情况下，改进的浏览器引擎146提供与在其他情况下远程计算服务器上提供的API对称的内核级API。

[0204] 本公开阐述了各种结构实施例的细节，所述结构实施例可以被布置为承载本公开的教导。通过利用本文所描述的灵活电路、创新软件、计算架构和通信手段，现在公开了多种示例性设备和系统。

[0205] 示例A-1是一种改进的计算系统，包括：至少一个处理器；至少一个联网模块；存储器，所述存储器具有存储与其上的被格式化用于由所述至少一个处理器执行的软件指令，所述软件指令被布置为：操作第一本地域上的本地计算服务器资源；实例化具有内嵌框架和不可见窗口的中继机制；实例化第二本地域上的本地web服务器；将服务工作者安装在所述不可见窗口上；在所述本地web服务器处接收对信息的请求；验证所述第一本地域上所述本地计算服务器资源的存在；将所述第二本地域通信地连接到所述内嵌框架；以及经由所述至少一个联网模块，使用所述中继机制在所述第一本地域上的所述本地计算服务器资源与所述第二本地域上的所述本地web服务器之间直接传送至少一个消息。

[0206] 示例A-2可以包括如示例A-1以及可替代地或另外地本文中的任何其他示例所述的主题，其中，所述本地计算服务器资源被布置为传输控制协议(TCP)服务器。

[0207] 示例A-3可以包括如示例A-2以及可替代地或另外地本文中的任何其他示例所述的主题，其中，所述本地web服务器在安全容器内部被实例化。

[0208] 示例A-4可以包括如示例A-1至A-3中任一项以及可替代地或另外地本文中的任何其他示例所述的主题，其中，所述中继机制的至少一部分被包括在所述安全容器内部。

[0209] 示例A-5可以包括如示例A-1至A-4中任一项以及可替代地或另外地本文中的任何其他示例所述的主题，其中，所述安全容器被布置为托管至少一个Node.js进程。

[0210] 示例A-6可以包括如示例A-1至A-5中任一项以及可替代地或另外地本文中的任何其他示例所述的主题，其中，所述本地web服务器被布置为处理超文本传输协议(HTTP)通信。

[0211] 示例A-7可以包括如示例A-1至A-6中任一项以及可替代地或另外地本文中的任何其他示例所述的主题，其中，所述本地web服务器被布置为处理web套接字通信。

[0212] 示例A-8可以包括如示例A-1至A-7中任一项以及可替代地或另外地本文中的任何其他示例所述的主题，其中，所述本地web服务器被布置为处理JavaScript命令。

[0213] 示例A-9可以包括如示例A-1至A-8中任一项以及可替代地或另外地本文中的任何其他示例所述的主题，其中，所述本地计算服务器资源可经由第一浏览器窗口访问，并且所述本地web服务器可经由第二浏览器窗口访问。

[0214] 示例A-10可以包括如示例A-1至A-9中任一项以及可替代地或另外地本文中的任何其他示例所述的主题，其中，所述本地计算资源被布置有至少一个内核级接口，所述至少一个内核级接口被布置为引导一个或多个内核级函数的操作。

[0215] 示例B-1是一种改进的计算系统，包括：提供具有至少一个联网模块的单个本地计算资源；在所述单个本地计算资源内，操作第一本地域上的本地计算服务器资源；在所述单个本地计算资源内，实例化具有内嵌框架和不可见窗口的中继机制；在所述单个本地计算资源内，实例化第二本地域上的本地web服务器；将服务工作者安装在所述不可见窗口上；在所述本地web服务器处接收对信息的请求；验证所述第一本地域上所述本地计算服务器资源的存在；将所述第二本地域通信地连接到所述内嵌框架；以及经由所述至少一个联网模块，使用所述中继机制在所述第一本地域上的所述本地计算服务器资源与所述第二本地域上的所述本地web服务器之间直接传送至少一个消息。

[0216] 示例B-2可以包括如示例B-1以及可替代地或另外地本文中的任何其他示例所述的主题，其中，提供所述单个本地计算资源包括将所述单个本地计算资源布置为传输控制协议(TCP)服务器。

[0217] 示例B-3可以包括如示例B-1至B-2中任一项以及可替代地或另外地本文中的任何其他示例所述的主题，进一步包括：在所述本地web服务器处执行至少一个内核级动作，所述内核级动作由从所述单个本地计算资源接收到的命令引导。

[0218] 示例B-4可以包括如示例B-1至B-3中任一项以及可替代地或另外地本文中的任何其他示例所述的主题，进一步包括：在所述第一本地域上打开第一浏览器窗口，所述第一浏览器窗口与所述本地计算服务器资源相关联；在所述第二本地域上打开第二浏览器窗口，所述第二浏览器窗口与所述本地web服务器相关联；从所述第一浏览器窗口和所述第二浏览器窗口中的一个浏览器窗口收集特定数据；以及在所述第一浏览器窗口和所述第二浏览器窗口中的另一个浏览器窗口处显示所述特定数据中的至少一些数据，所述特定数据中的所述至少一些数据与所述至少一个消息一起传递。

[0219] 示例B-5可以包括如示例B-1至B-4中任一项以及替代性地或另外地本文中的任何其他示例所述的主题，其中，所述特定数据中的至少一些数据是JavaScript命令。

[0220] 示例C-1是一种改进的计算系统，包括：至少一个处理器；至少一个联网模块；存储器，所述存储器具有存储于其上的被格式化用于由所述至少一个处理器执行的软件指令，所述软件指令被布置为：初始化改进的web浏览器，所述改进的web浏览器包括改进的浏览器引擎；经由所述改进的浏览器引擎实例化第一域上的传输控制协议(TCP)服务器；经由所述改进的浏览器引擎实例化第二域上的本地计算服务器资源，所述第二域与所述第一域具有不同的网络标识符；经由所述改进的浏览器引擎实例化至少一个本地运行时环境容器；将包括存储器的特定本地计算资源分配给所述至少一个本地运行时环境容器；向所述本地计算服务器资源和所述至少一个本地运行时环境容器授予对所述特定本地计算资源的访问权；将所分配的特定本地计算资源与所述改进的计算系统的其他功能隔离开；以及通过所述至少一个本地运行时环境容器，使用所述中继机制在所述第一本地域上的所述本地计算服务器资源与所述第二本地域上的所述本地web服务器之间直接传送消息。

[0221] 示例C-2可以包括如示例C-1以及可替代地或另外地本文中的任何其他示例所述的主题，其中，当至少一个消息在所述第一本地域上的所述本地计算服务器资源与所述第二本地域上的所述本地web服务器之间直接传送时，所述改进的计算系统不进行因特网访问。

[0222] 示例C-3可以包括如示例C-1至C-2中任一项以及可替代地或另外地本文中的任何其他示例所述的主题，其中，所述至少一个本地运行时环境容器被布置为托管Node.js运行时环境。

[0223] 示例C-4可以包括如示例C-1至C-3中任一项以及可替代地或另外地本文中的任何其他示例所述的主题，其中，所述改进的计算系统是台式计算机或膝上型计算机。

[0224] 示例C-5可以包括如示例C-1至C-4中任一项以及可替代地或另外地本文中的任何其他示例所述的主题，其中，所述改进的web浏览器的JavaScript解释器可以可选地确定是本地处理JavaScript还是远程处理JavaScript。

[0225] 本申请要求于2021年2月16日提交的美国临时申请号63 / 149,664的权益，该申请通过引用以其全文并入本文。

[0226] 上述各种实施例可以被组合以提供另外的实施例。实施例的各种特征是可选的，并且一个实施例的特征可以适当地与其他实施例组合。如果有必要，则可以对实施例的各方面进行修改以采用各个专利、申请和出版物的概念来提供另外的实施例。

[0227] 在本文的描述中，阐述了具体细节以便提供对各种示例实施例的全面理解。应当理解，对实施例的各种修改对于本领域技术人员来说将是显而易见的，并且在不脱离本公开的精神和范围的情况下，本文定义的一般原理可以应用于其他实施例和应用。此外，在以下描述中，出于解释的目的，阐述了许多细节。然而，本领域的普通技术人员应当理解，可以在不使用这些具体细节的情况下实践实施例。在其他情况下，没有示出或描述众所周知的结构和过程，以便避免描述被不必要的细节模糊。因此，本公开不旨在受限于所示实施例，而是旨在符合与本文所公开的原理和特征一致的最大范围。因此，鉴于以上详细描述，可以对实施例作出这些和其他改变。通常，在所附权利要求中，所使用的术语不应当被解释为将权利要求限制于本说明书中公开的具体实施例，而是应当被解释为包括所有可能的实施例以及这种权利要求有权获得的等效物的整个范围。因此，权利要求不受本公开限制。< / script> < / response> < / boolean>

Claims

1. An improved computing system, comprising: At least one processor; At least one networking module; A memory having software instructions stored thereon that are formatted for execution by the at least one processor, the software instructions being arranged to: Operate local computing server resources on a first local domain; Instantiate a relay mechanism having an embedded frame and an invisible window; Instantiate a local web server on a second local domain; Open a first browser window on the first local domain, the first browser window being associated with the local computing server resources; Open a second browser window on the second local domain, the second browser window being associated with the local web server; Collect data from one of the first browser window and the second browser window; Install a service worker on the invisible window; Receive a request for information at the local web server; Verify the existence of the local computing server resources on the first local domain; Communicatively connect the second local domain to the embedded frame; Via the at least one networking module, directly transfer at least one message between the local computing server resources on the first local domain and the local web server on the second local domain using the relay mechanism, and display at least some of the data at the other browser window of the first browser window and the second browser window, the at least some of the data being passed together with the at least one message.

2. The improved computing system according to claim 1, wherein, The local computing server resources are arranged as a Transmission Control Protocol (TCP) server.

3. The improved computing system according to claim 1, wherein, The local web server is instantiated inside a secure container.

4. The improved computing system according to claim 3, wherein, At least a portion of the relay mechanism is included inside the secure container.

5. The improved computing system according to claim 3, wherein, The secure container is arranged to host at least one Node.js process.

6. The improved computing system according to claim 1, wherein, The local web server is arranged to handle Hypertext Transfer Protocol (HTTP) communications.

7. The improved computing system according to claim 1, wherein, The local web server is arranged to handle web socket communications.

8. The improved computing system according to claim 1, wherein, The local web server is arranged to handle JavaScript commands.

9. The improved computing system according to claim 1, wherein, The local computing server resources are accessible via the first browser window, and the local web server is accessible via the second browser window.

10. The improved computing system according to claim 1, wherein, The local computing server resources are arranged with at least one kernel-level interface, the at least one kernel-level interface being arranged to boot the operation of one or more kernel-level functions.

11. An improved computing method, comprising: Provide a single local computing resource having at least one networking module; Within the single local computing resource, operate local computing server resources on a first local domain; Within the single local computing resource, instantiate a relay mechanism having an embedded frame and an invisible window; Within the single local computing resource, instantiate a local web server on a second local domain; Install a service worker on the invisible window; Receive a request for information at the local web server; Verify the existence of the local computing server resources on the first local domain; Open a first browser window on the first local domain, the first browser window being associated with the local computing server resource; Open a second browser window on the second local domain, the second browser window being associated with the local web server; Collect data from one of the first browser window and the second browser window; Communicatively connect the second local domain to the inline frame; Via the at least one networking module, directly transmit at least one message between the local computing server resource on the first local domain and the local web server on the second local domain using the relay mechanism; And Display at least some of the data at the other browser window of the first browser window and the second browser window, the at least some of the data being passed together with the at least one message.

12. The improved calculation method according to claim 11, wherein, Providing the single local computing resource includes arranging the single local computing resource as a Transmission Control Protocol (TCP) server.

13. The improved computing method according to claim 11, further comprising: Perform at least one kernel-level action at the local web server, the kernel-level action being guided by a command received from the single local computing resource.

14. The improved calculation method according to claim 11, wherein, At least some of the data are JavaScript commands.

Images