Remote System Update Without Inbound Connection
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current system software and firmware updating methods require a direct connection to the target device, increasing the risk of external security threats and limiting remote updating capabilities, especially for secure systems that do not allow external parties to initiate connections.
Innovation Solution
A computer-implemented method that allows remote scheduling and monitoring of system updates without initiating a connection to the target system, using input data such as code level, scheduled time, and authorization data provided via a channel external to the target system, enabling remote service updates and progress monitoring without establishing a connection.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If a direct connection is established to the target device for remote updating, then updating capability is improved, but security risk increases
Solution Approach 1:
Instead of the remote device initiating a connection to the target device (traditional client-server model), the patent inverts the approach by having the target device proactively send update information and status data back to the remote device. This reversal eliminates the need for the target device to accept external connection requests, thereby maintaining security while enabling remote updating capability.
Solution Approach 2:
The patent introduces an intermediary communication mechanism where the target device actively pushes update information and status data to the remote device through predefined channels. This intermediary approach allows information exchange without requiring the target device to open inbound connections, thus resolving the contradiction between remote access capability and security.
2Loss of information
If a direct connection is established to monitor update progress, then monitoring capability is improved, but connection security risk increases
Solution Approach 1:
For monitoring update progress, the patent inverts the traditional monitoring approach by having the target device actively send status data back to the remote device rather than the remote device querying the target device. This ensures that the target device maintains control over its connections while still providing comprehensive update progress information to the service representative.
Solution Approach 2:
The target device performs self-service by automatically sending update status information to the remote device without requiring external queries. This autonomous behavior enables the remote device to monitor update progress while the target device maintains its security posture by not opening inbound connections.
3Adaptability or versatility
If the device accepts external direct connection requests, then remote access is enabled, but vulnerability to security threats increases
Solution Approach 1:
The patent fundamentally inverts the remote access paradigm by eliminating inbound connection requests from external devices. Instead, the target device proactively initiates communication to send update information and status data, thereby maintaining security while enabling remote access capability through a reversed communication flow.
Solution Approach 2:
The patent employs an intermediary communication mechanism where the target device pushes information to the remote device through secure channels without accepting inbound connections. This intermediary approach enables remote access versatility while maintaining security by keeping the target device's connection posture closed.
Data Source
AI summary
In an approach, a processor receives input data comprising: (i) a code level for an update, (ii) a scheduled time for the update; (iii) a target system for the update, and (iv) authorization data, where the authorization data: (i) allows for scheduling of the update and (ii) is provided via a channel external from a connection to the target system without an inbound connection. A processor receives a set of data from the target system. A processor, responsive to receiving the set of data from the target system, sends a response packet to the target system that includes the input data. A processor receives, at the scheduled time, a request to process the update. A processor, responsive to the request, sends code for processing the update corresponding to the code level for the update. A processor receives status messages corresponding to progress of the update.


