Remote System Updates and Monitoring

Abstract

The processor receives input data including (i) a code level for the update, (ii) a scheduled time for the update; (iii) a target system for the update, and (iv) authorization data, where the authorization data (i) enables scheduling of the update and (ii) is provided without an inbound connection and over a channel external to a connection to the target system. The processor receives a set of data from the target system. In response to receiving the set of data from the target system, the processor sends a response packet having 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 the progress of the update.

Description

[Technical field]

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

[0002] Service personnel may maintain servers or other computing devices for client users. Typically, service personnel travel to the site to perform maintenance, updates, repairs, or other tasks associated with maintaining such computing devices. Some services, such as software and firmware updates, may be accomplished without the service personnel physically traveling to the site.

[0003] A drawback of current solutions is the need to establish a direct connection with the served device, which requires the served device to accept external direct connection requests, increasing the risk of external security threats that may compromise the served device. Summary of the Invention

[0004] According to some embodiments of the present invention, a computer-implemented method, a computer program product, and a computer system are provided. 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, where the authorization data (i) enables scheduling of the update and (ii) is provided over a channel external to a connection to the target system. The processor receives a set of data from the target system. In response to receiving the set of data from the target system, the processor sends a response packet to the target system having the input data. 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 the progress of the update. Such an approach has the advantage of enabling remote service updates to a target system without the need for the remote device to initiate a connection with the target system, and allowing the remote device to monitor the progress of the update without establishing a connection to the target system.

[0005] According to another embodiment of the present invention, a computer-implemented method, a computer program product, and a computer system are provided. A processor receives input data replicated from a first device, the 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, where the authorization data (i) enables scheduling of the update and (ii) is provided over a channel external to a connection to the target system. The processor receives a set of data from a second computing device in communication with the target system. In response to receiving the set of data from the second computing device, the processor transmits a response packet to the second computing device having the input data. The processor receives a request from the second computing device at the scheduled time to process the update. In response to the request, the processor transmits code to the second computing device for processing the update corresponding to the code level for the update. The processor receives a status message from the second computing device corresponding to a progress of the update of the target system. Such an approach has the benefit of enabling remote service updates to a target system without the need for the remote device to initiate a connection with the target system, and allowing the remote device to monitor the progress of the update without establishing a connection to the target system. Such an approach may improve security and enable remote updates to target systems that do not accept external computing devices to initiate connection requests.

[0006] Embodiments of the present invention optionally include an approach whereby status messages are attached to the remote support server request, which has the benefit of allowing a service representative to access the remote support server request and view status updates associated with updates to the target device, as well as any information attached to the remote support server request, thus allowing the service representative to monitor updates to the target system without maintaining a connection to the target system.

[0007] An embodiment of the present invention optionally includes an approach in which a set of data received from a target system is associated with a pre-scheduled periodic connection unrelated to updates. Such an approach has the advantage of creating a window within which a response packet containing the input data can be sent to the target system, thereby allowing updates to the target system to be scheduled without the need for a remote system to initiate a connection to the target system. [Brief description of the drawings]

[0008] [Figure 1] FIG. 1 illustrates a computing environment according to one embodiment of the present invention.

[0009] [Diagram 2] 2 is a flow chart illustrating the steps of a scheduling request function of an update monitor program executing within the computing environment of FIG. 1 for sending a system update schedule request and receiving an approval for such request, according to one embodiment of the present invention.

[0010] [Diagram 3] 2 is a flowchart illustrating the steps of an update program scheduling approval function executing within the computing environment of FIG. 1 for approving and scheduling a system update based on a request received from a scheduling request function in a return data packet, according to one embodiment of the present invention.

[0011] [Figure 4] 2 is a flowchart illustrating the steps of an update function of an update program executing within the computing environment of FIG. 1 to initiate a code load or software / firmware update request of a target server at a scheduled date and time, and to periodically send update status messages throughout the update, in accordance with one embodiment of the present invention.

[0012] [Diagram 5] 2 is a flow chart illustrating steps of a monitoring function of an update monitoring program executing within the computing environment of FIG. 1 to enable a user to monitor system updates of a target server at a remote location by sending system update codes and receiving update status messages without initiating or establishing an external connection, according to one embodiment of the present invention.

[0013] [Figure 6] 2 is a block diagram illustrating components of a service providing client device, a remote support server, a management console, and a target server according to one embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0014] Embodiments of the present invention recognize that securely scheduling and monitoring system code update processes can increase the efficiency of system updates that may otherwise have to be performed in-situ. Embodiments of the present invention recognize that secure systems exist that do not allow external parties (service personnel, external computing systems, etc.) to initiate calls to the secure system. Embodiments of the present invention provide an approach for remotely and securely scheduling and monitoring code update processes for a system without having to initiate connections to schedule and / or monitor the target servers.

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

