Remote system updating and monitoring

Abstract

A processor receives input data including: (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, wherein the authorization data: (i) permits scheduling of the update, and (ii) is provided via an external channel connected to the target system without an inbound connection. The processor receives a data set from the target system. In response to receiving the data set from the target system, the processor sends a response packet including the input data to the target system. The processor receives a request to process the update at the scheduled time. In response to the request, the processor sends code for processing the update corresponding to the code level for the update. The processor receives status messages corresponding to progress of the update.

Description

Technical Field

[0001] This invention generally relates to the field of system software / firmware updates, and more particularly to the remote scheduling and monitoring of updates to external systems without initiating a connection to the external system. Background Technology

[0002] Service representatives can maintain servers or other computing devices for client users. Typically, a service representative travels to a location to perform maintenance, updates, repairs, or other tasks associated with maintaining such computing devices. Some services, such as software or firmware updates, can be performed without the service representative physically traveling to the site.

[0003] The drawback of the current solution is that it requires a direct connection to the device being served, which increases the risk of external security threats compromising the device being served, as this solution requires the device being served to accept external direct connection requests. Summary of the Invention

[0004] According to some embodiments of the present invention, a computer-implemented method, computer program product, and computer system are provided. A processor receives input data including: (i) a code level for updating, (ii) a scheduling time for updating; (iii) a target system for updating; and (iv) authorization data, wherein the authorization data: (i) permits the update scheduling, and (ii) is provided via a channel other than a connection to the target system. The processor receives a dataset from the target system. In response to receiving the dataset from the target system, the processor sends a response packet including the input data to the target system. The processor receives a request to process the update at the scheduling time. In response to the request, the processor sends code for processing the update corresponding to the code level for updating. The processor receives a status message corresponding to the progress of the update. This method has the advantage of allowing remote service updates to the target system without requiring a connection to the target system from a remote device, and allows a remote device to monitor the update progress without establishing a connection to the target system.

[0005] According to other embodiments of the present invention, a computer-implemented method, computer program product, and computer system are provided. A processor receives input data copied from a first device, the input data including: (i) a code level for updating, (ii) a scheduling time for updating; (iii) a target system for updating, and (iv) authorization data, wherein the authorization data: (i) permits the update scheduling, and (ii) is provided via a channel other than the connection to the target system. The processor receives a dataset from a second computing device communicating with the target system. In response to receiving the dataset from the second computing device, the processor sends a response packet including the input data to the second computing device. The processor receives a request to process the update from the second computing device at the scheduling time. In response to the request, the processor sends code corresponding to the code level for updating to the second computing device for processing the update. The processor receives a status message from the second computing device corresponding to the progress of the update to the target system. This method has the advantage of allowing remote service updates to the target system without the remote device initiating a connection to the target system, and allows the remote device to monitor the update progress without establishing a connection to the target system. This method can enhance security and allows remote updates to target systems that do not accept connection requests initiated by external computing devices.

[0006] Embodiments of the present invention may optionally include a method in which a status message is attached to a remote support server request. This method has the advantage of allowing service representatives to view status updates associated with updates to the target device by accessing the remote support server request and any information attached to it, and thus monitoring updates to the target system without maintaining a connection to the target system.

[0007] Embodiments of the present invention may optionally include a method in which a dataset received from a target system is associated with a pre-scheduled, update-independent periodic connection. This method has the advantage of creating a window within which response packets including input data can be sent to the target system, enabling updates to the target system to be scheduled without requiring the remote system to initiate a connection to the target system. Attached Figure Description

[0008] Figure 1 A diagram depicting a computing environment according to an embodiment of the present invention.

[0009] Figure 2 Depicting an embodiment of the present invention in Figure 1 The flowchart illustrates the steps of the update monitoring program's scheduling request function, which is executed within the computing environment, for sending system update scheduling requests and receiving authorization for such requests.

[0010] Figure 3Depicting an embodiment of the present invention in Figure 1 A flowchart of the steps for scheduling and authorizing the update process within the computing environment, used to authorize and schedule system updates based on requests received from the scheduling request function in the return data packet.

[0011] Figure 4 Depicting an embodiment of the present invention in Figure 1 The flowchart illustrates the steps of an update process executed within a computing environment, used to initiate code loading or software / firmware update requests to the target server on a scheduled date and time, and to periodically send update status messages throughout the update process.

[0012] Figure 5 Depicting an embodiment of the present invention in Figure 1 The flowchart illustrates the steps of an update monitoring program executed within a computing environment to send system update codes and receive update status messages, thereby allowing users to monitor system updates of a target server from a remote location without initiating or establishing an external connection.

[0013] Figure 6 A block diagram depicting components of a service client device, a remote support server, a management console, and a target server according to an embodiment of the present invention. Detailed Implementation

[0014] Embodiments of the present invention recognize that securely scheduling and monitoring system code update processes can improve the efficiency of system updates that might otherwise have to be performed in person at the work site. Embodiments of the present invention recognize the existence of secure systems that do not allow external parties (service representatives, external computing systems, etc.) to initiate calls to the secure system. Embodiments of the present invention provide a method for remotely and securely scheduling and monitoring system code update processes without having to initiate a connection to schedule and / or monitor the target server.

[0015] The invention will now be described in detail with reference to the accompanying drawings.

[0016] Figure 1 A diagram depicts a computing environment 100 according to an embodiment of the present invention. Figure 1 The illustration is provided only as an example and does not imply any limitation on the environments in which different embodiments of the invention may be implemented.

[0017] In the described embodiments, computing environment 100 includes a service client device 110, a remote support server 115, and a management console 120 interconnected via network 105. Computing environment 100 also includes a management console 120 and a target server 125 interconnected via a direct connection or, in some embodiments, via a second network (e.g., an internal or private network).

[0018] It should be noted that, although Figure 1 The invention depicts a target server 125 and a management console 120 interconnected via a separate network; however, embodiments of the invention are contemplated where the management console 120 and the target server 125 are a single device, or where the management console 120 is the target server. Hereinafter, reference is made to embodiments including both the management console 120 and the target server 125. However, it is contemplated that interaction between the management console 120 and the target server 125 may not occur in all embodiments, and the update monitoring program 130 may communicate directly with the target server 125, and in such embodiments, the target server 125 may execute processes associated with the update program 145. Further, in the description... Figure 1 In the depicted embodiments, the service representative is described as interacting with the service client device 110. It should be noted that embodiments of the invention also anticipate embodiments where the service representative interacts directly with the remote support server 115. All of the above embodiments are within the scope of embodiments of the invention.

[0019] According to embodiments of the present invention, network 105 may be a local area network (LAN), a wide area network (WAN) (such as the Internet), a public switched telephone network (PSTN), any combination thereof, or any combination of connections and protocols that support communication between service client equipment 110, remote support server 115, and management console 120. Network 105 may include wired, wireless, or fiber optic connections. Computing environment 100 may include additional computing devices, servers, computers, mobile devices, or other devices not shown.

[0020] Remote support server 115 may be a management server, a web server, or any other electronic device or computing system capable of receiving and sending data. In some embodiments, remote support server 115 may be a laptop computer, tablet computer, netbook computer, personal computer (PC), desktop computer, or any programmable electronic device capable of communicating with service client device 110 and management console 120 via network 105. In other embodiments, remote support server 115 may represent a server computing system utilizing multiple computers as server systems, such as in a cloud computing environment. In another embodiment, remote support server 115 represents a computing system utilizing clustered computers and components as a single seamless resource pool. Remote support server 115 includes update monitoring program 130. Remote support server 115 may include, as per [the relevant documentation / information]... Figure 6 The components are described and illustrated in further detail.

[0021] Update monitoring program 130 operates to schedule software or firmware updates for a target device (e.g., target server 125) and subsequently receives progress status updates from the target device during the scheduled update. In some embodiments, update monitoring program 130 schedules updates and monitors update progress directly with target server 125. In other embodiments, management console 120 acts as an intermediary between remote support server 115 and target server 125, and target server 125 does not communicate directly with remote support server 115. In one embodiment, update monitoring program 130 resides on remote support server 115. In other embodiments, update monitoring program 130 may reside on another server or another computing device, as long as update monitoring program 130 can communicate with management console 120 and / or target server 125. In one embodiment, update monitoring program 130 includes two functions: a scheduling request function 135 and a monitoring function 140.

[0022] The scheduling request function 135 operates to receive system update details (e.g., scheduling date / time, authorization code / token, target server, version / code level) input by a service representative or management user (such as a service representative interacting with service client device 110) and returns these system update details to a management console (e.g., management console 120) communicating with the target server (e.g., target server 125). After receiving data (e.g., periodically sent system availability data) from management console 120, the scheduling request function 135 sends these system update details via a response packet. The scheduling request function 135 may further receive confirmation from management console 120 that the system update has been scheduled, and the scheduling request function 135 may store this confirmation in persistent storage on remote support server 115 or send the confirmation to service client device 110 for service representatives to access. In one embodiment, the scheduling request function 135 is a function of update monitoring program 130. In another embodiment, the scheduling request function 135 is a standalone program that executes on the remote support server 115 or another server or computing device, as long as the scheduling request function 135 can communicate with the service client device 110, the management console 120 and / or the target server 125.

[0023] When a system update occurs, monitoring function 140 operates to receive update status messages from target server 125, either directly or from management console 120. These status messages can be monitored by a service representative operating service client device 110 or remote support server 115. In one embodiment, the monitoring function is a function of update monitoring program 130. In another embodiment, the monitoring function is a standalone program executing on remote support server 115 or another server or computing device, provided that monitoring function 140 can communicate with service client device 110, management console 120, and / or target server 125.

[0024] Service client device 110 can be a laptop computer, netbook computer, tablet computer, PC, desktop computer, personal digital assistant (PDA), or smartphone. Typically, service client device 110 can be any electronic device or computing system capable of executing computer code and communicating with remote support server 115. Typically, service client device 110 is used by service representatives or other administrative users to input system update details to be copied to remote support server 115 for use by update monitoring program 130 and scheduling request function 135. Service client device 110 can also be used by such users to monitor status updates related to scheduled updates to target server 125. Service client device 110 may include, as referenced... Figure 6 The components are described and illustrated in further detail.

[0025] Management console 120 may be a management server, a web server, or any other electronic device or computing system capable of receiving and sending data. In some embodiments, management console 120 may be a laptop computer, tablet computer, netbook computer, PC, desktop computer, or any programmable electronic device capable of communicating with remote support server 115 via network 105 and with target server 125 via another network or a direct connection. In other embodiments, management console 120 may represent a server computing system utilizing multiple computers as server systems, such as in a cloud computing environment. In another embodiment, management console 120 represents a computing system utilizing clustered computers and components as a single seamless resource pool. Management console 120 includes updater 145. In some embodiments, management console 120 generally operates to manage target server 125, thereby allowing system administrators to manage, monitor, and service target server 125 that remote users may not be able to access via network 105. Management console 120 may include, for example, updates related to... Figure 6 The components are described and illustrated in further detail.

[0026] The target server 125 may be a management server, a network server, or any other electronic device or computing system capable of receiving and sending data. In some embodiments, the target server 125 may be a laptop computer, tablet computer, netbook computer, PC, desktop computer, or any programmable electronic device capable of communicating with the management console 120. In other embodiments, the target server 125 may represent a server computing system utilizing multiple computers as server systems, such as in a cloud computing environment. In another embodiment, the target server 125 represents a computing system utilizing clustered computers and components as a single seamless resource pool. Typically, the target server 125 is any server, mainframe, or computing device scheduled for firmware and / or software updates to the system. In one embodiment, the target server 125 does not allow external services to initiate calls to the target server 125. The target server 125 may include, as referenced... Figure 6 The components are described and illustrated in further detail.

[0027] Updater 145 operates to identify an authorized attempt to schedule a system update that has been received, schedules and sends an acknowledgment of the system update schedule, and then, in response to a code load request at a scheduled date and time corresponding to the system update details, pulls or otherwise receives the required system update data (e.g., installation files, firmware updates, code) directly or via management console 120 from remote support server 115 to target server 125. Updater 145 also generates an update status message to be sent to remote server 115 for access by a service representative or other administrative user at service client device 110 or remote support server 115. In one embodiment, updater 145 resides on management console 120. In other embodiments, updater 145 may reside on another server or another computing device, such as target server 125, as long as updater 145 can communicate with target server 125 and remote support server 115. In one embodiment, updater 145 includes two functions: a scheduling authorization function 150 and an update function 155.

[0028] The scheduling authorization function 150 operates to schedule and send confirmation of a request to schedule a system update. The scheduling authorization function 150 receives such a system update request as metadata in response to one or more data packets (e.g., system availability data) that may be periodically (e.g., hourly, daily, weekly) sent by the management console 120 to the target server 125. The metadata received by the scheduling authorization function 150 may include information such as scheduling data (e.g., date, time), authorization code / token, target device (e.g., target server 125), and a specified code level or software / firmware version associated with the system update. In one embodiment, the scheduling authorization function 150 is a function of the updater 145. In another embodiment, the scheduling authorization function 150 is a separate program that executes on the management console 120, the target server 125, or another server or computing device, provided that the scheduling authorization function 150 can communicate with the management target server 125 and / or the remote support server 115.

[0029] Update function 155 operates to generate and send a remote code load request to remote server 115 on the scheduled date and time for a system update, pull or otherwise receive system update data (e.g., installation files, firmware updates, code) for target server 125 to process and perform the update, and periodically send system update status messages to remote support server 115 throughout the update process for service representatives or administrative users to access via service client device 110 or remote support server 115. In one embodiment, update function 155 is a function of updater 145. In another embodiment, update function 155 is a standalone program that executes on management console 120, target server 125, or another server or computing device, as long as update function 155 can communicate with management target server 125 and / or remote support server 115.

[0030] Figure 2 A description of an embodiment of the present invention is provided. Figure 1 A flowchart 200 shows the steps of the scheduling request function 135 executed within the computing environment 100, used to send system update scheduling requests and receive authorization for such requests.

[0031] In one embodiment, initially, a service representative of another managing user coordinates with a second user associated with target server 125. For example, the second user may be a customer or client of the service representative who owns / rents target server 125, and the service representative may be responsible for maintaining and / or updating target server 125. The service representative obtains an authorization token or code via a channel outside network 105. For example, the second user may verbally provide such an authorization token to the service representative via telephone call or in person. In some embodiments, the authorization token is a one-time, limited-availability authorization token that allows scheduling. An managing user at target server 125 or management console 120 may request that such an authorization token be provided to the service representative, and in response to such a request, an authorization token may be generated. The authorization token may be, for example, a 6-digit hash token that can be read and verbally passed to the service representative. Additionally, the second user may provide the service representative with other information related to system updates, such as scheduling information (date / time), the specific system to be updated (e.g., target server 125), the desired code level or software / firmware version, or other information related to scheduling system updates.

[0032] After receiving the system update details, the service representative enters the system update details at the computing device. In some embodiments, the service representative enters the system update details at the service client device 110. In other embodiments, the service representative enters the system update details at the remote support server 115.

[0033] In step 210, the scheduling request function 135 receives system update details. In embodiments where the system update details are entered directly at the remote support server 115, the scheduling request function 135 receives the system update details via user (e.g., service representative) input at the user interface of the remote support server 115. In embodiments where the system update details are entered at the service client device 110, the scheduling request function 135 receives the system update details from the service client device 110. For example, the service client device 110's procedures may copy, send, or otherwise replicate the system update details to the remote support server 115 via network 105, making the system update details accessible to the scheduling request function 135.

[0034] In step 220, the scheduling request function 135 receives data from the target server 125. In some embodiments, the scheduling request function 135 receives data directly from the target server 125. In other embodiments, the scheduling request function 135 receives data from a management console 120 that substantially references the target server 125. The data received by the scheduling request function 135 may be in the form of periodic and periodically scheduled system availability data or other types of scheduling data. Typically, the data received from the target server 125 is unrelated to the details of system updates received by the scheduling request function 135 (see step 210). The scheduling request function 135 may receive such data periodically (e.g., daily). In other embodiments, the scheduling request function 135 receives such data periodically but not according to any particular schedule. For example, the target server 125 or the management console 120 may send such data based on a specific metric being met or a threshold being exceeded.

[0035] In step 230, the scheduling request function 135 sends system update details along with a response to target server 125. In some embodiments, the scheduling request function 135 sends the system update details directly to target server 125. In other embodiments, the scheduling request function 135 sends the system update details to management console 120, which communicates with target server 125. Typically, in response to receiving data from target server 125 and / or management console 120 (see step 220), the scheduling request function 135 sends the system update details as metadata in a response data packet sent to target server 125 and / or management console 120. As described above, the system update details included in the metadata of the response data packet may include details such as update date / time, authorization token / code, code level or software / firmware version number, and the specifications of the target server. The specifications of the target server can help with authorization and, for example, whether management console 120 is operatively connected to multiple potential target servers besides target server 125 alone. As a result of the scheduling request function 135 sending system update details via response data packets, the scheduling request function 135 does not need to initiate a call or connection to the target server 125 or the management console 120, but can still provide system update details to the target server 125 and / or the management console 120.

[0036] In step 240, the scheduling request function 135 receives confirmation from the target server 125. In some embodiments, the scheduling request function 135 receives confirmation directly from the target server 125. In other embodiments, the scheduling request function 135 receives confirmation from the management console 120. This confirmation can provide confirmation that system update details have been received by the management console 120 and / or the target server 125 and that the system update has been scheduled for the specified date / time.

[0037] Figure 3 A description of an embodiment of the present invention is provided. Figure 1 A flowchart 300 shows the steps of the scheduling authorization function 150 executed within the computing environment 100, used to authorize and schedule system updates based on requests received from the scheduling request function 135 in the return data packet.

[0038] As described herein, the scheduling authorization function 150 resides on the management console 120 and manages the target server 125. Some embodiments of the invention may include a scheduling authorization function residing on the target server 125, and in such embodiments, a management console is not present.

[0039] In one embodiment, initially, the management console 120 sends periodic updates to the remote support server, as referenced. Figure 2 As described (see step 220). The process of management console 120 may send such updates based on a time period (e.g., hourly, daily, weekly) or other metrics (e.g., whether the workload exceeds a pre-selected threshold in response to a system crash / error / restart). In one embodiment, the process of management console 120 monitors target server 125 to determine when to send such updates and what information such updates should contain. In other embodiments, the process of target server 125 sends status updates to management console 120, and the process of management console 120 relays the received information to remote support server 115. Updates may include various information, such as, but not limited to, system availability data, status data, system error data, or any other type of data.

[0040] In step 310, the scheduling authorization function 150 receives one or more response data packets as a return of a sent update from the previously described periodic update. The scheduling authorization function 150 receives one or more response data packets from the remote support server 115.

[0041] In decision 320, scheduling authorization function 150 determines whether one or more received response data packets include system update details. In some embodiments, scheduling authorization function 150 may receive various response data packets. For example, remote support server 115 may only send response data packets acknowledging receipt of data packets sent by various processes of target server 125 and / or management console 120. Scheduling authorization function 150 analyzes the received data packets(s) and identifies whether system update metadata, as previously described, is included in any received data packets.

[0042] If the scheduling authorization function 150 determines that there are no system update details in one or more received response data packets (judgment 320, "No" branch), then the function completes.

[0043] If the scheduling authorization function 150 determines that system update details exist in one or more received response data packets (decision 320, "Yes" branch), then the scheduling authorization function 150 determines whether the system update details include valid authorization (decision 330). The scheduling authorization function 150 can determine whether the system update details include valid authorization by comparing any received authorization information (e.g., authorization token) with the authorization information associated with the target server 125 and / or management console 120. (See above reference...) Figure 2 As described, an administrative user at the target server 125 or management console 120 may have instructed processes on the target server 125 or management console 120 to generate authorization, such as an authorization token. This authorization information is stored on the target server 125 and / or management console 120 so that the management console 120 can access the authorization information. Therefore, when the scheduling authorization function 150 receives a response data packet including system update details, the scheduling authorization function 150 compares the authorization from the received data packet with the stored authorization information generated at the target server 125 or management console 120. In some embodiments, the authorization information is also associated with other system update details, such as scheduling information (e.g., date / time), target server information, and / or code level or software / firmware version number. By associating the authorization information with these further system update details, security is enhanced because, in addition to the authorization information, the user who generated the system update details may need to know additional information about the system update.

[0044] If the scheduling authorization function 150 determines that no valid authorization exists (judgment 330, "No" branch), the function completes. In some embodiments, after determining that no valid authorization exists, the scheduling authorization function 150 may send an alert or other notification to the remote support server 115 indicating that a system update will not be scheduled. Such an alert or notification may be accessed by a service representative or other administrative user at the service client device 110 or the remote support server 115. In some embodiments, the alert or other notification may provide information indicating why the authorization is considered invalid (e.g., an incorrect authorization token, an authorization token that does not match other system update details).

[0045] If the scheduling authorization function 150 determines that a valid authorization exists (judgment 330, "Yes" branch), then the scheduling authorization function 150 schedules the system update (step 340). Typically, the authorization function 150 schedules the system update for a date and time indicated by the system update details. The scheduling authorization function 150 may store additional system update details. In some embodiments, the process management of the management console 120 is used for updates to the target server 125, and therefore, the scheduling authorization function 150 stores any necessary information in the management console 120. In other embodiments, the target server 125 may communicate directly with the remote support server 115, and in this embodiment, the scheduling authorization function 150 may store the system update details in the target server 125 and schedule the system update on the target server 125.

[0046] In step 350, the scheduling authorization function 150 sends an acknowledgment to the remote support server 115. The scheduling authorization function 150 may send an acknowledgment detailing that the system update has been received and that the system update has been scheduled to be performed at the date and time indicated in the response data packet.

[0047] In some embodiments, a user at the target server 125 or management console 120 may be able to view or cancel all code loading or other system updates to the target server 125 before initiating a scheduled code loading or software / firmware installation process.

[0048] Figure 4 Depicting in Figure 1 A flowchart 400 shows the steps of the update function 155 performed within the computing environment 100, which is used to initiate a code loading or software / firmware update request for the target server 125 on a scheduled date and time, and to periodically send update status messages throughout the update process.

[0049] As described herein, update functionality 155 resides on management console 120 and manages target server 125. Some embodiments of the invention may include update functionality residing on target server 125, and in such embodiments, a management console may not be required.

[0050] In one embodiment, initially, the scheduling authorization function 150 has received the system update details and schedules a system update for the target server 125.

[0051] In step 410, update function 155 sends a remote code load or software / firmware update request to remote support server 115. In some embodiments, update function 155 opens a remote support server request outbound connection to indicate a remote code load or software / firmware update. Typically, the remote support server request sends detailed information to remote support server 115. For example, some remote support server request types send detailed error information that service representatives can use to prepare an action plan. In some embodiments of the invention, remote load remote support server request opens a new remote support server request. Typically, update function 155 sends a remote code load or software / firmware request that may specify system update details, such as software / firmware version number or code level.

[0052] In step 420, update function 155 receives system update code associated with the system update. For example, update function 155 may receive installation files, software / firmware code, or any other code used to process a system update for target server 125. In some embodiments, update function 155 may pull required system update data (e.g., installation files, firmware updates, code) from remote support server 115. In embodiments including management console 120, update function 155 may send such received system update code to target server 125 to install or otherwise process the system update. In embodiments not including management console 120, update function 155 may execute on target server 125, and target server 125 may be able to directly process the received system update code. In some embodiments, update function 155 may receive all system update code required to perform a system update for target server 125 before initiating the installation or processing of such code for the update. In other embodiments, the installation or processing of a system update for target server 125 may occur in parallel with receiving system update code (e.g., for software updates, multiple installation files may exist). In some embodiments, management console 120 actively manages system updates for target server 125.

[0053] In step 430, update function 155 sends a system update status message to remote support server 115. Typically, update function 155 sends periodic system update status messages to remote support server 115, which include details associated with a system update on target server 125. In some embodiments, update function 155 appends a system update message to a remote support server request, such that the system update is associated with an issue opened for code loading on remote support server 115, thereby allowing such system update to be accessed by a service representative or other user at service client device 110 or remote support server 115. In some embodiments, target server 125 sends the system update status message directly to remote support server 115. In other embodiments, target server 125 sends the system update status message to management console 120, and update function 155 sends the system update status message to remote support server 115. In other embodiments, management console 120 actively manages system updates for target server 125 and is therefore able to monitor system updates for target server 125 and generate system update status messages. The system update status message sent by update function 155 may include detailed code loading information, shutdown / reboot information, and a specification of any errors or code loading / installation failures during code loading, including any details that caused the failure. In some embodiments, update function 155 sends such system update messages periodically according to predetermined time intervals, for example, every three minutes. In other embodiments, update function 155 sends such system updates periodically based on another metric associated with the system update process. This metric may be based on, for example, a completion percentage (e.g., a system update message for each percentage point of completion in a software / firmware update installation) or the presence of error messages.

[0054] Figure 5 Depicting in Figure 1 A flowchart 500 shows the steps of the monitoring function 140 performed within the computing environment 100, which are used to send system update codes and receive update status messages, thereby allowing service representatives or other authorized users to monitor system updates of the target server 125 at a remote support server 115 or service client device 110 without initiating or establishing an external connection to the management console 120 or the target server 125.

[0055] In one embodiment, initially, the scheduling request function 135 cooperates with the scheduling authorization function 150 to schedule and confirm the scheduling of code loading or software / firmware updates for the target server 125 based on information received from a service representative or other administrative user at the service client device 110 or remote support server 115.

[0056] In step 510, monitoring function 140 receives a remote code load request for code loading or software / firmware update of target server 125. In some embodiments, monitoring function 140 receives the remote code load request from management console 120. In other embodiments, monitoring function 140 receives the remote code load request from target server 125. Typically, monitoring function 140 receives the remote code load request from a device capable of operatively performing the steps associated with update function 155. In some embodiments, the remote code load request takes the form of a remote support server request, as referenced in... Figure 4 The update function 155 at step 410 is described. The code loading request may specify details associated with the system update, such as the target system (e.g., target server 125), the code-level or software / firmware version used for the update, or other information.

[0057] In step 520, monitoring function 140 sends system update code for target server 125 to management console 120 or, in embodiments without management console 120, to target server 125. Typically, monitoring function 140 sends system update code in response to a received remote code loading request, and monitoring function 140 does not initiate sending system update code to management console 120. In some embodiments, update function 155 may pull system update code from remote support server 115, and monitoring function 140 may not send system update code. System update code may include, for example, software / firmware code, installation files, or any other code used to process system updates for target server 125.

[0058] In step 530, monitoring function 140 receives an update status message associated with a system update of target server 125 from management console 120 or, in embodiments where management console 120 is not present, from target server 125. The update status message received by monitoring function 140 is the update status message described with reference to update function 155 (see [link to update status message description]). Figure 4 (Step 430). Such update status messages may include installation errors, update status, code loading progress messages, or any other status messages associated with a system update to target server 125. Monitoring function 140 may periodically receive such update status messages, as described with reference to update function 155. In some embodiments, update status messages are attached to the original problem opened for code loading via a remote code loading request (see step 510). Typically, monitoring function 140 stores update status messages so that they are accessible to a service representative or other administrative user at service client device 110 or remote support server 115. In some embodiments, monitoring function 140 sends update status messages to service client device 110.

[0059] By storing update status messages and making them accessible to service representatives or other administrative users at service client device 110 or remote support server 115, monitoring function 140 allows service representatives or other administrative users to remotely monitor updates associated with target server 125 from the site location of management console 120 and / or target server 125, without requiring such users to establish external connections to target server 125 or management console 120 using remote devices (e.g., service client device 110, remote support server 115). While remote support server 115 may respond to target server 125 or management console 120, it does not initiate external calls but responds to data requests originating from target server 125 or management console 120. Service client device 110 never communicates directly with management console 120 or target server 125, and in embodiments of the invention, allows service representatives or other users to monitor the update status of target server 125 by monitoring update status messages sent to remote support server 115. If an error occurs that causes a system update failure on target server 125, the system representative can be able to visit the management console 120 and / or the site of target server 125 to perform any necessary field service tasks and can formulate an action plan while the service representative is en route to the site. Embodiments of the invention recognize the advantage of not requiring a service representative to travel to the site in the event of a successful remote code loading as described herein and a successful system update. Furthermore, the remote code loading described herein allows target server 125 and / or management console 120 to initiate the code loading, and neither service client device 110 nor remote support server 115 initiates any connection to target server 125 or management console 120, thereby enhancing the security of target server 125 and / or management console 120 against potential external security threats.

[0060] Figure 6 A block diagram 600 depicts components of a service client device 110, a remote support server 115, a management console 120, and / or a target server 125 according to an illustrative embodiment of the present invention. It should be understood that... Figure 6 This is merely an illustration of an implementation and does not imply any limitation on the environment in which different embodiments may be implemented. Many modifications can be made to the depicted environment.

[0061] Each of the service client device 110, remote support server 115, management console 120, and target server 125 includes a communication structure 602 that provides communication between a cache 616, memory 606, persistent storage device 608, communication unit 610, and one or more input / output (I / O) interfaces 612. The communication structure 602 can be implemented using any architecture designed to transfer data and / or control information between processors (such as microprocessors, communication and network processors, etc.), system memory, peripheral devices, and any other hardware components within the system. For example, the communication structure 602 can be implemented using one or more buses or crossbars.

[0062] Memory 606 and persistent storage device 608 are computer-readable storage media. In this embodiment, memory 606 includes random access memory (RAM). Typically, memory 606 may include any suitable volatile or non-volatile computer-readable storage medium. Cache 616 is a fast memory that enhances the performance of one or more computer processors 604 by storing recently accessed data from memory 606 and data near the accessed data in memory 606.

[0063] Update monitoring program 130, scheduling request function 135, and monitoring function 140 may be stored in persistent storage device 608 and memory 606 of remote support server 115 for execution by one or more of the corresponding computer processors 604 via cache 616. Update program 145, scheduling authorization function 150, and update function 155 may be stored in persistent storage device 608 and memory 606 of management console 120 for execution by one or more of the corresponding computer processors 604 via cache 616. In an embodiment, persistent storage device 608 includes a magnetic hard disk drive (MDD). As an alternative to or supplement to a MDD, persistent storage device 608 may include a solid-state drive (SSD), semiconductor storage device, read-only memory (ROM), erasable programmable read-only memory (EPROM), flash memory, or any other computer-readable storage medium capable of storing program instructions or digital information.

[0064] The media used in persistent storage device 608 can also be removable. For example, a removable hard disk drive can be used in persistent storage device 608. Other examples include optical discs and disks, thumb drives and smart cards, which are inserted into the drive for transfer to another computer-readable storage medium that is also part of persistent storage device 608.

[0065] In these examples, communication unit 610 provides communication with other data processing systems or devices. In these examples, communication unit 610 includes one or more network interface cards. Communication unit 610 can provide communication using one or both of physical and wireless communication links. Update monitoring program 130, scheduling request function 135, and monitoring function 140 can be downloaded to the persistent storage device 608 of remote support server 115 via communication unit 610. Update program 145, scheduling authorization function 150, and update function 155 can be downloaded to the persistent storage device 608 of management console 120 via communication unit 610.

[0066] One or more I / O interfaces 612 allow data input and output to other devices that can be connected to the service client device 110, remote support server 115, management console 120, and / or target server 125. For example, I / O interface 612 can provide connectivity to external devices 618, such as keyboards, keypads, touchscreens, and / or other suitable input devices. External devices 618 may also include portable computer-readable storage media, such as thumb drives, portable optical discs or disks, and memory cards. Software and data used to practice embodiments of the invention (e.g., update monitoring program 130, scheduling request function 135, and monitoring function 140) can be stored on such portable computer-readable storage media and can be loaded onto persistent storage device 608 of remote support server 115 via one or more I / O interfaces 612. Additional software and data (e.g., updater 145, scheduling authorization function 150, and update function 155) used to implement embodiments of the present invention may be stored on such a portable computer-readable storage medium and may be loaded onto a permanent storage device 608 of the management console 120 via one or more I / O interfaces 612. One or more I / O interfaces 612 are also connected to a display 620.

[0067] The display 620 provides a mechanism for displaying data to the user and can be, for example, a computer monitor.

[0068] The programs described herein are identified based on applications that implement them in specific embodiments of the invention. However, it should be understood that any particular program terminology used herein is for convenience only, and therefore the invention should not be limited to use only in any particular application identified and / or implied by such terminology.

[0069] This invention can be a system, method, and / or computer program product at any possible level of technical detail integration. The computer program product may include one or more computer-readable storage media having computer-readable program instructions thereon for causing a processor to perform aspects of the invention.

[0070] Computer-readable storage media can be tangible devices capable of holding and storing instructions for use by an instruction execution device. Computer-readable storage media can be, for example, but not limited to, electronic storage devices, magnetic storage devices, optical storage devices, electromagnetic storage devices, semiconductor storage devices, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable optical disc read-only memory (CD-ROM), digital multifunction disc (DVD), memory sticks, floppy disks, mechanical encoding devices such as punch cards or recessed structures on which instructions are recorded, and any suitable combination of the foregoing. As used herein, computer-readable storage media should not be construed as transient signals themselves, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through waveguides or other transmission media (e.g., light pulses through fiber optic cables), or electrical signals transmitted through wires.

[0071] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a suitable computing / processing device, or downloaded via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network) to an external computer or external storage device. The network may include copper cables, optical fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to a computer-readable storage medium within the respective computing / processing device.

