On-demand server-less container-based storage transfer
By using containers for data transmission in a private cloud environment, the problems of slow transmission speed and data leakage in traditional methods are solved, achieving efficient and secure data transmission and meeting the security needs of organizations that process sensitive information.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2024-07-26
- Publication Date
- 2026-03-13
AI Technical Summary
Existing technologies for transmitting data in private cloud environments are slow and pose a risk of data leakage, failing to effectively meet the security needs of organizations that process sensitive information.
It adopts an on-demand, serverless container-based storage transfer method, which instantiates containers in a private cloud environment to transfer data, ensuring that data does not directly access local storage during the transfer process. It uses a unique CA certificate to establish a secure connection, enabling portable and scalable data transfer between multiple devices.
It enables efficient and secure data transmission in a private cloud environment, ensuring device security and data privacy, avoiding the problems of slow transmission speed and data leakage in traditional methods, and providing a flexible data transmission solution.
Smart Images

Figure CN121666746A_ABST
Abstract
Description
Technical Field
[0001] This disclosure relates to container-based storage delivery for on-demand serverless systems. Background Technology
[0002] Organizations such as military units and healthcare providers must meet compliance and regulatory requirements regarding data management. For these organizations, minimizing exposure to attacks and data breaches is crucial. One solution for these organizations to meet compliance requirements is through the implementation of a private cloud, also known as a Distributed Cloud Hosting (DCH), which is a fully self-contained and air-gapped platform that does not require internet connectivity. A private cloud allows customers to manage data, services, infrastructure, APIs, and / or tools without unnecessarily exposing them to external entities.
[0003] A private cloud typically comprises one or more central data centers communicatively coupled to tactical edge devices (also known as equipment). For example, in a military environment, the data center may be deployed in a central location, such as a base, and the tactical edge devices may include drones, vehicles, portable stations, etc. Tactical edge devices can disconnect from and reconnect to the data center over time (e.g., a drone may disconnect from the data center when deployed and be reconnected when returning). Summary of the Invention
[0004] One aspect of this disclosure provides a computer-implemented method for container-based, serverless, on-demand storage delivery. The computer-implemented method is executed by data processing hardware that performs operations including receiving a request to transfer data from a first device to a second device. The first device is hosted in a private cloud, and the private cloud is isolated from the Internet. The operations also include determining that the first device is communicatively connected to the private cloud. The operations include instantiating a container at the first device in response to determining that the first device is communicatively connected to the private cloud, the container being configured to receive data from the first device without direct access to the first device's local storage. The operations also include using the container to transfer data from the first device to the second device.
[0005] Implementations of this disclosure may include one or more of the following optional features. In some implementations, the second device is hosted in a private cloud. In these implementations, the second device may include a data center. In these implementations, the first device may include an edge device of the private cloud, which includes one or more of a drone, a smartphone, a laptop, or an in-vehicle computer in a vehicle.
[0006] In some implementations, the second device is not hosted on a private cloud. In these implementations, the operation may further include determining that the first device is communicatively coupled to the second device via a network, and instantiating a container on the first device in response to determining that the first device is communicatively coupled to the second device via a network. In these implementations, the network may include an internet connection.
[0007] A container can be instantiated at a first device using a first Certificate Authority (CA) certificate. Further, the container can use a second CA certificate to transfer data to a second device. The first CA certificate and the second CA certificate can be different. In some implementations, the operation further includes determining that the first device is not communicatively connected to the private cloud before determining that the first device is communicatively connected to the private cloud, wherein determining that the first device is communicatively connected to the private cloud includes determining that the first device has become communicatively connected to the private cloud after determining that the first device is not communicatively connected to the private cloud.
[0008] Another aspect of this disclosure provides a system for container-based storage delivery in a serverless, on-demand manner. The system includes data processing hardware and memory hardware communicating with the data processing hardware. The memory hardware stores instructions that, when executed on the data processing hardware, cause the data processing hardware to perform operations. The operations include receiving a request to transfer data from a first device to a second device. The first device is hosted in a private cloud, and the private cloud is isolated from the internet. The operations also include determining that the first device is communicatively connected to the private cloud. The operations include instantiating a container at the first device in response to determining that the first device is communicatively connected to the private cloud, the container being configured to receive data from the first device without direct access to the first device's local storage. The operations also include using the container to transfer data from the first device to the second device.
[0009] This aspect may include one or more of the following optional features. In some implementations, the second device is hosted in a private cloud. In these implementations, the second device may include a data center. In these implementations, the first device may include an edge device of the private cloud, which includes one or more of a drone, a smartphone, a laptop, or an in-vehicle computer in a vehicle.
[0010] In some implementations, the second device is not hosted on a private cloud. In these implementations, the operation may further include determining that the first device is communicatively coupled to the second device via a network, and instantiating a container on the first device in response to determining that the first device is communicatively coupled to the second device via a network. In these implementations, the network may include an internet connection.
[0011] A container can be instantiated at a first device using a first Certificate Authority (CA) certificate. Further, the container can use a second CA certificate to transfer data to a second device. The first CA certificate and the second CA certificate can be different. In some implementations, the operation further includes determining that the first device is not communicatively connected to the private cloud before determining that the first device is communicatively connected to the private cloud, wherein determining that the first device is communicatively connected to the private cloud includes determining that the first device has become communicatively connected to the private cloud after determining that the first device is not communicatively connected to the private cloud.
[0012] Details of one or more implementations of this disclosure are set forth in the accompanying drawings and the description below. Other aspects, features, and advantages will become apparent from the specification, drawings, and claims. Attached Figure Description
[0013] Figure 1 This is a schematic diagram of an example system for on-demand serverless container-based storage delivery.
[0014] Figure 2 This is a schematic diagram of an example device connected to an example private cloud.
[0015] Figure 3 This is a schematic diagram of an example sequence diagram for on-demand serverless container-based storage delivery.
[0016] Figure 4 This is a flowchart illustrating an example layout of an operation for a serverless, container-based storage delivery method.
[0017] Figure 5 This is a schematic diagram of an example computing device that can be used to implement the systems and methods described herein.
[0018] In the various figures, the same reference numerals indicate the same elements. Detailed Implementation
[0019] A private cloud is an isolated environment comprising cloud computing services and locally hosted infrastructure. In other words, a private cloud is self-contained and inaccessible to devices outside the private cloud (e.g., via the internet), although some devices originating from the private cloud may be adapted to communicate with devices outside the private cloud environment. Private clouds are particularly useful for organizations that process sensitive information, such as healthcare providers and military units. A private cloud can include multiple hardware devices communicatively coupled within the private cloud environment. Example hardware devices that can be deployed in a private cloud include data centers acting as central data repositories and computing centers, as well as edge devices (which may also be referred to interchangeably herein as “devices”), which are typically smaller devices that can connect / disconnect from the private cloud environment when necessary. For example, in a private cloud deployed within a military environment, edge devices could include drones and / or computing devices deployed on vehicles such as tanks.
[0020] Transferring data between devices in a private cloud environment differs from transferring data in a regular cloud environment. Typically, internet-based clouds implement a control plane to transfer data between devices. However, since private clouds generally do not have internet access, such a control plane is unavailable in a private cloud environment. Instead, private clouds typically perform data transfer between devices by cloning and / or performing binary file transfers. However, this method of transferring data between devices can be slow and may also expose the local device storage between devices during the transfer.
[0021] The implementation described herein relates to container-based storage delivery in a serverless, on-demand environment (i.e., in a private cloud). In other words, this disclosure provides a method for transferring data between various devices in a private cloud environment using containers. Unlike previous data transfer methods, the container-based method keeps devices secure throughout the data transfer process because the containers do not directly access the local storage of any device. Instead, a container is instantiated at a first device to receive data from the first device, and then a second device retrieves the data from the container. Throughout the data transfer process, the data transfer using containers can be completed without exposing the local storage of either the first or second device. Furthermore, the container-based data transfer process of this disclosure is portable, reproducible, and scalable, allowing it to run simultaneously on multiple devices and / or operating systems.
[0022] refer to Figure 1In some implementations, the on-demand serverless container-based storage delivery system 100 includes a private cloud 140 communicatively coupled to edge devices 110 and data center 120 via a dedicated network 130 (e.g., a local area network (LAN) and / or a wide area network (WAN)). The private cloud 140, including the connected devices 110 and 120, can be isolated from devices outside the private cloud 140 (i.e., the private cloud 140 is not connected to the Internet or any other network connection). Therefore, network 130 can be a secure, dedicated network connecting various devices 110 and 120 via wired and / or wireless connections. The private cloud 140 can be a distributed system with scalable / elastic resources 142. Resources 142 include computing resources 144 (e.g., data processing hardware) and / or storage resources 146 (e.g., memory hardware such as volatile and / or non-volatile addressable semiconductor memories). Edge devices 110 and data center 120 can access and use resources 142. In some implementations, the private cloud 140 executes a transport module 145 that manages the transport of data 50 between various devices in the private cloud (i.e., edge device 110 and data center 120).
[0023] In some implementations, the private cloud 140 is an isolated environment comprising cloud computing services and locally hosted infrastructure. The private cloud 140 can be deployed by organizations requiring stringent security for data 50, such as military units or hospitals. Edge devices 110 and data centers 120 can be any devices suitable for an organization to deploy the private cloud 140 within them. Specifically, edge devices 110 can refer to any portable device and / or device that can connect to / disconnect from the private cloud 140. For example, edge devices 110 can be any of a tablet, smartphone, smartwatch, drone, vehicle-mounted computer, or any other suitable portable computing device. Furthermore, data centers 120 can be fixed installations containing greater processing and storage capacity, such as a single computer or a computer cluster. The private cloud 140 can host any number of edge devices 110 and / or data centers 120, although for simplicity... Figure 1 It only includes one of each.
[0024] Private cloud 140 is configured for on-demand, serverless, container-based delivery of data 50 between devices 110 and 120 within private cloud 140. Generally, private cloud 140 is responsible for securely delivering data 50 between devices 110 and 120 via delivery module 145. Specifically, delivery module 145 implements container 150 during data delivery, such that delivery module 145 does not access the local storage of either device 110 or 120 during the data 50 delivery process. Container 150 is a software package containing all the necessary elements to run in any environment (i.e., private cloud 140) through a virtualized operating system. In other words, container 150 functions as a computing unit that can be instantiated at any of devices 110, 120, and / or private cloud 140. Container 150 allows for easy sharing of CPU, memory, storage, and network resources at the operating system level and provides a logical packaging mechanism in which applications can be abstracted from the environment in which they actually run (i.e., devices 110 and 120). By using a container-based process to transfer data 50, the transfer module 145 can simultaneously initiate multiple transfers within the private cloud 140 (i.e., instantiate the container 150 at various devices 110, 120). Furthermore, the transfer module 145 is portable and scalable because it can easily adapt the container 150 for various devices 110, 120 of the private cloud 140 without requiring manual intervention (i.e., code rewriting) or processing power.
[0025] In the example container-based transfer of data 50, the transfer module 145 may receive a request 30 instructing that data 50 be transferred from edge device 110 to data center 120. The transfer module 145 may only accept request 30 if it is provided by a user authorized to access private cloud 140. For example, the transfer module 145 may include role-based access control (RBAC) to determine whether request 30 originates from an authorized user. Furthermore, request 30 may be received at a transfer device (e.g., edge device 110 in this example) or a receiving device (e.g., data storage 120 in this example). In some implementations, the transfer module 145 defines restrictions for the transfer of data 50, such as maximum memory, CPU, and / or network limits. Therefore, request 30 must comply with the restrictions defined by the transfer module 145; otherwise, the transfer module 145 rejects request 30.
[0026] In some implementations, each device 110, 120 of the private cloud 140 may correspond to a CA certificate, enabling the delivery module 145 to establish a secure connection with the corresponding device 110, 120 when communicating with it. In this example, the delivery module 145 may establish a secure connection with the edge device 110 based on the corresponding CA certificate and then transmit a request 30 to the edge device 110, allowing the edge device 110 to select appropriate data 50 to upload to the container 150. If the edge device 110 is connected to the private cloud 140 (i.e., connected to the network 130), the delivery module 145 instantiates the container 150 at the edge device 110. If the edge device 110 is not connected to the private cloud 140 (i.e., disconnected from the network 130), the delivery module 145 periodically (e.g., at regular or irregular intervals, such as once a minute, once an hour, once a day, etc.) checks to see if the edge device 110 is connected. The delivery module 145 can create files (e.g., YAML files) containing specific details about the source and destination (i.e., source type, destination type, source path, destination path, source and destination access credentials, source and destination custom CA certificates). Once the delivery module 145 instantiates the container 150 at the edge device 110, the edge device 110 uploads data 50 to the container 150. In some implementations, the delivery module 145 schedules the delivery of data 50 based on the needs of system 100. For example, if devices 110 and 120 are in use or in a low-power mode, the delivery module 145 can initiate (and / or schedule) the delivery of data 50 at a later time. The delivery module 145 can then deploy the container 150 at data center 120 so that data center 120 can retrieve data 50 from the container 150. In some implementations, before deploying the container 150 at data center 120, the delivery module 145 first checks to ensure that data center 120 is connected to private cloud 140 (i.e., connected to network 130).
[0027] The delivery module 145 can also monitor the delivery of data 50 from edge device 110 to data center 120. For example, if container 150 crashes (i.e., suffers a software or hardware failure), the delivery module 145 can instantiate a new container 150. In some implementations, the delivery module 145 includes a limit on retry attempts (i.e., the maximum number of times container 150 crashes). In some implementations, the delivery module 145 monitors the progress of data delivery from the source device (i.e., edge device 110) to container 150. In some of these implementations, if the source device loses connection to network 130 midway through the delivery of data 50, the delivery module 145 restarts the upload once the source device reconnects to network 130 from the point of failure, without having to restart the entire upload of data 50. The delivery module 145 can track the progress of data 50 delivery by running a description of the job or by analyzing pod logs.
[0028] Although the example shown depicts edge device 110 providing data 50 and data center 120 receiving data 50, in reality, either entity can provide and / or receive data 50 via transmission module 145. Furthermore, Figure 1 The example system 100 is not intended to be restrictive and may include multiple edge devices 110 and data center 120. Therefore, any number of additional devices 110, 120 hosted by the private cloud 140 can transmit and / or receive data 50 via the transport module 145. The private cloud 140 then allows data 50 to be transferred between devices 110, 120 of the private cloud 140 via the transport module 145 without exposing devices 110, 120 to external entities. Furthermore, because the transport module 145 implements container 150 during data 50 transmission, the transport module 145 does not need to access the local storage of any of the devices 110, 120 during data 50 transmission. All communication between the transport module 145, container 150, and the various devices 110, 120 can be protected using CA certificates as an additional layer of security.
[0029] Figure 2This is a schematic diagram 200 of an example device 110 connected to an example private cloud 140. As described above, the private cloud 140 can host multiple devices, including any number of edge devices 110. In an example of a private cloud environment for a military unit, the edge devices may include drones 110, 110A and military vehicles 110, 110B. These edge devices 110 can be configured to connect to and disconnect from the private cloud 140 as needed. For example, drone 110A can be deployed to take pictures of remote areas. When drone 110A is in the field, it can disconnect from the private cloud 140. Furthermore, drone 110A can sometimes connect to the Internet 220. For example, if drone 110A captures images that need to be urgently shared without being connected to the private cloud 140, the drone can initiate a data transmission via the Internet 220 (e.g., via a broadband cellular network, etc.). Drone 110A can transmit data 50 using container 150 via transmission module 145. Figure 1 Furthermore, vehicle 110B or any other suitable edge device 110 (e.g., smartphone, tablet, laptop, smartwatch, in-vehicle computer) can be similarly configured to repeatedly connect and disconnect from private cloud 140 and / or Internet 220 as needed for operation.
[0030] In some implementations, each edge device 110 may include a CA certificate 210 issued by a Certificate Authority (CA). A CA certificate 210 is a digital certificate that proves ownership of the public key by the naming subject of the certificate, thereby allowing other parties to trust the corresponding device (i.e., edge device 110) (and / or be trusted by the corresponding device (i.e., edge device 110)). For example, a drone 110A corresponds to a first CA certificate 210, 210A, and a vehicle 110B corresponds to a second CA certificate 210, 210B. Here, certificates 210A, 210B and any other corresponding certificates 210 corresponding to other devices 110 in the private cloud 140 are distinct.
[0031] In conventional private cloud implementations, each device 110 in the private cloud typically uses the same CA certificate 210. Since these implementations transfer data between devices 110 via cloning and / or binary data transfer, a single CA certificate 210 may be sufficient. In the present disclosure, assigning each device a unique CA certificate 210 allows data 50 to be transferred via container 150. Here, each time the transfer module 145 communicates with edge device 110 (or data center 120), the transfer module 145 is able to establish a secure connection (to instantiate and / or deploy container 150) using the unique CA certificate 210 of the corresponding device 110. In other words, container 150 uses the unique CA certificate 210 to read data 50 and transfer data 50 to devices 110 and 120.
[0032] Figure 3 This is a schematic diagram of sequence diagram 300 for on-demand serverless container-based storage delivery. In step 302, user 305 requests data delivery. For example, user 305 sends a request 30 indicating that data 50 from first device 110 is to be delivered to second device 120. Figure 1 Request 30 may instruct data 50 to be transferred from any device in the private cloud 140 (i.e., edge device 110 or data center 120) to any one or more other devices 110, 120 in the private cloud 140. In example sequence diagram 300, the request is for data 50 to be transferred from edge device 110 to data center 120. In some implementations, the transfer module 145 accepts or rejects the request based on multiple characteristics. For example, the transfer module 145 determines that the user 305 associated with request 30 has permission to request 30. In some implementations, request 30 must meet certain conditions, such as maximum memory, maximum CPU usage, maximum network limits, etc. Conditions may be set to default / preset values or user-defined values.
[0033] In step 304, the transmission module 145 determines whether the edge device 110 is connected to the private cloud 140. In some implementations, when data 50 is to be transmitted from the edge device 110 to a device outside the private cloud 140 (e.g., transmitted to an external device via the Internet), the transmission module 145 may determine whether the edge device is connected to the external device / network. If the edge device 110 is not connected to the private cloud 140 (or the external network), the transmission module 145 may periodically recheck to see if the edge device 110 has been reconnected.
[0034] In step 306, the delivery module 145 instantiates container 150 at edge device 110. In some implementations, the delivery module 145 schedules (i.e., for a future point in time) the delivery of data based on network resources, the size of the request, the state of the source device and / or destination device, or any other suitable basis. Therefore, in these implementations, the delivery module 145 does not instantiate container 150 at edge device 110 until the scheduled time. In step 308, edge device 110 delivers the requested data to container 150. Here, container 150 cannot access the local storage of edge device 110. Alternatively, edge device 110 is configured to upload appropriate data 50 to container 150. In some implementations, the delivery module 145 monitors the delivery of data 50. In the event of a crash or any other failure of container 150, the delivery module 145 is configured to allow automatic fault recovery, such as by instantiating a new container 150. The delivery module 145 may include a maximum number of attempts to complete the delivery of data 50 before rejecting request 30. Furthermore, the transmission module can monitor the progress of data 50 upload, such as by running a description about the upload or by tracking pod logs. If the edge device 110 loses connection to the private cloud 140 during the upload, the transmission module 145 can resume the upload once the edge device 110 reconnects to the private cloud 140, without having to completely restart the transmission of data 50.
[0035] In step 310, the transmission module 145 transmits data 50 to the data center 120 via container 150. For example, container 150 can establish a connection at data center 120 using CA certificate 210 unique to data center 120, and then transmit data accordingly. In step 312, data center 120 retrieves data 50 from container 150.
[0036] Figure 4 This is a flowchart illustrating an exemplary arrangement of the operation of a method 400 for on-demand serverless container-based storage delivery. Method 400 can be provided by, for example... Figure 1 System 100 components and / or Figure 5The method is executed by various interconnected computing devices of computing device 500. In operation 402, method 400 includes receiving a request 30 to transfer data 50 from a first device 110 to a second device 120, the first device 110 being hosted at a private cloud 140 isolated from the Internet. In operation 404, method 400 includes determining that the first device 110 is communicatively connected to the private cloud 140. In response to operation 404, in operation 406, method 400 includes instantiating a container 150 at the first device 110, the container 150 being configured to receive data 50 from the first device 110 without direct access to the local storage of the first device 110. In operation 408, method 400 includes using container 150 to transfer data 50 from the first device 110 to the second device 120.
[0037] Figure 5 This is a schematic diagram of an example computing device 500 that can be used to implement the systems and methods described in this document. The computing device 500 is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframes, and other suitable computers. The components shown herein, their connections and relationships, and their functions are intended to be exemplary only and are not intended to limit the implementations of the invention described and / or claimed in this document.
[0038] Computing device 500 includes a processor 510, memory 520, storage device 530, a high-speed interface / controller 540 connected to memory 520 and high-speed expansion port 550, and a low-speed interface / controller 560 connected to low-speed bus 570 and storage device 530. Each of components 510, 520, 530, 540, 550, and 560 is interconnected using various buses and may be mounted on a common motherboard or otherwise. Processor 510 can process instructions for execution within computing device 500, including instructions stored in memory 520 or storage device 530, to display graphical information of a graphical user interface (GUI) on an external input / output device, such as a display 580 coupled to high-speed interface 540. In other implementations, multiple processors and / or multiple buses, as well as multiple memories and various types of memory, may be used as appropriate. Additionally, multiple computing devices 500 may be connected, with each device providing a portion of the necessary operation (e.g., as a server group, blade server cluster, or multiprocessor system).
[0039] Memory 520 stores information non-temporarily within computing device 500. Memory 520 may be a computer-readable medium, a volatile memory cell, or a non-volatile memory cell. Non-temporary memory 520 may be a physical means for temporarily or permanently storing programs (e.g., instruction sequences) or data (e.g., program state information) for use by computing device 500. Examples of non-volatile memory include, but are not limited to, flash memory and read-only memory (ROM) / programmable read-only memory (PROM) / erasable programmable read-only memory (EPROM) / electronically erasable programmable read-only memory (EEPROM) (e.g., commonly used in firmware, such as boot programs). Examples of volatile memory include, but are not limited to, random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), phase-change memory (PCM), and magnetic disks or magnetic tapes.
[0040] Storage device 530 provides mass storage for computing device 500. In some implementations, storage device 530 is a computer-readable medium. In various implementations, storage device 530 may be a floppy disk device, hard disk device, optical disk device, magnetic tape device, flash memory or other similar solid-state storage device, or device array (including devices arranged in a storage area network or other configuration). In additional implementations, a computer program product is tangibly embodied in an information carrier. The computer program product contains instructions that, when executed, perform one or more methods, such as those described above. The information carrier is a computer or machine-readable medium, such as memory 520, storage device 530, or memory on processor 510.
[0041] High-speed controller 540 manages bandwidth-intensive operations of computing device 500, while low-speed controller 560 manages less bandwidth-intensive operations. This assignment of responsibilities is merely exemplary. In some implementations, high-speed controller 540 is coupled to memory 520, display 580 (e.g., via a graphics processor or accelerator), and high-speed expansion port 550 which accepts various expansion cards (not shown). In some implementations, low-speed controller 560 is coupled to storage device 530 and low-speed expansion port 590. Low-speed expansion port 590 (which may include various communication ports (e.g., USB, Bluetooth, Ethernet, Wireless Ethernet)) may be coupled to one or more input / output devices (such as keyboards, pointing devices, scanners) or networking devices (such as switches or routers) via, for example, a network adapter.
[0042] The computing device 500 can be implemented in many different forms, as shown in the figure. For example, it can be implemented as a standard server 500a or multiple times in a group of such servers 500a, as a laptop computer 500b, or as part of a rack server system 500c.
[0043] Various implementations of the systems and techniques described herein can be implemented in digital electronic and / or optical circuit systems, integrated circuit systems, specially designed ASICs (Application-Specific Integrated Circuits), computer hardware, firmware, software, and / or combinations thereof. These various implementations may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system, which includes at least one programmable processor, which may be dedicated or general-purpose and coupled to receive data and instructions from a storage system, at least one input device, and at least one output device, and to transfer data and instructions to the storage system, at least one input device, and at least one output device.
[0044] A software application (i.e., a software resource) can refer to computer software that instructs a computing device to perform a task. In some examples, a software application may be referred to as an "application," "app," or "program." Example applications include, but are not limited to, system diagnostic applications, system management applications, system maintenance applications, word processing applications, spreadsheet applications, messaging applications, media streaming applications, social networking applications, and game applications.
[0045] These computer programs (also referred to as programs, software, software applications, or code) include machine instructions for a programmable processor and can be implemented using high-level procedural and / or object-oriented programming languages and / or assembly / machine languages. As used herein, the terms “machine-readable medium” and “computer-readable medium” refer to any computer program product, non-transitory computer-readable medium, device, and / or apparatus (e.g., disk, optical disk, memory, programmable logic device (PLD)) used to provide machine instructions and / or data to a programmable processor, including machine-readable media that receive machine instructions as machine-readable signals. The term “machine-readable signal” refers to any signal used to provide machine instructions and / or data to a programmable processor.
[0046] The processes and logic flows described in this specification can be executed by one or more programmable processors (also known as data processing hardware) that execute one or more computer programs to perform functions by manipulating input data and generating output. The processes and logic flows can also be executed by special-purpose logic circuit systems, such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits). For example, processors suitable for executing computer programs include both general-purpose microprocessors and special-purpose microprocessors, as well as any one or more processors in any type of digital computer. Typically, the processor receives instructions and data from read-only memory or random access memory, or both. The basic elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include one or more mass storage devices for storing data, such as magnetic disks, magneto-optical disks, or optical disks, or operatively coupled to receive data from or transfer data to said mass storage device, or both. However, a computer need not have such devices. Computer-readable media suitable for storing computer program instructions and data include all forms of non-volatile memory, media, and memory devices, including, for example, semiconductor memory devices (e.g., EPROM, EEPROM, and flash memory devices), magnetic disks (e.g., internal hard disks or removable disks), magneto-optical disks, and CD-ROMs and DVD-ROMs. Processors and memory may be supplemented by or incorporated into dedicated logic circuitry systems.
[0047] To provide interaction with the user, one or more aspects of this disclosure can be implemented on a computer having a display device for displaying information to the user (e.g., a CRT (cathode ray tube), LCD (liquid crystal display) monitor, or touchscreen) and possibly a keyboard and pointing device (e.g., a mouse or trackball) through which the user can provide input. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback, such as visual, auditory, or tactile feedback; and input from the user can be received in any form, including sound, speech, or tactile input. Additionally, the computer can interact with the user by sending documents to and receiving documents from the device used by the user; for example, by sending a webpage to a web browser on the user's client device in response to a request received from a web browser.
[0048] Various implementations have been described. However, it should be understood that various modifications can be made without departing from the spirit and scope of this disclosure. Therefore, other implementations are within the scope of the following claims.
Claims
1. A computer-implemented method (400) executed by data processing hardware (510) to cause the data processing hardware (510) to perform operations, the operations comprising: Receive a request (30) to transmit data (50) from a first device (110) to a second device (120), the first device (110) being hosted in a private cloud (140) isolated from the Internet; It is determined that the first device (110) is communicatively connected to the private cloud (140); In response to determining that the first device (110) is communicatively connected to the private cloud (140), a container (150) is instantiated at the first device (110), the container (150) being configured to receive the data (50) from the first device (110) without directly accessing the local storage of the first device (110); and The container (15) is used to transfer the data (50) from the first device (110) to the second device (120).
2. The method (400) as described in claim 1, wherein, The second device (120) is hosted in the private cloud (140).
3. The method (400) as described in claim 2, wherein, The second device (120) includes a data center.
4. The method (400) as described in claim 3, wherein, The first device (110) includes an edge device of the private cloud (140), wherein the edge device includes one or more of the following: Drones; Smartphones; Laptop; or The vehicle's onboard computer.
5. The method (400) according to any one of claims 1 to 4, wherein, The second device (120) is not hosted on the private cloud (140).
6. The method (400) as claimed in claim 5, wherein: The operation further includes determining that the first device (110) is communicatively coupled to the second device (120) via a network (130); and Instantiating the container (150) at the first device (110) is in response to determining that the first device (110) is communicatively coupled to the second device (120) via the network (130).
7. The method (400) as claimed in claim 6, wherein, The network (130) includes an Internet connection.
8. The method (400) according to any one of claims 1 to 7, wherein, The container (150) is instantiated at the first device (110) using a first certificate authority CA certificate (210A).
9. The method (400) as claimed in claim 8, wherein, The container (150) uses a second CA certificate (210B) to transmit the data (50) to the second device (120).
10. The method (400) according to any one of claims 1 to 9, wherein, The operation further includes: determining that the first device (110) is not communicatively connected to the private cloud (140) before determining that the first device (110) is communicatively connected to the private cloud (140), wherein determining that the first device (110) is communicatively connected to the private cloud (140) includes determining that the first device (110) has become communicatively connected to the private cloud (140) after determining that the first device (110) is not communicatively connected to the private cloud (140).
11. A system (100) comprising: Data processing hardware (510); as well as A memory hardware (520) communicating with the data processing hardware (510), the memory hardware (520) storing instructions that, when executed on the data processing hardware (510), cause the data processing hardware (510) to perform operations, the operations including: Receive a request (30) to transmit data (50) from a first device (110) to a second device (120), the first device (110) being hosted in a private cloud (140) isolated from the Internet; It is determined that the first device (110) is communicatively connected to the private cloud (140); In response to determining that the first device (110) is communicatively connected to the private cloud (140), a container (150) is instantiated at the first device (110), the container (150) being configured to receive the data (50) from the first device (110) without directly accessing the local storage of the first device (110); and The container (15) is used to transfer the data (50) from the first device (110) to the second device (120).
12. The system (100) as claimed in claim 11, wherein, The second device (120) is hosted in the private cloud (140).
13. The system (100) as claimed in claim 12, wherein, The second device (120) includes a data center.
14. The system (100) as claimed in claim 13, wherein, The first device (110) includes an edge device of the private cloud (140), wherein the edge device includes one or more of the following: Drones; Smartphones; Laptop; or The vehicle's onboard computer.
15. The system (100) as claimed in any one of claims 11 to 14, wherein, The second device (120) is not hosted on the private cloud (140).
16. The system (100) of claim 15, wherein: The operation further includes determining that the first device (110) is communicatively coupled to the second device (120) via a network (130); and Instantiating the container (150) at the first device (110) is in response to determining that the first device (110) is communicatively coupled to the second device (120) via the network (130).
17. The system (100) as claimed in claim 16, wherein, The network (130) includes an Internet connection.
18. The system (100) as claimed in any one of claims 11 to 17, wherein, The container (150) is instantiated at the first device (110) using a first certificate authority CA certificate (210A).
19. The system (100) as claimed in claim 18, wherein, The container (150) uses a second CA certificate (210B) to transmit the data (50) to the second device (120).
20. The system (100) as claimed in any one of claims 11 to 19, wherein, The operation further includes: determining that the first device (110) is not communicatively connected to the private cloud (140) before determining that the first device (110) is communicatively connected to the private cloud (140), wherein determining that the first device (110) is communicatively connected to the private cloud (140) includes determining that the first device (110) has become communicatively connected to the private cloud (140) after determining that the first device (110) is not communicatively connected to the private cloud (140).