[0016] Figure 1 illustrates a diagram of a computing environment 100 in accordance with one embodiment of the present invention. Figure 1 is intended only to illustrate one embodiment and is not intended to suggest any limitation with regard to the environments in which different embodiments of the present invention may be implemented.

[0017] In the illustrated embodiment, computing environment 100 includes a service providing client device 110, a remote support server 115, and an administration console 120 interconnected via a network 105. Computing environment 100 also includes administration console 120 and 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 while FIG. 1 shows the target server 125 and the management console 120 interconnected via separate networks, embodiments of the present invention contemplate embodiments in which the management console 120 and the target server 125 are a single device or the management console 120 is the target server. In the following, reference is made to an embodiment 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 monitor 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. Furthermore, in describing the embodiment shown by FIG. 1, the service representative is described as interacting with the service delivery client device 110. It should be noted that embodiments of the present invention also contemplate embodiments in which the service representative interacts directly with the remote support server 115. All such embodiments described above are within the scope of embodiments of the present invention.

[0019] The 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 supporting communication between the service provision client devices 110, the remote support server 115, and the management console 120 according to embodiments of the present invention. The network 105 may include wired, wireless, or fiber optic connections. The computing environment 100 may include additional computing devices, servers, computers, mobile devices, or other devices not shown.

[0020] The remote support server 115 may be a management server, a web server, or any other electronic device or computing system capable of receiving and transmitting data. In some embodiments, the remote support server 115 may be a laptop computer, a tablet computer, a netbook computer, a personal computer (PC), a desktop computer, or any programmable electronic device capable of communicating with the service provision client device 110 and the management console 120 via the network 105. In other embodiments, the remote support server 115 may represent a server computing system that utilizes multiple computers as a server system, such as in a cloud computing environment. In another embodiment, the remote support server 115 represents a computing system that utilizes clustered computers and components to act as a single pool of seamless resources. The remote support server 115 houses an update monitor program 130. The remote support server 115 may include components as shown and described in more detail with respect to FIG. 6.

[0021] The update monitor program 130 operates to schedule software or firmware updates for target devices, such as the target server 125, and then receive progress status updates from the target devices during the scheduled updates. In some embodiments, the update monitor program 130 schedules updates directly with the target server 125 and monitors the update progress. In other embodiments, the management console 120 is intermediate between the remote support server 115 and the target server 125, and the target server 125 does not communicate directly with the remote support server 115. In one embodiment, the update monitor program 130 resides on the remote support server 115. In other embodiments, the update monitor program 130 can reside on another server or another computing device, so long as the update monitor program 130 can communicate with the management console 120 and / or the target server 125. In one embodiment, the update monitor 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) entered by a service representative or administrator user, such as a service representative interacting with the service provision client device 110, and return the system update details to a management console, such as the management console 120, which is in communication with the target server (e.g., target server 125). The scheduling request function 135 transmits such system update details via a response packet after receiving data from the management console 120 (e.g., system availability data transmitted periodically). The scheduling request function 135 may further receive an acknowledgement from the management console 120 that the system update has been scheduled, and the scheduling request function 135 may store the acknowledgement in persistent storage at the remote support server 115 or transmit the acknowledgement to the service provision client device 110 for access by the service representative. In one embodiment, the scheduling request function 135 is a function of the update monitor program 130. In another embodiment, the scheduling request function 135 is a standalone program executing on the remote support server 115 or another server or computing device, so long as the scheduling request function 135 is capable of communicating with the service providing client device 110, the management console 120, and / or the target server 125.

[0023] As system updates occur, the monitoring function 140 operates to receive update status messages directly from the target server 125 or from the management console 120. Such status messages may be monitored by service personnel operating the service provision client device 110 or the remote support server 115. In one embodiment, the monitoring function is a function of the update monitor program 130. In another embodiment, the monitoring function is a standalone program running on the remote support server 115 or another server or computing device, so long as the monitoring function 140 is capable of communicating with the service provision client device 110, the management console 120, and / or the target server 125.

[0024] The servicing client device 110 may be a laptop computer, a netbook computer, a tablet computer, a PC, a desktop computer, a personal digital assistant (PDA), or a smartphone. In general, the servicing client device 110 may be any electronic device or computing system capable of executing computer code and communicating with a remote support server 115. In general, the servicing client device 110 is utilized by a service representative or other administrative user to input details of system updates to be replicated to the remote support server 115 for use by the update monitor program 130 and the scheduling request function 135. The servicing client device 110 may also be used by such a user to monitor status updates with respect to scheduled updates of the target server 125. The servicing client device 110 may include components as shown and described in more detail with respect to FIG. 6.