[0072] Computer-readable program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, integrated circuit configuration data, or source code or object code written in any combination of one or more programming languages ​​(including object-oriented programming languages ​​such as Smalltalk, C++, etc.) and procedural programming languages ​​(such as the "C" programming language or similar programming languages). The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network (including a local area network (LAN) or a wide area network (WAN)) or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuits including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs) may execute computer-readable program instructions by utilizing state information from the computer-readable program instructions to personalize the electronic circuits in order to perform aspects of this invention.

[0073] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0074] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for implementing the functions / actions specified in one or more blocks of a flowchart and / or block diagram. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other device to operate in a particular manner, such that the computer-readable storage medium in which the instructions are stored includes an article of writing comprising instructions for implementing aspects of the functions / actions specified in one or more blocks of a flowchart and / or block diagram.

[0075] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus or other device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other device to produce a computer-implemented process, such that the instructions executed on the computer, other programmable apparatus or other device perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0076] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions comprising one or more executable instructions for implementing a specified logical function. In some alternative embodiments, the functions indicated in the blocks may occur in a non-consecutive order as shown in the figures. For example, two blocks shown consecutively may actually be executed substantially simultaneously, or these blocks may sometimes be executed in reverse order, depending on the functions involved. It will also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system that performs the specified function or action or executes a combination of dedicated hardware and computer instructions.

[0077] Various embodiments of the invention have been described for illustrative purposes, but this description is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein has been chosen to best explain the principles of the embodiments, their practical application, or technical improvements superior to those found in the market, or to enable those skilled in the art to understand the embodiments described herein.

Claims

1. A computer-implemented method, comprising: Input data is received by one or more processors, the input data including: (i) a code level for the update, (ii) a target system for the update; (iii) a scheduling time for the update for the target system, and (iv) authorization data, wherein the target system does not allow external services to initiate calls to the target system, and the authorization data: (i) allows the scheduling of the update for the target system, and (ii) is provided via a channel other than the connection to the target system; The dataset is received from the target system by one or more processors; In response to receiving the dataset from the target system, one or more processors send a response packet including the input data to the target system; During the scheduling time for the update of the target system, one or more processors receive a request to process the update; In response to the request, one or more processors send code for processing the update corresponding to the code level used for the update; and One or more processors receive status messages corresponding to the progress of the update.

2. The computer-implemented method according to claim 1, wherein, The request to process the update includes a remote support server request generated by the target system.

3. The computer-implemented method according to claim 2, wherein, The status message is attached to the remote support server request.

4. The computer-implemented method according to claim 1 further includes: After sending the response packet including the input data to the target system, one or more processors receive from the target system an acknowledgment that the update has been scheduled for the scheduling time used for the update.