[0025] The management console 120 may be a management server, a web server, or any other electronic device or computing system capable of receiving and transmitting data. In some embodiments, the management console 120 may be a laptop computer, a tablet computer, a netbook computer, a PC, a desktop computer, or any programmable electronic device capable of communicating with the remote support server 115 via the network 105 and with the target server 125 via another network or a direct connection. In other embodiments, the management console 120 may represent a server computing system that utilizes multiple computers as a server system, such as in a cloud computing environment. In another embodiment, the management console 120 represents a computing system that utilizes clustered computers and components to act as a single pool of seamless resources. The management console 120 contains updates 145. In some embodiments, the management console 120 generally operates to manage the target server 125, allowing a system administrator to manage, monitor, and service the target server 125 that may be inaccessible via the network 105 to a remote user. The management console 120 may include components as shown and described in more detail with respect to FIG. 6.

[0026] The target server 125 may be a management server, a web server, or any other electronic device or computing system capable of receiving and transmitting data. In some embodiments, the target server 125 may be a laptop computer, a tablet computer, a netbook computer, a PC, a 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 that utilizes multiple computers as a server system, such as in a cloud computing environment. In another embodiment, the target server 125 represents a computing system that utilizes clustered computers and components to act as a single pool of seamless resources. In general, the target server 125 is any server, mainframe, or computing device for which firmware and / or software updates to the system are to be scheduled. 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 components as shown and described in more detail with respect to FIG. 6.

[0027] The update program 145 operates to identify that an approved attempt to schedule a system update has been received, schedule the system update, send an acknowledgement of the scheduling of the system update, and then retrieve or otherwise receive the required system update data (e.g., installation files, firmware updates, code) from the remote support server 115 to the target server 125, either directly or via the management console 120, in response to a code load request at a scheduled date and time corresponding to the details of the system update. The update program 145 also generates update status messages to be sent to the remote server 115 for access by service personnel or other administrative users at the service provision client device 110 or the remote support server 115. In one embodiment, the update program 145 resides on the management console 120. In other embodiments, the update program 145 can reside on another server, such as the target server 125, or another computing device, as long as the update program 145 is capable of communicating with the target server 125 and the remote support server 115. In one embodiment, the update program 145 includes two functions: a scheduling approval function 150 and an update function 155.

[0028] The scheduling approval function 150 operates to schedule system updates and to send acknowledgments of requests to schedule system updates. Such system update requests are received by the scheduling approval function 150 as metadata in return packets in response to data packets (e.g., system availability data) that may be sent periodically (e.g., hourly, daily, weekly) by the management console 120 for the target server 125. The metadata received by the scheduling approval function 150 may include information such as the scheduling data (e.g., date, time), the approved code / token, the target device, such as the target server 125, and the specified code level or software / firmware version associated with the system update. In one embodiment, the scheduling approval function 150 is a function of the update program 145. In another embodiment, the scheduling approval function 150 is a standalone program executing on the management console 120, the target server 125, or another server or computing device, so long as the scheduling approval function 150 is capable of communicating with the managed target server 125 and / or the remote support server 115.

[0029] The update function 155 operates to generate and send remote code load requests to the remote server 115 at the scheduled date and time of a system update, to retrieve or otherwise receive system update data (e.g., installation files, firmware updates, code) for processing by the target server 125 to perform the update, and to periodically send system update status messages to the remote support server 115 throughout the update for access by service personnel or administrative users via the service provision client device 110 or the remote support server 115. In one embodiment, the update function 155 is a function of the update program 145. In another embodiment, the update function 155 is a standalone program executing on the management console 120, the target server 125, or another server or computing device, so long as the update function 155 is capable of communicating with the managed target server 125 and / or the remote support server 115.

[0030] FIG. 2 illustrates a flowchart 200 of steps for a scheduling request function 135 executing within the computing environment 100 of FIG. 1 to send a system update schedule request and receive an approval for such a request, according to one embodiment of the present invention.

[0031] In one embodiment, the service representative of the other administrative user first coordinates with a second user associated with the target server 125. For example, the second user may be a client or customer of the service representative who owns / leases the target server 125, and the service representative may be responsible for maintaining and / or updating the target server 125. The service representative obtains an authorization token or code via a channel external to the network 105. For example, the second user may provide such authorization token verbally to the service representative via a telephone call or in-person interaction. In some embodiments, the authorization token is a one-time use authorization token that enables scheduling. The administrative user of the target server 125 or management console 120 may request that such authorization token be provided to the service representative, and in response to this request, an authorization token may be generated. The authorization token may be, for example, a six-digit hash token that may be read and verbally communicated to the service representative. The second user may also provide the service representative with other information regarding the system update, such as scheduling information (date / time), the particular system (e.g., target server 125) to be updated, the desired code level or software / firmware version, or other information related to scheduling the system update.

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

[0033] At stage 210, the scheduling request function 135 receives the system update details. In embodiments where the system update details are entered directly into the remote support server 115, the scheduling request function 135 receives the system update details via user (e.g., service representative) input at a user interface of the remote support server 115. In embodiments where the system update details are entered at the servicing client device 110, the scheduling request function 135 receives the system update details from the servicing client device 110. For example, a process at the servicing client device 110 may copy, transmit, or otherwise replicate the system update details to the remote support server 115 over the network 105 so that the system update details can be accessed by 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 the management console 120, which in essence references the target server 125. The data received by the scheduling request function 135 may be in the form of periodic, regularly scheduled system availability data or other types of scheduled data. In general, the data received from the target server 125 is independent of the details of the system updates received by the scheduling request function 135 (see step 210). The scheduling request function 135 may receive such data periodically, for example 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 certain metrics being met or thresholds being exceeded.

[0035] At step 230, the scheduling request function 135 sends the system update details to the target server 125 along with a response to the target server 125. In some embodiments, the scheduling request function 135 sends the system update details directly to the target server 125. In other embodiments, the scheduling request function 135 sends the system update details to the management console 120, which is in communication with the target server 125. In general, the scheduling request function 135 sends the system update details as metadata in a response data packet sent to the target server 125 and / or management console 120 in response to receiving data from the target server 125 and / or management console 120 (see step 220). As described above, the system update details included in the metadata of the response data packet may include details such as date / time of the update, authorization token / code, code level or software / firmware version number, and target server specifications. The specification of the target server may be useful for authorization and may also be useful, for example, in cases where the management console 120 is operatively connected to multiple potential target servers in addition to just the target server 125. As a result of the scheduling request function 135 sending the system update details via the response data packet, the scheduling request function 135 does not have to initiate a call or connection to the target server 125 or the management console 120, although it may still provide the system update details to the target server 125 and / or the management console 120.

[0036] At stage 240, the scheduling request function 135 receives an acknowledgment from the target server 125. In some embodiments, the scheduling request function 135 receives the acknowledgment directly from the target server 125. In other embodiments, the scheduling request function 135 receives the acknowledgment from the management console 120. The acknowledgment may provide confirmation that the 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] FIG. 3 illustrates a flowchart 300 of the steps of a scheduling approval function 150 executing within the computing environment 100 of FIG. 1 to approve and schedule a system update based on a request received in a return data packet from a scheduling request function 135, in accordance with one embodiment of the present invention.

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

[0039] In one embodiment, the management console 120 initially sends periodic updates to the remote support server as described with respect to FIG. 2 (see step 220). The management console 120 process may send such updates based on a period (e.g., hourly, daily, weekly) or other metric (e.g., when the workload exceeds a preselected threshold, in response to a system crash / error / restart). In one embodiment, the management console 120 process monitors the target server 125 to determine when to send such updates and what information should be included in such updates. In another embodiment, the target server 125 process sends status updates to the management console 120, which relays the received information to the remote support server 115. The updates may include a variety of information, such as, but not limited to, system availability data, status data, system error data, or any other type of data.

[0040] At step 310, the scheduling acknowledgement function 150 receives one or more response data packets in return from a sent one of the periodic updates described above. The scheduling acknowledgement function 150 receives one or more response data packets from the remote support server 115.

[0041] At decision 320, the scheduling approval function 150 determines whether one or more received response data packets include details of the system update. In some embodiments, the scheduling approval function 150 may receive various response data packets. For example, the remote support server 115 may simply send response data packets acknowledging receipt of data packets sent by various processes of the target server 125 and / or the management console 120. The scheduling approval function 150 analyzes the received data packets and identifies whether any of the received data packets include system update metadata as described above.

[0042] If the scheduling approval function 150 determines that system update details are not present in one or more received response data packets (decision 320, no branch), the function is complete.