5. The computer-implemented method according to claim 1, wherein, The status message is received at predetermined time intervals during the update.

6. The computer-implemented method according to claim 1, wherein, The dataset received from the target system is associated with pre-scheduled periodic connections that are independent of the update.

7. The computer-implemented method according to claim 1, wherein, The status message includes information selected from a group consisting of: a restart performed by the target system, and errors.

8. The computer-implemented method according to claim 1, wherein, The authorization data includes an authorization token generated by the target system.

9. A computer-implemented method, comprising: One or more processors receive input data copied from a first device, the input data including: (i) a code level for the update, (ii) a target system for the update; (iii) a scheduling time for the update for the target system, and (iv) authorization data, wherein the target system does not allow external services to initiate calls to the target system, and the authorization data: (i) allows the scheduling of the update for the target system, and (ii) is provided via a channel other than the connection to the target system; A dataset is received by one or more processors from a second computing device that communicates with the target system. In response to receiving the dataset from the second computing device, one or more processors send a response packet including the input data to the second computing device; During the scheduling time for the update of the target system, one or more processors receive a request from the second computing device to process the update; In response to the request, one or more processors send code for processing the update, corresponding to the code level used for the update, to the second computing device; and One or more processors receive status messages from the second computing device corresponding to the progress of the update to the target system.