[0043] If the scheduling approval function 150 determines that system update details are present in one or more received response data packets (decision 320, yes branch), the scheduling approval function 150 determines whether the system update details include valid approvals (decision 330). The scheduling approval function 150 may determine whether the system update details include valid approvals by comparing any received approval information (e.g., an approval token) with approval information associated with the target server 125 and / or management console 120. As described above with respect to FIG. 2, an administrative user at either the target server 125 or management console 120 may have generated approvals, for example in the form of an approval token, to a process at the target server 125 or management console 120. Such approval information is stored at the target server 125 and / or management console 120, allowing the management console 120 to access the approval information. Thus, when the scheduling approval function 150 receives a response data packet containing the system update details, the scheduling approval function 150 compares the approval from the received data packet with stored approval information generated at the target server 125 or management console 120. In some embodiments, the approval information is also associated with the scheduling information (e.g., date / time), target server information, and / or other system update details such as code levels or software / firmware version numbers. By associating the approval information with these further system update details, security is enhanced since a user generating the system update details may need to know additional information about the system update in addition to the approval information.

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

[0045] If the scheduling approval function 150 determines that a valid approval exists (decision 330, yes branch), the scheduling approval function 150 schedules the system update (stage 340). Generally, the approval function 150 schedules the system update for the date and time indicated in the system update details. The scheduling approval function 150 may store additional system update details. In some embodiments, a process in the management console 120 manages the updates for the target server 125, and thus the scheduling approval function 150 stores any necessary information for the management console 120. In other embodiments, the target server 125 may communicate directly with the remote support server 115, and in such embodiments, the scheduling approval function 150 may store the system update details for the target server 125 and schedule the system update on the target server 125.

[0046] At stage 350, the scheduling approval function 150 sends an acknowledgement to the remote support server 115. The scheduling approval function 150 may send an acknowledgement detailing that the details of the system update have been received and that the system update is scheduled to be performed at the date and time indicated in the response data packet.

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

[0048] FIG. 4 shows a flowchart 400 of the steps of an update function 155 executed within the computing environment 100 of FIG. 1 to initiate a code load or software / firmware update request for a target server 125 at a scheduled date and time, and to send update status messages periodically throughout the update.

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

[0050] In one embodiment, initially, the scheduling approval function 150 receives details of the system update and schedules the system update for the target server 125 .

[0051] In step 410, the update function 155 sends a remote code load or software / firmware update request to the remote support server 115. In some embodiments, the update function 155 opens an outbound connection for a type of remote support server request to indicate the remote code load or software / firmware update. Generally, the remote support server request sends detailed information to the remote support server 115. For example, some types of remote support server requests send detailed error information that can be used by service personnel to prepare an action plan. In some embodiments of the present invention, the remote load remote support server request opens a new remote support server request. Generally, the update function 155 may send a remote code load or software / firmware request that may specify details of the system update, such as software / firmware version numbers or code levels.

[0052] In step 420, the update function 155 receives a system update code associated with the system update. For example, the update function 155 may receive an installation file, software / firmware code, or any other code used to process the system update of the target server 125. In some embodiments, the update function 155 may retrieve the necessary system update data (e.g., installation files, firmware updates, code) from the remote support server 115. In embodiments that include a management console 120, the update function 155 may transmit such received system update code to the target server 125 to install or otherwise process the system update. In embodiments that do not include a management console 120, the update function 155 may be running on the target server 125, which may be capable of directly processing the received system update code. In some embodiments, the update function 155 may receive all system update code necessary to perform the system update of the target server 125 before initiating the installation or processing of such code for the update. In other embodiments, the installation or processing of system updates on target servers 125 may occur in parallel with receiving the system update code (e.g., for a software update, there may be multiple installation files). In some embodiments, management console 120 actively manages system updates on target servers 125.

[0053] In step 430, the update function 155 sends a system update status message to the remote support server 115. In general, the update function 155 sends periodic system update status messages to the remote support server 115 that include details associated with the system updates of the target server 125. In some embodiments, the update function 155 can attach the system update message to the remote support server request so that the system update is associated with the issue opened for code loading on the remote support server 115, making such system updates accessible by service personnel or other users at the service providing client device 110 or the remote support server 115. In some embodiments, the target server 125 sends the system update status message directly to the remote support server 115. In other embodiments, the target server 125 sends the system update status message to the management console 120, and the update function 155 sends the system update status message to the remote support server 115. In yet other embodiments, the management console 120 actively manages the system updates of the target server 125 and can thus monitor the system updates of the target server 125 and generate system update status messages. System update status messages sent by update function 155 may include detailed code load in process messages, shutdown / restart information, as well as errors during code load or during code load specification, or installation failures including any details that caused the failure. In some embodiments, update function 155 sends such system update messages periodically according to a predefined period, e.g., once every three minutes. In other embodiments, update function 155 sends such system updates periodically based on another metric associated with the system update process. Such a metric may be based, for example, on a completion percentage (e.g., one system update message for every completed percentage point of the software / firmware update installation), or the presence of error messages.