10. The computer-implemented method according to claim 9, wherein, The request to process the update includes a remote support server request generated by the second computing device.

11. The computer-implemented method according to claim 10, wherein, The status message is attached to the remote support server request.

12. The computer-implemented method according to claim 9, further comprising: After sending the response packet including the input data to the second computing device, one or more processors receive from the second computing device an acknowledgment that the update has been scheduled for the scheduling time used for the update.

13. The computer-implemented method according to claim 9, wherein, The status message is received at predetermined time intervals during the update.

14. The computer-implemented method according to claim 9, wherein, The dataset received from the second computing device is associated with a pre-scheduled periodic connection that is independent of the update.

15. The computer-implemented method according to claim 9, wherein, The status message includes information selected from a group consisting of: a restart performed by the target system, and errors.

16. The computer-implemented method according to claim 9, wherein, The authorization data includes an authorization token generated by the second computing device.

17. A computer program product comprising: One or more computer-readable storage media, and program instructions commonly stored on the one or more computer-readable storage media, the program instructions comprising: Program instructions for receiving input data, the input data including: (i) a code level for updating, (ii) a target system for the update; (iii) a scheduling time for the update of the target system, and (iv) authorization data, wherein the target system does not allow external services to initiate calls to the target system, and the authorization data: (i) allows the scheduling of the update of the target system, and (ii) is provided via a channel other than the connection to the target system; Program instructions for receiving datasets from the target system; A program instruction for sending a response packet including the input data to the target system in response to receiving the dataset from the target system; Program instructions for receiving a request to process the update at the scheduled time for the update of the target system; For responding to the request, sending program instructions for processing the update corresponding to the code level for the update; and Program instructions for receiving status messages corresponding to the progress of the update.