[0054] FIG. 5 illustrates a flowchart 500 of steps of a monitoring function 140 executed within the computing environment 100 of FIG. 1 to enable a service representative or other authorized user at the remote support server 115 or service delivery client device 110 to monitor system updates of the target server 125 by sending system update codes and receiving update status messages without initiating or establishing an external connection to the management console 120 or target server 125.

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

[0056] In step 510, the monitoring function 140 receives a remote code load request for a code load or software / firmware update for the target server 125. In some embodiments, the monitoring function 140 receives the remote code load request from the management console 120. In other embodiments, the monitoring function 140 receives the remote code load request from the target server 125. In general, the monitoring function 140 receives the remote code load request from a device that operatively executes a step associated with the update function 155. In some embodiments, the remote code load request is in the form of a remote support server request, as described with respect to the update function 155 in step 410 of FIG. 4. The code load request may specify details associated with the system update, such as the target system (e.g., the target server 125), the code level or software / firmware version of the update, or other information.

[0057] In step 520, the monitoring function 140 transmits the system update code for the target server 125 to the management console 120, or to the target server 125 in embodiments without the management console 120. Generally, the monitoring function 140 transmits the system update code in response to a received remote code load request, and the monitoring function 140 does not initiate the transmission of the system update code to the management console 120. In some embodiments, the update function 155 may retrieve the system update code from the remote support server 115, and the monitoring function 140 may not transmit the system update code. The system update code may include, for example, software / firmware code, installation files, or any other code used to process a system update of the target server 125.

[0058] In step 530, the monitoring function 140 receives update status messages associated with the system updates of the target server 125 from the management console 120, or from the target server 125 in embodiments where the management console 120 is not present. The update status messages received by the monitoring function 140 are the update status messages described with respect to the update function 155 (see FIG. 4 , step 430). Such update status messages may include installation errors, update status, code load progress messages, or any other status messages associated with the system updates of the target server 125. As described with respect to the update function 155, the monitoring function 140 may receive such update status messages periodically. In some embodiments, the update status messages are attached to the original issue opened for the code load via the remote code load request (see step 510). Generally, the monitoring function 140 stores the update status messages so that they are accessible to service personnel or other administrative users at the service delivery client device 110 or the remote support server 115. In some embodiments, the monitoring function 140 sends an update status message to the service providing client device 110 .

[0059] By storing update status messages and making the update status messages accessible to a service representative or other administrative user at the service providing client device 110 or the remote support server 115, the monitoring function 140 allows a service representative or other administrative user to monitor updates associated with the target server 125 remotely from the on-site location of the management console 120 and / or the target server 125 without such user having to utilize a remote device (e.g., the service providing client device 110, the remote support server 115) to establish an external connection with the target server 125 or the management console 120. Although the remote support server 115 may respond to the target server 125 or the management console 120, the remote support server 115 does not initiate external calls, but instead responds to data requests originating from the target server 125 or the management console 120. The service delivery client device 110 never communicates directly with the management console 120 or the target server 125, and embodiments of the present invention allow a service representative or other user to monitor the update status of the target server 125 by monitoring update status messages sent to the remote support server 115. If an error occurs that causes the system update of the target server 125 to fail, system personnel may be able to go to the site of the management console 120 and / or the target server 125 may be able to perform any necessary on-site service tasks, and a plan of action may be developed while the service representative is on the way to the site. Embodiments of the present invention recognize the advantage of not requiring a service representative to travel to the site if such a remote code load as described herein is successfully executed and the system is successfully updated.Furthermore, the remote code loading described herein allows the target server 125 and / or the management console 120 to initiate the code loading, and neither the service providing client device 110 nor the remote support server 115 initiates any connection to the target server 125 or the management console 120, thereby enhancing the security of the target server 125 and / or the management console 120 from potential external security threats.

[0060] 6 illustrates a block diagram 600 of components of a service providing client device 110, a remote support server 115, an administration console 120, and / or a target server 125 in accordance with an exemplary embodiment of the invention. It should be understood that FIG. 6 is merely provided as an example of one implementation and is not intended to suggest any limitation with respect to the environments in which different embodiments may be implemented. Many modifications to the depicted environments may be made.

[0061] Each of the service providing client device 110, the remote support server 115, the management console 120, and the target server 125 includes a communication fabric 602 that provides communication between a cache 616, a memory 606, a persistent storage 608, a communication unit 610, and an input / output (I / O) interface 612. The communication fabric 602 may be implemented using any architecture designed to pass data and / or control information between a processor (e.g., a microprocessor, a communication and network processor, etc.), system memory, peripherals, and any other hardware components in the system. For example, the communication fabric 602 may be implemented using one or more buses or crossbar switches.

[0062] Memory 606 and persistent storage 608 are computer readable storage media. In this embodiment, memory 606 includes random access memory (RAM). In general, memory 606 may include any suitable volatile or non-volatile computer readable storage medium. Cache 616 is a high-speed memory that improves the performance of computer processor 604 by retaining recently accessed data and data near the accessed data from memory 606.

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

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

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

[0066] The I / O interface 612 allows for input and output of data with other devices that may be connected to the service providing client device 110, the remote support server 115, the management console 120, and / or the target server 125. For example, the I / O interface 612 may provide a connection to an external device 618, such as a keyboard, a keypad, a touch screen, and / or any other suitable input device. The external device 618 may also include a portable computer-readable storage medium, such as a thumb drive, a portable optical or magnetic disk, and a memory card. Software and data used to implement embodiments of the present invention, such as the update monitor program 130, the scheduling request function 135, and the monitor function 140, may be stored on such a portable computer-readable storage medium and loaded into the persistent storage 608 of the remote support server 115 via the I / O interface 612. Additional software and data used to implement embodiments of the present invention, such as update programs 145, scheduling approval function 150, and update function 155, may be stored on such portable computer-readable storage media and loaded into persistent storage 608 of management console 120 via I / O interface 612. I / O interface 612 is also connected to a display 620.

[0067] Display 620 provides a mechanism for displaying data to a user and may be, for example, a computer monitor.

[0068] The programs described herein are identified based on the applications for which they are implemented in particular embodiments of the invention. However, it should be understood that any particular program names herein are used merely for convenience, and therefore the invention should not be limited to use with any particular application identified and / or suggested by such names.

[0069] The present invention may be a system, method, and / or computer program product integrated at any conceivable level of technical detail. The computer program product may include a computer readable storage medium (or multiple computer readable storage media) having computer readable program instructions for causing a processor to implement aspects of the present invention.

[0070] A computer-readable storage medium may be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes portable computer diskettes, hard disks, random access memories (RAMs), read-only memories (ROMs), erasable programmable read-only memories (EPROMs or flash memories), static random access memories (SRAMs), portable compact disk read-only memories (CD-ROMs), digital versatile disks (DVDs), memory sticks, floppy disks, punch cards, or mechanically encoded devices such as ridge structures in grooves in which instructions are recorded, and any suitable combination of the above. As used herein, computer-readable storage media should not be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted over wires.

[0071] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to the respective computing / processing device or to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may comprise copper transmission cables, optical transmission fiber, 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 transfers the computer-readable program instructions to a computer-readable storage medium in the respective computing / processing device for storage.

[0072] The computer readable program instructions implementing the operations of the present invention may be assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or may be source or object code written in any combination of one or more programming languages, including object oriented programming languages ​​such as Smalltalk® or C++, 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 as a stand-alone software package, partially on the user's computer, 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 the connection may be to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may execute computer readable program instructions to personalize the electronic circuitry by utilizing state information of the computer readable program instructions to perform aspects of the invention.

[0073] 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 computer or other programmable data processing apparatus to produce a machine, whereby the instructions executed via the processor of the computer or other programmable data processing apparatus create means for implementing the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams. These computer readable program instructions may also be stored on a computer readable storage medium capable of directing a computer, programmable data processing apparatus, and / or other device to function in a particular manner, whereby the computer readable storage medium having stored thereon instructions comprises an article of manufacture including instructions that implement aspects of the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0075] The computer readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device and cause the computer, other programmable apparatus, or other device to execute a series of operational steps to produce a computer-implemented process, whereby the instructions executing on the computer, other programmable apparatus, or other device implement the functions / acts specified in one or more blocks of the flowcharts and / or block diagrams.

[0076] The flowcharts and block diagrams in the figures 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 the flowcharts or block diagrams may represent a module, segment, or portion of instructions that includes one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions noted in the blocks may occur in a different order than that noted in the figures. For example, two blocks shown in succession may actually be realized as a single step, or may be executed simultaneously, substantially simultaneously, partially or fully in a time-overlapping manner, or the blocks may be executed in the reverse order depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a special-purpose hardware-based system that performs the specified functions or actions or executes a combination of special-purpose hardware and computer instructions.

[0077] The description of various embodiments of the present invention has been presented for illustrative purposes, but 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 of the present invention. The terms used in this specification are selected to best explain the principles of the embodiments, practical applications, or technical improvements to the technology found in the market, or to enable those skilled in the art to understand the embodiments disclosed herein.