18. The computer program product according to claim 17, wherein, The request to process the update includes a remote support server request generated by the target system.

19. The computer program product according to claim 18, wherein, The status message is attached to the remote support server request.

20. The computer program product according to claim 17, further comprising: Program instructions, co-located on the one or more computer-readable storage media, are configured to receive from the target system, after sending the response packet including the input data, an acknowledgment that the update has been scheduled for the scheduling time used for the update.

21. The computer program product according to claim 17, wherein, The status message is received at predetermined time intervals during the update.

22. The computer program product according to claim 17, wherein, The dataset received from the target system is associated with pre-scheduled periodic connections that are independent of the update.

23. The computer program product according to claim 17, wherein, The status message includes information selected from a group consisting of: a restart performed by the target system, and errors.

24. A computer program product comprising: One or more computer-readable storage media, and program instructions commonly stored on the one or more computer-readable storage media, the program instructions comprising: Program instructions for receiving input data copied from a first device, the input data including: (i) a code level for updating, (ii) a target system for the update; (iii) a scheduling time for the update for the target system, and (iv) authorization data, wherein the target system does not allow external services to initiate calls to the target system, and the authorization data: (i) allows the scheduling of the update for the target system, and (ii) is provided via a channel other than the connection to the target system; Program instructions for receiving a dataset from a second computing device that communicates with the target system; A program instruction for sending a response packet including the input data to the second computing device in response to receiving the dataset from the second computing device; Program instructions for receiving a request to process the update from the second computing device during the scheduled time for the update of the target system; For responding to the request, sending program instructions to the second computing device for processing the update code corresponding to the code level for the update; and Program instructions for receiving from the second computing device a status message corresponding to the progress of the update to the target system.

25. A computer system, comprising: One or more computer processors, one or more computer-readable storage media, and program instructions commonly stored on the one or more computer-readable storage media, the program instructions being executed by at least one of the one or more computer processors to perform the method according to any one of claims 1 to 16.

Images