Claims

1. receiving, by one or more processors, input data having (i) a code level for an update, (ii) a scheduled time for said update; (iii) a target system for said update, and (iv) authorization data, where said authorization data (i) enables scheduling of said update and (ii) is provided over a channel external to a connection to said target system; receiving, by one or more processors, a set of data from the target system; transmitting, by one or more processors in response to receiving the set of data from the target system, a response packet having the input data to the target system; receiving a request to process the update by one or more processors at the scheduled time; transmitting, in response to the request, by one or more processors, code for processing the update corresponding to the code level for the update; and receiving, by one or more processors, status messages corresponding to the progress of the update. A computer-implemented method comprising:

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

3. 3. The computer-implemented method of claim 1 or claim 2, wherein the status message is attached to a remote support server request generated by the target system.

4. receiving, by one or more processors after transmitting the response packet with the input data to the target system, a confirmation from the target system that the update has been scheduled at the scheduled time for the update. The computer-implemented method of claim 1 , further comprising:

5. The computer-implemented method of claim 1 , wherein the status messages are received according to predetermined time intervals throughout the updates.

6. The computer-implemented method of claim 1 , wherein the set of data received from the target system is associated with a pre-scheduled periodic connection independent of the update.

7. The computer-implemented method of claim 1 , wherein the status message comprises information selected from the group consisting of: a reboot by the target system, an update progress, and an error.

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

9. receiving, by one or more processors, replicated input data from a first device, said input data having input data including: (i) a code level for an update, (ii) a scheduled time for said update; (iii) a target system for said update, and (iv) authorization data, where said authorization data (i) enables scheduling of said update and (ii) is provided over a channel external to a connection to said target system; receiving, by one or more processors, a set of data from a second computing device in communication with the target system; transmitting, by one or more processors in response to receiving the set of data from the second computing device, a response packet having the input data to the second computing device; receiving, at the scheduled time, a request from the second computing device to process the update by one or more processors; transmitting, by one or more processors in response to the request, code for processing the update corresponding to the code level for the update to the second computing device; and A computer-implemented method comprising receiving, by one or more processors, a status message from the second computing device corresponding to a progress of the update to the target system.

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

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

12. receiving, by one or more processors after transmitting the response packet with the input data to the second computing device, a confirmation from the second computing device that the update has been scheduled at the scheduled time for the update. The computer-implemented method of claim 9 , further comprising:

13. 13. The computer-implemented method of claim 9, wherein the status messages are received according to predefined time intervals throughout the updates.

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

15. 15. The computer-implemented method of claim 9, wherein the status message comprises information selected from the group consisting of: a reboot by the target system, an update progress, and an error.

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

17. A processor comprising: receiving input data having (i) a code level for an update, (ii) a scheduled time for said update; (iii) a target system for said update, and (iv) authorization data, said authorization data (i) enabling the scheduling of said update and (ii) provided over a channel external to a connection to said target system; receiving a set of data from the target system; in response to receiving the set of data from the target system, transmitting a response packet having the input data to the target system; receiving a request to process the update at the scheduled time; in response to the request, transmitting code for processing the update corresponding to the code level for the update; and receiving status messages corresponding to the progress of said update; A computer program for executing the following:

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

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

20. The processor, receiving, after transmitting the response packet having the input data to the target system, a confirmation from the target system that the update has been scheduled at the scheduled time for the update.

20. A computer program product as claimed in any one of claims 17 to 19, further comprising:

21. 21. A computer program product as claimed in any one of claims 17 to 20, wherein the status messages are received according to predefined time intervals during the updates.

22. 22. The computer program product of claim 17, wherein the set of data received from the target system is associated with a pre-scheduled periodic connection independent of the update.

23. 23. The computer program product of claim 17, wherein the status message comprises information selected from the group consisting of: a reboot by the target system, an update progress, and an error.

24. A processor comprising: receiving replicated input data from a first device, said input data including: (i) a code level for an update, (ii) a scheduled time for said update; (iii) a target system for said update, and (iv) authorization data, wherein said authorization data (i) enables scheduling of said update and (ii) is provided over a channel external to a connection to said target system; receiving a set of data from a second computing device in communication with the target system; in response to receiving the set of data from the second computing device, transmitting a response packet having the input data to the second computing device; program instructions for receiving, at the scheduled time, a request from the second computing device to process the update; in response to the request, transmitting to the second computing device code for processing the update corresponding to the code level for the update; and receiving a status message from the second computing device corresponding to a progress of the update to the target system; A computer program for executing the above.

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

Images