Computer-Implemented Method, Computer Program, Computer System, and Computer-Readable Recording Medium

Abstract

To provide a computer-implemented method, a computer program, computer system, and a computer readable recording medium.SOLUTION: A computer system 100 for updating a device is disclosed. The computer system 100 identifies that an update associated with the device is available, and includes a firmware update analyzer 600 for determining whether the available update associated with the device is permitted or not and a firmware update scheduler 140 for, in response to the available update associated with the device being permitted, determining an optimal scheduled time for performing the update on the device and performs the update on the device at the scheduled time.SELECTED DRAWING: Figure 1

Description

Technical Field

[0001] The present invention generally relates to the field of device updates, and more specifically, to optimizing the scheduling of software updates and firmware updates.

Background Art

[0002] A software update changes, modifies, or replaces any current software program on a computer, handheld mobile device, or smart home appliance. Software updates typically include minor improvements rather than major changes. Software updates can address any new security issues, software bugs, or problems with existing software. Often, software updates are necessary for the device to continue operating the software without problems. Continuing software updates ensures that the device runs the latest software. Small-scale software updates can be performed when the device that needs to be updated is being used by the user, but larger-scale updates may require that the device not be in use while the software update is being performed.

[0003] A firmware update is a software program used to update the firmware of a user device. A firmware update upgrades a computing device with evolved operating instructions without the need to upgrade any of the hardware of the user device. Firmware updates are used to improve the capabilities or fix problems of a computing device. To date, firmware updates have made it possible for computing devices to operate efficiently.

Summary of the Invention

Problems to be Solved by the Invention

[0004] The present invention aims to optimize the update schedule of a device.

Means for Solving the Problem

[0005] According to one embodiment of the present invention, a computer-implemented method for updating a device is disclosed. The computer-implemented method includes identifying that an update associated with the device is available. The computer-implemented method further includes determining whether an available update associated with the device is acceptable. The computer-implemented method further includes determining an optimally scheduled time for performing the update on the device in response to the available update associated with the device being acceptable. The computer-implemented method further includes performing the update at the scheduled time.

[0006] According to another embodiment of the present invention, a computer program for updating a device is disclosed. The computer program includes one or more program instructions that can be stored on one or more computer-readable recording media. The program instructions include identifying that an update associated with the device is available. The program instructions further include instructions for determining whether an available update associated with the device is acceptable. The program instructions further include determining an optimally scheduled time for performing the update on the device in response to the available update associated with the device being acceptable. The program instructions further include instructions for updating the device at the scheduled time.

[0007] According to another embodiment of the present invention, a computer system for updating a device is disclosed. The computer system includes one or more computer processors, one or more computer-readable recording media, and computer program instructions stored on one or more computer-readable recording media for execution by one or more computer processors. The program instructions include instructions for identifying that an update associated with the device is available. The program instructions further include instructions for determining whether an available update associated with the device is allowed. The program instructions further include instructions for determining an optimally scheduled time for performing an update on the device in response to an available and allowed update associated with the device. The program instructions further include instructions for performing an update of the device at the scheduled time.

[0008] The drawings included in this disclosure are included herein and form a part thereof. These are provided to illustrate embodiments of the disclosure and to explain the principles of the disclosure together with the description. The drawings merely exemplify certain embodiments and do not limit the disclosure.

Brief Description of the Drawings

[0009]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

[0010] The present invention generally relates to device updates, and more specifically to optimizing the scheduling of software updates and firmware updates.

[0011] New versions of software and firmware are released to users to fix minor issues, install new features, or otherwise change the current software or firmware on computing devices such as servers, laptops, handheld mobile devices, or smart electronic devices. Continuing to update software and firmware on computing devices is necessary to ensure that the device runs the latest version or is free from any bugs. If users delay updating their devices, it can cause the device to slow down, freeze, or operate in an unintended manner, ultimately changing the user experience. In some cases, software updates include security patches. In these cases, failing to update the device to the latest software update exposes the device to security breaches.

[0012] Minor updates can be installed in the background of the device while the user is using it. Typically, larger updates require a temporary device shutdown or restart, which makes the device temporarily unavailable to the user. Shutting down or restarting the user device is inconvenient for the user and disrupts their work schedule. For this reason, many users delay completing updates to their devices. Generally, notifications on user devices alert the user to update their device's software or firmware immediately or at a point in time delayed by the user. Larger updates also require that the user device have a sufficient charge level while connected to a charger.

[0013] Embodiments of the present invention recognize that it can be difficult to determine the most convenient time to update a group of devices that are not tied to a single location, handle applications with strict schedules, or both. For example, if a user is currently using their device, updating the device is likely inconvenient for the user because they are currently using the device. Embodiments of the present invention further recognize that if a user plans to update their devices at a scheduled time, the scheduled time may no longer be convenient for the user by the time the device software needs to be updated. Similarly, some operating systems schedule automatic updates during periods of low general utilization that are convenient for some users, excluding others. A user may also simply forget to perform the update at the scheduled time, or it may not be easy to make the power cable available at the scheduled update time, or both. In any of these scenarios, the user's device will fall behind on software updates, leaving the device vulnerable to security breaches and potential unintended performance issues.

[0014] Embodiments of the present invention further recognize the following problems or disadvantages with respect to the scheduling and execution of system updates: (i) users do not have sufficient knowledge or feel comfortable performing system updates themselves, and thus require the assistance of more experienced individuals; (ii) some operating systems force updates without consulting the user, which can result in loss of data, productivity, or both; (iii) inexperienced users may not even be aware that updates are available, necessary, or both; and (iv) important information may be accidentally deleted if the device is not updated within a certain time threshold.

[0015] Embodiments of the present invention address the above deficiencies by finding the optimal and convenient time to schedule software updates by analyzing the user's schedule. Embodiments of the present invention recognize that many factors influence the optimal time for a software update. Thus, embodiments of the present invention analyze many factors, including but not limited to, the user's personal and business calendars, the device's charge level, the device's charge threshold, or both, the device's screen time, network status, and Wi-Fi connectivity, to determine and schedule the optimal time to perform a software update. In an embodiment, a mutually available time is determined for a plurality of interdependent devices. In an embodiment, the time available for future device updates is learned, at least in part, based on the availability of the device for the update and the past update times for a particular device or devices.

[0016] Embodiments of the present invention further recognize that updating server computers is complex at many different levels. Updates can force system downtime, require logging back into the server computer, or even be incompatible with the server. For example, if the server hardware level does not support the latest firmware update, it may be necessary to leave the server at the current older version. Conversely, other servers may not require that level of firmware due to the hardware level installed on the server. In another example, certain server computers under test at the system level may require a specific firmware level for verification. Nevertheless, a user of the server may not want a firmware update for a particular code stream, but may want an update for another code stream.

[0017] Embodiments of the present invention further recognize that scheduling server updates across a cluster of servers can be both difficult and cumbersome for server computer administrators, IT teams, or both. For example, update times may need to be determined for all computing devices in a data center in order to perform necessary / specific firmware updates on a single computing device to minimize downtime or impact on the workloads of other devices. Further, automatic updates can be discretionary, if not impossible, due to the different levels of updates required and the order in which the updates should be performed, and the fact that certain updates may only apply to certain server computers. For example, on a system test floor, there are multiple test corners focused on different functions with different workload runtimes. While code is being released and updated, there may be a need for the test team to determine whether to update the servers, update all servers and apply patches not related to the test focus, or apply patches that do not conform to a specific hardware level. Accordingly, embodiments of the present invention recognize the need for automatic scheduling of machine updates for server groups, taking into account the update requirements for specific servers within a specific workload, availability, hardware level, convenience, and server group.

[0018] 0025 Embodiments of the present invention provide one or more of the following features, characteristics, operations, effects, or combinations thereof: (i) managing code updates / patch applications for specific servers in an environment such as a data center; (ii) identifying scheduled events along with the system's workload(s) and automatically determining an optimal time to perform software / hardware updates / patch applications; (iii) automatically updating various server computers based on the availability of the server computers and the need for firmware sub-stream updates during system utilization / testing; and (iv) automatically updating various server computers based on the availability of the server computers and the server hardware level under testing and utilization (e.g., if a server computer has a lower-level Ficon card that does not support a particular firmware update, then identifying a different firmware update that does not target the lower-level Ficon card); and scheduling and updating server updates based on system availability, the interdependencies of other servers or computing devices that require the utilization of a specific server scheduled for update, the availability of the server computer, and the need for firmware sub-stream updates.

[0019] The present invention can provide a computer system, a computer-implemented method, a computer program, or a computer-readable recording medium, in any possible integration at any possible level of technical detail. The computer program includes computer-readable program instructions for causing a processor, which the computer-readable recording medium (or media) has thereon, to perform aspects of the present invention.

[0020] A computer-readable recording medium can be a tangible device that can hold and store multiple instructions for use by an instruction execution device. The computer-readable medium can be, for example, but not limited to, an electrical recording device, a magnetic recording device, an optical recording device, an electromagnetic recording device, a semiconductor recording device, or any preferred combination thereof. More specific examples of computer-readable recording media include, but are not limited to, the following: portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory (registered trademark)), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disks (DVD), memory sticks, floppy disks (registered trademark), punch cards, or mechanically encoded devices having structures that project into grooves in which instructions are recorded, and any preferred combination thereof. As used herein, a computer-readable recording medium is not itself to be construed as a transient signal such as a radio wave or other freely propagating electromagnetic wave, a waveguide or other communication medium (e.g., an optical pulse passing through an optical fiber cable), or an electrical signal communicated through a wire.

[0021] The computer programs described herein can be downloaded from a computer-readable recording medium to respective computing / processing devices, or can be downloaded to an external computer or an external recording device via a network such as, for example, the Internet, a local area network, a wide area network or a wireless network and combinations thereof. The network can include copper communication cables, optical communication fibers, wireless communication routers, firewalls, switches, gateway computers and edge servers or combinations thereof. A network adapter card or network interface in each computing / processing device receives computer-readable program instructions from the network and transfers the computer-readable program instructions to a computer-readable recording medium within each computing / processing device for storage therein.

[0022] Computer-readable program instructions for carrying out the operations of the present invention may be source code or object code written in any combination of programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine language instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, configuration data for integrated circuits, or one or more procedural programming languages such as the object-oriented programming languages Smalltalk®, C++, the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partly on the user's computer as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN), a wide area network (WAN), or the connection may be made to an external computer (e.g., through an Internet service provider). In some embodiments, an electrical circuit, including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), can personalize and execute the electrical circuit using the state information of the computer-readable program instructions to execute the features of the present invention.

[0023] The features of the invention described herein have been described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer-readable recording media and computer programs according to embodiments of the invention. It should be understood that any combination of flowchart illustrations and / or block diagrams and / or blocks in the flowchart illustrations and / or block diagrams can be implemented by computer-readable program instructions.

[0024] Computer-readable program instructions can be provided to a computer's processor or other programmable data processing apparatus for generating a computer, and cause the functions / operations specified by blocks or multiple blocks in a flowchart and block diagram or combinations thereof to be implemented by execution by the computer's processor or other programmable data processing apparatus. These computer-readable program instructions that direct a computer, programmable data processing apparatus, and other devices or combinations thereof to function in a particular manner can also be stored in a computer-readable recording medium, and the computer-readable recording medium storing the instructions constitutes a manufactured article that includes instructions for implementing the features of the functions / operations specified by blocks or multiple blocks in a flowchart and block diagram or combinations thereof.

[0025] Computer-readable program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other device, and cause a computer-implemented process to occur for a series of operation steps on the computer, other programmable apparatus, or other device, thereby implementing the functions / operations specified by blocks or multiple blocks in a flowchart and block diagram or combinations thereof on the computer, other programmable apparatus, or other device.

[0026] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and possible implementation operations of systems, methods, and computer programs according to various embodiments of the present invention. In this regard, a flowchart or block diagram can represent a module, segment, or portion of instructions, which include one or more executable instructions for implementing a particular logical function (or functions). In some alternative implementations, the functions described in the blocks can be executed differently than shown. For example, two blocks shown in succession can, depending on the functions involved, be performed as one step in practice, and can be executed simultaneously, substantially simultaneously, partially or completely overlapping in time, or the blocks can sometimes be executed in reverse order. Also, the illustrations of the block diagrams and flowcharts, or both of them and the blocks in the block diagrams and the illustrations in the flowcharts or combinations of them, indicate that they can be implemented by a system based on specific hardware for performing a specific function or operation or for performing specific hardware and computer instructions for a particular purpose.

[0027] The description of various embodiments of the present invention is presented for illustrative purposes and is not intended to be exclusive or limiting of 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 terms used in this specification are selected to best explain the principles of the embodiments, the practical application, or a technical improvement over technologies found in the market, or to enable those skilled in the art to understand the embodiments disclosed herein.

[0028] 0035 The present invention will be described in detail below with reference to the drawings. FIG. 1 is a functional block diagram of a network computing environment for scheduling an optimal time for firmware update according to at least one embodiment of the present invention, generally indicated by reference numeral 100. FIG. 1 provides an illustration of only one implementation and is not meant to imply any limitation with respect to the environments in which different embodiments may be implemented. Many modifications to the illustrated environment can be made by those skilled in the art without departing from the scope of the present invention as recited in the claims.

[0029] Computing system 100 includes a master server computer 105, an update analysis server computer 135, and a server computer 145 interconnected via network 130. In various embodiments of the present invention, the master server computer 105, the update analysis server computer 135, and the server computer 145 can be any electronic device or computing system capable of transmitting and receiving data, such as a stand-alone device, a management server, a web server, a mobile device, or any other electronic device. In an embodiment, the master server computer 105, the update analysis server computer 135, and the server computer 145 represent a server computing system that uses a number of server systems, such as a cloud computing environment. In an embodiment, the master server computer 105, the update analysis server computer 135, and the server computer 145 represent clustered computers and components (e.g., multiple database server computers, application server computers, web server computers, etc.), which function as a single pool of seamless resources when the network computing environment is accessed. Generally, the master server computer 105, the update analysis server computer 135, and the server computer 145 execute machine-readable program instructions, communicate with each other within the master server computer 105 via a network such as network 130, and communicate with other devices (not shown), and can represent any electronic device or combination of programmable electronic devices that are programmable.

[0030] The master server computer 105 includes a master schedule 110 and a server list 111. In an embodiment, the master server computer 105 controls the update of the server computer 145. In an embodiment, the master server computer 105 monitors the performance conditions and workloads of the server computer 145. In an embodiment, the master server computer 105 transmits updates to other servers such as the server computer 145 within the network 130. In an embodiment, the master server computer 105 automatically approves firmware updates to be sent to one or more server computers 145, either through the user's administrator or both of them.

[0031] In an embodiment, the master schedule 110 includes the schedule information of the master server computer 105. In an embodiment, the schedule 110 includes information related to the current, future, or both workloads of the master server computer 105 related to the updates to be performed on the server computer 145. In an embodiment, the schedule 110 includes information and time for other master tasks in addition to the updates. For example, these master tasks can include various meetings, lunch breaks, appointments, or other events associated with specific users with master privileges. In an embodiment, the schedule 110 includes information on the time when the master server computer 105 can handle updates from the server list 111 of the server computer 145. In an embodiment, the server list 111 includes a list of server computers managed by the master server computer 105.

[0032] In an embodiment, a priority value is assigned to a server computer whose priority value is included in server list 111. For example, a higher priority value for a server computer is placed higher than a server computer having a lower priority value that should be updated on schedule 110. This means that a server computer having a higher priority value will be updated before a server computer having a lower priority value. In an embodiment, the priority value is based on a determination of the need for a server computer on which to perform a server update. For example, a server with firmware version 2.0 will have a higher need to be updated than a server computer with firmware version 2.1. In an embodiment, the priority value is determined by comparing the current firmware and the firmware update. In an embodiment, server list 111 changes over time by both adding and removing server computers managed by master server computer 105.

[0033] Update analysis server 135 includes update analysis program 101, which further includes firmware update analyzer 600, firmware update scheduler 140, and system profile learner 500. In an embodiment, firmware update analyzer 600 integrates the information included in master schedule 110 with the availability information of one or more server computers 145 (described in more detail later with reference to FIG. 3) to determine whether a particular server computer 145 requests an update and, if an update is necessary, whether the update is permitted.

[0034] The firmware update scheduler 140 is a module or subprogram of the update analysis program 101 that schedules firmware updates for one or more server computers 145. In an embodiment, the firmware update scheduler 140 schedules and stores a firmware update reminder within the workload / event schedule 150 of the server computer 145. In an embodiment, the firmware update scheduler 140 schedules and stores a firmware update reminder within the schedule 110 of the master server computer 105.

[0035] The system profile learner 500 is a module or subprogram of the update analysis program 101 that determines the respective system configuration profile 155 of the server computer 145. In an embodiment, the system profile learner 500 determines the firmware or hardware level of the server computer 145. In an embodiment, the system profile learner 500 determines the available time of the server computer 145 for performing an update. Further embodiments of the system profile learner 500 will be described in more detail below with reference to FIG. 2.

[0036] Server computer 145 includes a workload / event schedule 150, a system configuration profile 155, a system firmware level 160, and a system hardware level 165. In an embodiment, server computer 145 is managed by a master server computer 105. In an embodiment, workload / event schedule 150 includes historical workload data associated with a particular server computer 145. In an embodiment, workload / event schedule 150 includes software or firmware updates, current, future, or both workloads, and scheduled events such as system downtime associated with a particular server computer. In an embodiment, system configuration profile 155 includes respective configuration parameters for server computer 145. In an embodiment, system configuration profile 155 includes the hardware and firmware levels associated with server computer 145. In an embodiment, update analysis program 101 identifies the firmware and hardware levels and determines whether server computer 145 requires a firmware update. In an embodiment, the firmware level requiring an update is determined based on a user command or a predetermined improper configuration. In an embodiment, if the firmware level cannot have a patch applied, these firmware levels are stored as an exception within system configuration profile 155. In an embodiment, the hardware level requiring an update is determined based on a user command, a predetermined improper configuration, or unsupported hardware. In an embodiment, if the hardware level cannot have a patch applied, these hardware levels are stored as an exception within system configuration profile 155.In an embodiment, the workload / event schedule 150 is included within the system configuration profile 155.

[0037] In an embodiment, the system configuration profile 155 includes rules for a specific server computer 145. The rules for the server computer 145 include levels of firmware or hardware, and include whether the update analysis program 101 should or should not update, and whether a specific firmware level or hardware level for which the update is not permitted. The rules for the server computer 145 are determined by the requirements for firmware or hardware specialized for the specific server computer 145.

[0038] In an embodiment, the server computer 145 has multiple firmware levels. In an embodiment, the firmware levels operate, manage, and control the server computer 145. For example, the server computer 145 includes an install level, an activation level, and an allowable level. Generally, the install level of server firmware is what is installed and loaded into memory after the management system is powered off and then powered on. The activation level is the level at which the server firmware or the power subsystem firmware is active and operating in memory. The allowable level is the backup level of the server or the power subsystem firmware. Typically, the allowable level of firmware is the level used when the server deletes the install level. In an embodiment, the system firmware level 160 includes information about one or more install levels, activation levels, or allowable levels.

[0039] In an embodiment, system hardware level 165 includes low-level or high-level hardware components. Generally, the hardware level of an operating system controls the use of physical system resources such as, for example, a memory manager, a process manager, and a disk drive. The hardware level should not be updated if identified by a user command, a predetermined improper configuration, or unsupported hardware.

[0040] 0047 In various embodiments of the present invention, update analysis program 101 manages the application of software updates or patches to a particular server computer in a data center environment. In an embodiment, update analysis program 101 determines that a server update is necessary. In an embodiment, update analysis program 101 generates a configuration file as will be described in more detail according to FIG. 3 below. In an embodiment, update analysis program 101 uses firmware update analyzer 600 to determine the optimal time at which the server update should be scheduled. Update analysis program 101 uses firmware update scheduler 140 to update schedule 110 and the workload / event schedule 150 of the server computer based on the configuration profile 155 of the server computer. In an embodiment, update analysis program 101 schedules the optimal server update time based on schedule 110.

[0041] In an embodiment, the master server computer 105 identifies scheduled events for the system workload and determines the optimal time to perform a firmware update or patch application in order to reduce machine downtime. In an embodiment, the master server computer 105 updates various server computers 145 based on the availability of one or more server computers 145, the need for an update to the firmware substream, or system availability. In an embodiment, the update to the firmware substream includes LPAR, OSA, CFCC (coupling), Power, and HMC / SE. In an embodiment, the master server computer 105 updates various server computers 145 based on the availability of the server computer and the hardware level. For example, if the server computer 145 does not support a firmware update, the server computer 145 can use a specific update that does not target this lower-level hardware.

[0042] In an embodiment, the update analysis program 101 determines a number of optimal times for server updates. In these embodiments, the update analysis program 101 assigns a score for each available time. In an embodiment, the update analysis program 101 automatically performs an update on the server at the scheduled optimal time based on prior learning from previous update attempts.

[0043] In an embodiment, the update analysis program 101 determines that there is no overlap between the workload / event schedule 150 and the schedule 110. For example, if both schedules indicate that there is a calendar event at that time, the update analysis program 101 will determine that there is no overlap between the workload / event schedule 150 and the schedule 110. That is, if the workload / event schedule 150 indicates that there is an event from 3:00 PM to 4:00 PM on January 4, 2020, the update analysis program 101 means that there is no overlap between the two schedules from 3:00 PM to 4:00 PM on January 4, 2020. However, if both schedules indicate that there are no calendar events scheduled from 4:00 PM to 5:00 PM on January 4, 2020, the update analysis program 101 indicates that there is an overlap between the workload / event schedule 150 and the schedule 110. If it is shown that there is no overlapping time at all initially, the update analysis program 101 increases the time span for investigating the overlap time. For example, if the update analysis program 101 determines that there is no available overlapping time on January 4, the update analysis program 101 then expands the time span for investigating the overlap time to two days to determine whether there is available overlapping time on January 4 and January 5.

[0044] FIG. 2 is a flowchart diagram showing the operational steps for generating a system configuration file according to at least one embodiment of the present invention, generally indicated by reference numeral 200. FIG. 2 is merely illustrative of one implementation form and does not imply any limitation with respect to the environment in which different embodiments can be implemented. Many modifications to the illustrated environment can be made by those skilled in the art without departing from the spirit of the present invention as recited in the claims.

[0045] In step S202, the update analysis program 101 identifies the firmware level of the server computer. For example, the update analysis program 101 identifies the embedded software instructions of the server computer to identify the firmware level of the server computer. In an embodiment, the identified firmware level is stored in a configuration file such as the system configuration file 155. In an embodiment, the firmware level automatically queries from the specific firmware configuration file and the configuration scheme of the operating system on the server computer 145. In an embodiment, the firmware level of the server computer 145 is manually input into the system configuration profile 155 by a user with administrative privileges.

[0046] In step S204, the update analysis program 101 identifies the hardware level of the server computer. For example, the update analysis program 101 identifies the embedded software instructions of the server computer to identify the hardware level of the server computer. In an embodiment, the identified hardware level is stored in a configuration file such as the system configuration file 155. In an embodiment, the hardware level of the server computer 145 is manually input into the system configuration profile 155 by a user with administrative privileges.

[0047] In step S206, the update analysis program 101 determines whether there is a firmware level that does not require an update. In an embodiment, the update analysis program 101 determines that a specific firmware level for a specific server computer 145 should not be updated based on one or more of, but not limited to, user commands, pre-determined improper configurations, and unsupported firmware. For example, if the current firmware level does not support new updates, it can be determined that an update is not necessary. For example, the firmware level may be required to remain unchanged in a server test environment for simulating specific client operations that may reproduce specific events. If it is determined that there is a firmware level that requires an update (decision step S206, "YES" branch), the update analysis program 101 proceeds to step S208. If it is determined that there is no firmware level that requires an update (decision step S206 "NO" branch), the update analysis program 101 proceeds to decision step S210.

[0048] In step S208, the update analysis program 101 stores information regarding which specific firmware level is required for a server that requires an update, and which firmware level is for a server that does not require an update, should not be updated, or both, in a configuration file.

[0049] In decision step S210, the update analysis program 101 determines the hardware level at which an update is not necessary. In an embodiment, the update analysis program 101 determines, for a specific server computer 145, that a specific hardware portion, which is not limited thereto, should not be uploaded based on one or more of user instructions, pre-determined improper configurations, and unsupported hardware. For example, a pre-determined improper hardware configuration can include system resource settings assigned to a specific device. In an embodiment, unsupported hardware may be the case where the physical hardware within the system cannot support an update. In an embodiment, when future unreleased prototype hardware is being tested within the server computer 145, a specific prototype hardware can be protected from an update at the current release level of the firmware to prevent hardware failures. If it is determined that there is a hardware level that requires an update (branch of decision step S210 “YES”), the update analysis program 101 proceeds to step S212. If it is determined that there is no hardware that requires an update (branch of decision step S210 “NO”), the update analysis program 101 proceeds to step S214.

[0050] In step S212, the update analysis program 101 stores, in the configuration file, information regarding which specific firmware level is required for a server that requires an update, and which firmware level is required for a server that does not require an update, should not be updated, or both.

[0051] In step S214, the update analysis program 101 searches for and stores the workload / event schedule 150 of the server computer in the system configuration file 155.

[0052] In step S216, the update analysis program 101 generates a configuration file.

[0053] FIG. 3 is generally indicated by reference numeral 300 and is a flowchart showing operational steps for scheduling a firmware update according to at least one embodiment of the present invention. FIG. 3 merely illustrates one implementation form and does not imply any limitation with respect to the environment in which different embodiments can be implemented. Many changes to the illustrated environment can be made by those skilled in the art without departing from the spirit of the present invention as recited in the claims.

[0054] In decision step S302, the update analysis program 101 determines whether there is an available update for a server computer such as the server computer 145. If it is determined that there is no available update (branch of decision step S302 “NO”), the update analysis program 101 returns to the start of the operational steps. If it is determined that there is an available update (branch of decision step S302 “YES”), the update analysis program 101 proceeds to decision step S304.

[0055] In decision step S304, the update analysis program 101 determines whether there is a server computer that needs to be updated. In an embodiment, the update analysis program 101 determines that a server computer needs to be updated based on one or more of, but not limited to, user commands, pre-determined incorrect configurations, and unsupported firmware. In an embodiment, the update analysis program 101 compares the current firmware level of each server computer with the latest update to determine whether the server computer is operating with an old version. If it is determined that there is no server computer that needs to be updated (the branch of "NO" in decision step S304), the update analysis program 101 returns to the start of the operation step. If it is determined that there is a server computer that needs to be updated (the branch of "YES" in decision step S304), the update analysis program 101 proceeds to step S306.

[0056] In step S306, the update analysis program 101 loads the system configuration profile associated with the server computer. For example, the update analysis program 101 loads the system configuration file 155 generated for the specific server computer 145 according to FIG. 2 above.

[0057] In step S308, the update analysis program 101 determines whether there is any schedule overlap within the set time frame. In the embodiment, the update analysis program 101 compares the master schedule 110 of the server computer with the workload / event schedule 150 of the server computer to determine the available time for overlap to perform the update within a predetermined time frame. If there is no overlap in the schedule within the set time frame (the branch of decision step S310 “NO”), the update analysis program 101 proceeds to step S312. If it is determined that there is an overlap within the set time frame (the branch of decision step S310 “YES”), the update analysis program 101 proceeds to step S314.

[0058] 0065 In step S312, the update analysis program 101 increases the predetermined time frame for performing the update. In the embodiment, the update analysis program 101 can increase the time width of the time frame. For example, if the update analysis program 101 detects that there is no sufficiently long continuous time period for both the server computer 145 and the master server computer 105 to complete the update, it increases the time width of the time frame and determines whether the allowable time period for performing the update between devices overlaps with another time period in the more distant future. If it is determined to increase the time frame for investigating the future time period when the update should be completed, and no overlap of the allowable time period for completing the update is found, the update analysis program 101 can perform a forced update on the server computer 145.

[0059] In step S314, the update analysis program 101 schedules the firmware update. In an embodiment, the update analysis program 101 schedules an update for one or more server computers 145 based on a comparison between the master schedule 110 and the respective workload / event schedule 150 of the one or more server computers 145 that require an update. In an embodiment, the update analysis program 101 schedules an update for one or more server computers 145 based on a comparison between the master schedule 110 and the workload / event schedule of each server computer of all server computers 145, and determines the firmware schedule time for one or more server computers 145 that require an update. For example, only one server computer 145 requires an update, but other server computers 145 may depend on the particular server computer 145 that requires an update. Therefore, determine the overlapping time to complete the update based on the master schedule 110 of the master server computer 105, the particular server computer 145 that requires an update, and additional server computers 145 that depend on the above particular server computer 145 that requires an update, and find the time that minimizes the impact of the server computer update on these other dependent server computers. In an embodiment, one or more server computers 145 are updated at once by the update analysis program 101. The plurality of steps in FIG. 3 can be repeated to determine whether additional server computers 145 require available updates.

[0060] 0067 FIG. 4 is generally designated by reference numeral 400 and shows a functional block diagram of a computing system for scheduling an optimal time for software updates according to one embodiment of the present invention. FIG. 4 is merely illustrative of one implementation form and does not imply any limitation with respect to the environment in which different embodiments can be implemented. Many changes to the illustrated environment can be made by those skilled in the art without departing from the spirit of the present invention as recited in the claims.

[0061] The user device 401 can represent a user's computing device, such as a laptop computer, a tablet computer, a notebook computer, a personal computer, a desktop computer, a personal digital assistant (PDA), a smartphone, a wearable device (e.g., smart glasses, smart watch, e-textile, AR headset, etc.) or any programmable computer system known in the art. Generally, the device 401 represents any electronic device or combination of electronic devices capable of executing computer-readable program instructions.

[0062] Computer system 400 includes user device 401 and server 135 interconnected on network 430. User device 401 includes user interface 403 and application 404. User interface 403 provides an interface between a user of an end-user device such as user device 401 and multiple applications existing within the device. A user interface such as user interface 403 refers to information provided by a program to the user (such as graphics, text, and sound) and control sequences used by the user to control the program. There are various types of user interfaces. In one embodiment, user interface 403 is a graphical user interface. A graphical user interface (GUI) is a type of user interface, such as a computer keyboard and mouse, that enables a user to interact with an electronic device through graphical icons and visual indicators, which are secondary display methods, as opposed to text-based interfaces, typed command codes, or text navigation. In computing, GUI(s) were introduced as a reaction to the steep learning curve required for command-line interfaces that require commands typed on a keyboard. Operations in GUI(s) are often performed through direct manipulation of graphical elements. In another embodiment, user interface 403 is a script or application programming interface (API).

[0063] Application 404 can represent one or more applications (e.g., a combination of applications) that can operate on user device 401. In various exemplary embodiments, application 404 can be an application located on the user device. In other embodiments, application 404 can be an application of another mobile device (e.g., a web browser, a messaging application specific to an enterprise, a social media application, an application for software updates, firmware, and the hardware level of the device, etc.). For example, application 404 can be a client - side application associated with server 435 (e.g., a client - side application associated with update analysis program 101).

[0064] In additional embodiments, application 404 can, according to various embodiments of the present invention, perform the processing steps of update analysis program 102 (i.e., application 404 can represent update analysis program 102 operating on user device 3401). For example, a user of user device 401 can receive update reminders, viewing software, firmware, hardware updates scheduled for the user's device, options for specific updates, approvals, rejections, and cancellations of scheduled updates using application 404, or combinations thereof.

[0065] The user device 401 further includes an update notification system 405, a schedule 410, a device status 415, a location service 420, and a device role 425. In an embodiment, the update notification system 405 is a component or subprogram of the update analysis program 102 that is used to alert the user that an update is available. In some embodiments, the alert by the update notification system 405 can be a pop-up window or a drop-down box. In an embodiment, the schedule 410 further includes the historical screen usage of the user device 401. For example, if the user device is typically used from 2:00 pm to 5:00 pm on Wednesdays, the update analysis program 102 records this information in the schedule 410. In an embodiment, the schedule 410 includes the historical charge level of the user device. Those skilled in the art will recognize that the schedule 410 can include the schedule (calendar) of one or more users of the user device 401.

[0066] In an embodiment, the device status 415 includes various performance states of the user device, such as the charging level of the device and the Wi-Fi status. In an embodiment, the charging level indicates what percentage of the device's battery is. In an embodiment, the charging level indicates whether the device is currently charging or not. In an embodiment, the charging level indicates whether it exceeds a pre-determined threshold level required to complete a specific update. In an embodiment, the device status 415 includes the historical usage of the device and the historical charging time of the device. In an embodiment, the Wi-Fi status can be classified by the strength of the Wi-Fi connection of the user device to Wi-Fi. In an embodiment, the location service 420 includes various location information for the current and future positions of the user device, and the device role 425 includes various information including whether the device is a master device or a slave device for a specific user device.

[0067] The server 435 includes an update analysis program 102, and further includes a device firmware update analyzer 300, a firmware update scheduler 440, and a device profile learner 450. In an embodiment, the program 102 is a subprogram of the program 101. In an embodiment, the program 102 is different from the program 101 or separated from the program 101. In an embodiment, the device firmware update analyzer 300 is a module or subprogram of the update analysis program 102 used to analyze firmware updates. In an embodiment, the device firmware update analyzer 300 combines the overall schedule of one or more user devices 401, the availability of the server, and the availability of information (described in more detail later with reference to FIG. 5) to determine whether a specific user device 401 needs an update and, if an update is needed, whether the update is acceptable.

[0068] In an embodiment, the firmware scheduler 440 is a module or subprogram of the update analysis program 102 that is used to schedule updates on a user device. In an embodiment, the firmware scheduler 440 schedules and stores a reminder of a firmware update on the schedule 410 within the schedule 410 of the user device 401.

[0069] In an embodiment, the device profile learner 450 is a module or subprogram of the update analysis program 102 that determines the firmware level or hardware level of the user device 401 for performing an update. In an embodiment, the device profile learner 450 determines the available time of the user device 401. Further embodiments of the device profile learner are described in more detail below with reference to FIG. 6.

[0070] In an embodiment, the user device 401 may require a software update, a firmware update, a hardware update, or a combination thereof. In an embodiment, the update analysis program 102 analyzes the schedule 410, the device status 415, the location service 420, and the device role 425 to determine the optimal time to update the software on the user device 401. In an embodiment, the update analysis program 102 is based on one or more of, but not limited to, the user schedule of the device, the usage history of the device, the screen time history of the device, the current location of the device, the future location of the device, the charging history of the device, the current charge level of the device, the Wi-Fi connection history of the device, and the current Wi-Fi connectivity of the device. Determine the optimal time to update the software based on multiple factors. In an embodiment, the update analysis program 102 determines the time when the device is not in use, has a sufficient charge level, and has a sufficient Wi-Fi connection as the time to perform the software update. In an embodiment, once such an optimal time is determined, the update program 102 schedules the date and time of such an update on the schedule 410.

[0071] In an embodiment, a user may need assistance to update the software, firmware, hardware, or a combination thereof of a device. Therefore, the update analysis program 102 can determine whether the device that needs an update is a master device or a slave device. In an embodiment, the update analysis program 102 can schedule a software update for a slave device when the master device and the slave device are available. In an embodiment, the update analysis program 102 links the master device to one or more slave devices. In an embodiment, the update analysis program 102 notifies the master device that the update time for one or more slave devices is available. In an embodiment, the update analysis program 102 updates a family of mobile devices.

[0072] In an embodiment, the update analysis program 102 determines a number of optimal times for updating a user device. Here, the update analysis program 102 can assign a score for each available time. In an embodiment, the update analysis program 102 automatically performs an update on one or more user devices at the scheduled optimal time based on prior learning from previous update attempts, previous completed update times, or both.

[0073] In an embodiment, the update analysis program 102 determines whether there is no available time overlap between the schedule of the child device and the master schedule. In an embodiment, the child schedule is the schedule of the user device that needs an update, and the master schedule is the schedule of the user device that supports the update. For example, if the update analysis program 102 indicates that there are events calendared at that time for both schedules, it can be determined that there is no overlap between the child schedule and the master schedule. If it is shown that there is no overlap time at all initially, the update analysis program 102 increases the overlap time width. For example, if the update analysis program 102 determines that there is no available time overlap on January 4th, the update analysis program 102 then increases the overlap time width to two days and determines whether there is available time overlap from January 4th to January 5th.

[0074] FIG. 5 is a flowchart diagram showing the operational steps for generating a calendar option for a child device, according to at least one embodiment of the present invention, generally indicated by reference numeral 500. FIG. 5 is merely illustrative of one implementation form and does not imply any limitation with respect to the environments in which different embodiments can be implemented. Many modifications to the illustrated environment can be made by those skilled in the art without departing from the spirit of the present invention as recited in the claims.

[0075] In step S502, the update analysis program 102 determines whether an update is available. If it is determined that the update is not available (branch of decision step S502 “NO”), the update analysis program 101 returns to step S502. If it is determined that the update is available (branch of decision step S502 “YES”), the update analysis program 102 proceeds to decision step S504.

[0076] In decision step S504, the update analysis program 102 determines whether the user device requires an update (e.g., software, firmware, hardware, or a combination of these updates). In an embodiment, if the device's hardware or firmware cannot support available updates, the update analysis program 102 determines that the user device does not require an update. If it is determined that the device does not require an update (the branch of decision step S504 “NO”), the update analysis program 102 returns to step S504. If it is determined that an update is available (the branch of decision step S504 “YES”), the update analysis program 102 proceeds to step S506.

[0077] In step S506, the update analysis program 102 operates the device profile learner. Embodiments of the device profile learner will be described in more detail later with reference to FIG. 6.

[0078] In decision step S508, the update analysis program 102 determines whether there is a master device that supports the update of the sub-devices. If it is determined that there is no master device (the branch of decision step S508 “NO”), the update analysis program 101 proceeds to step S510. If it is determined that there is a master device (the branch of decision step S508 “YES”), the update analysis program 101 proceeds to step S514.

[0079] In decision step S510, the update analysis program 102 determines whether there is an overlap over a pre-determined time frame of the schedule. If it is determined that there is no overlap in the schedule over the pre-determined time frame (branch of decision step S510 “NO”), the update analysis program 102 proceeds to step S512. If it is determined that there is an overlap in the schedule over the set time frame (branch of decision step S510 “YES”), the update analysis program 102 proceeds to step S516.

[0080] In step S512, the update analysis program 102 increases the time width of the overlap. In an embodiment, the update analysis program 102 can increase the time width within the time frame. For example, if the update analysis program 102 detects continuous insufficient time to complete the update between both the server master device and the child device, it increases the time width of the time frame and determines whether an acceptable time period in which the update can be performed between the devices overlaps with yet another time period in the future. If no overlapping time interval for completing the update is found even by increasing the time frame for investigating future time intervals for completing the update, the update analysis program 102 can forcefully perform the update on the child device.

[0081] In step S514, the update analysis program 102 generates calendar options for the master device. In an embodiment, the update analysis program 102 records the update times available in the calendar of the master device.

[0082] In step S516, the update analysis program 102 generates calendar options for the child device. In an embodiment, the update analysis program 102 records the update times available in the calendar of the child device.

[0083] 0090 Figure 6 is a flowchart diagram generally indicated by reference numeral 600 and showing the operational steps for scheduling an update of a user device according to at least one embodiment of the present invention. Figure 6 is merely illustrative of one implementation form and does not imply any limitation with respect to the environment in which different embodiments can be implemented. Many changes to the illustrated environment can be made by those skilled in the art without departing from the spirit of the present invention as recited in the claims.

[0084] In step S602, the update analysis program 102 determines the availability of the user of the device. In an embodiment, the update analysis program 102 determines the availability of the user of the device based on the schedule 410.

[0085] In decision step S604, the update analysis program 102 determines whether the user is available. For example, the update analysis program 102 can determine whether the user is available when the device update requires user input such as password entry, acceptance or rejection of the update, selection of various user options during the update, and the like. If it is determined that the user is not available (branch of decision step S604 “NO”), the update analysis program 102 proceeds to step S606. If it is determined that the user is available (branch of decision step S604 “YES”), the update analysis program 102 proceeds to step S610.

[0086] In step S606, the update analysis program 102 determines the event type of the user. In the embodiment, the update analysis program 102 determines the type of the calendar event. For example, the update analysis program 102 determines whether the calendar event is a business meeting, a medical appointment, or lunch. In the embodiment, the update analysis program 102 determines whether the event type of the user is due to the location being specified on the calendar. In the embodiment, the update analysis program 102 instructs the user to indicate the event type.

[0087] In decision step S608, the update analysis program 102 determines whether the user event requires the use of the device. For example, the update analysis program 102 determines that the user event is a medical appointment and that there is no need to use the device. In other embodiments, the update analysis program 102 determines that the user event is a business meeting that requires the device. In an embodiment, the update analysis program 102 determines whether the use of the device is necessary based on the location being specified with the location service 420 for the user event on the calendar event. In an embodiment, the update analysis program 102 determines whether the user event requires the use of device location tracking. For example, if the update analysis program 102 determines that it is at a coffee shop, the update analysis program 102 can determine that this event does not require the use of the device. In an embodiment, the update analysis program 102 instructs the user to indicate whether they need to use their devices for the event or not. In an embodiment, the update analysis program 102 accesses the historical use of the device for similar event types to determine whether the user event requires the use of the device. If the event is determined not to require the device (branch of decision step S608 “NO”), the update analysis program 102 proceeds to step S610. If the event is determined to require the device (branch of decision step S608 “YES”), the update analysis program 102 proceeds to step S614.

[0088] In step S610, the update analysis program 102 analyzes the user's screen time. In an embodiment, the update analysis program 102 determines whether the user has historically used their device at 6:00 p.m. on Tuesdays.

[0089] In decision step S612, the update analysis program 102 determines whether the user device is currently in use. In an embodiment, if the user is currently using the device, the device is in use. In an embodiment, if an application is operating on the device, the device is in use. In an embodiment, if data is being communicated to, from, or both to and from the device, the device is in use. If it is determined that the device is in use (the branch of decision step S612 “YES”), the update analysis program 102 proceeds to step S614. If it is determined that the device is not in use (the branch of decision step S612 “NO”), the update analysis program 102 proceeds to step S616.

[0090] In step S616, the update analysis program 102 determines whether there is an acceptable network connection. In an embodiment, an acceptable network connection is a network speed that exceeds a pre-determined threshold level for performing a particular update. In an embodiment, an acceptable network connection is a network bandwidth that exceeds a pre-determined threshold level for performing a particular update. If it is determined that there is no acceptable network connection (the branch of decision step S616 “NO”), the update analysis program 102 proceeds to step S614. If it is determined that the device has an acceptable network connection (the branch of decision step S616 “YES”), the update analysis program 102 proceeds to step S618.

[0091] In decision step S618, the update analysis program 102 determines whether the charging level of the user device is acceptable. In an embodiment, the acceptable charging level is determined based at least in part on the remaining percentage of battery life exceeding a pre-determined threshold level for a particular update. In an embodiment, the acceptable charging level is further determined based on the power consumption between particular updates. In an embodiment, the acceptable power reception level is further determined based on the battery type, the age of the battery, and the historical battery usage data of a particular user device. If it is determined that the charging level is not acceptable (branch of decision step S618 “NO”), the update analysis program 102 proceeds to step S614. If it is determined that the device has an acceptable charging level (branch of decision step S618 “YES”), the update analysis program 102 proceeds to step S620.

[0092] In step S614, the update analysis program 102 marks that the pre-determined time interval for updating the user device in the firmware scheduler 440 is not available.

[0093] In step S620, the update analysis program 102 marks that the pre-determined time interval for updating the user device in the firmware scheduler 440 is available.

[0094] FIG. 7 is a block diagram generally designated by reference numeral 700 and showing components of a computing device suitable for executing update analysis program 101 and update analysis program 102 according to one embodiment of the present invention. Computing device 700 includes one or more processors 704 (one or more computer processors), a communication function 702, a memory 706 including a RAM 716 and a cache 718, a firmware update analyzer 600, a firmware update scheduler 140, and a system profile learner 500, an update analysis program 101, and a device firmware update analyzer 300, a firmware scheduler 440 and a device profile learner 450, a persistent storage 708 including an update analysis program 102, a communication unit 712, an I / O interface (which may be plural) 714, a display 722, and external devices (which may be plural) 720. FIG. 7 merely illustrates one implementation form and does not mean any limitation regarding an environment in which different embodiments can be implemented. Many changes to the illustrated environment can be made by those skilled in the art without departing from the spirit of the present invention as recited in the claims.

[0095] As shown, computing device 700 includes a communication function 702, which provides communication between the processor(s) 704, the memory 706, the persistent storage 708, the communication unit 712, and the I / O interface(s) 714. Communication function 702 can be implemented by any architecture suitable for passing data or controlling information between the processor(s) 704 (e.g., one or more microprocessors, one or more communication processors, or one or more network processors), the memory 706, the external device(s) 720, and any other hardware components within the system.

[0096] Memory 706 and persistent storage 708 are computer-readable recording media. In the illustrated embodiment, memory 706 includes random-access memory (RAM) 716 and cache 718. In general, memory 706 can include any suitable one or more volatile or non-volatile computer-readable recording media.

[0097] The program instructions for update analysis program 101 and update analysis program 102 can be stored in persistent storage 708, or more generally on any computer-readable recording medium, for execution by one or more respective computer processors (plural is okay) via one or more memories 706. Persistent storage 708 can be a magnetic hard disk drive, a solid-state disk drive, a semiconductor recording device, a read-only memory (ROM), an electronically erasable programmable read-only memory (EEPROM), flash memory, or any other computer-readable recording medium capable of storing program instructions or digital information.

[0098] The medium used by persistent storage 708 can also be made removable. For example, a removable hard drive can be used for persistent storage 708. Other examples include magneto-optical disks, thumb drives (trademark), and smart cards that are inserted into a drive for transfer onto another computer-readable recording medium that is part of persistent storage 708.

[0099] The communication unit 712 provides communication with other data processing systems or devices in these embodiments. In these embodiments, the communication unit 712 includes one or more network interface cards. The communication unit 712 can provide communication through either or both physical or wireless communication links. In the context of some embodiments of this embodiment, the sources of various input data may be physically remote from the computing device 700, can receive the input data, and the output can similarly communicate via the communication unit 712.

[0100] The I / O interface(s) 714 enables input and output of data with other devices that can be connected to the computer 700. For example, the I / O interface 714 can provide a connection to external device(s) 720 such as a keyboard, keypad, touch screen, or some other suitable input device. The external device(s) 720 can also include, for example, a thumb drive (trademark), portable optical or magnetic disk, and memory card. The software and data used to implement the embodiments of the present invention can be stored on a portable computer-readable recording medium as described above and loaded into the persistent storage 708 via the I / O interface 714. The I / O interface 714 can also connect a display 722. The display 722 provides a function for displaying data to the user and can be, for example, a computer monitor.

[0101] This disclosure includes a detailed description of cloud computing, but the teachings cited in this disclosure are not limited to cloud computing environments. Rather, the embodiments of the present invention can be implemented in combination with any other type of computing environment known now or developed later.

[0102] Cloud computing is a service delivery model for convenient, on-demand network access to a shared pool of configurable computing resources (such as networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. This cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0103] The characteristics are as follows:

[0104] On-demand self-service: Cloud consumers can automatically and unidirectionally provision as much computing capability as needed, such as server time and network storage, without the need for human interaction with the service provider.

[0105] Broad network access: Capabilities are available over the network and accessed through standard mechanisms that promote use by different thin or thick client platforms (such as mobile phones, laptops, and PDAs).

[0106] Resource pooling: Provider computing resources are pooled to serve multiple consumers with different physical and virtualized resources that are dynamically assigned and reassigned as needed. There is a sense of location independence in that consumers generally have no control or knowledge of the exact location of the provided resources (such as country, state, or data center) and can specify location at a high level of abstraction.

[0107] Rapid elasticity: The function can be supplied quickly and elastically, and in some cases automatically, scale out rapidly, and be released quickly to scale in rapidly. For consumers, the functions available for supply often appear to have no restrictions and can be purchased in any quantity at any time.

[0108] Measured services: The cloud system automatically controls and optimizes resource usage by leveraging metering functions at several abstraction levels suitable for service types (e.g., storage, processing, bandwidth, and active user accounts). By monitoring, controlling, and reporting resource usage, transparency can be provided to both the providers and consumers of the services being used.

[0109] The service model is as follows:

[0110] Software as a Service (SaaS): The function provided to the consumer is to use the provider's application running on the cloud infrastructure. The application is accessible from various client devices through a thin-client interface such as a web browser (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, server, operating system, storage, or the functions of individual applications, except for limited user-specific application configuration settings.

[0111] Platform as a Service (PaaS): The capabilities provided to the consumer are to place the applications created or acquired by the consumer, which are created using the programming languages and tools supported by the provider, on the cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, which includes the network, servers, operating systems, or storage, but controls the deployed applications and, if possible, configures the application hosting environment.

[0112] Infrastructure as a Service (IaaS): The functions provided to the consumer are the provision of processing, storage, network, and other basic computing resources, and the consumer can deploy and run any software that can include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but has control over the operating system, storage, and deployed applications, and has limited control over select networking components (e.g., the host firewall) if possible.

[0113] The deployment models are as follows.

[0114] Private cloud: The cloud infrastructure operates only for one organization. This can be managed by that organization or a third party and can exist on-premises or off-premises.

[0115] Community Cloud: The cloud infrastructure is shared by several organizations and supports a specific community with common interests (e.g., mission, security requirements, policies, and compliance considerations). It can be managed by those organizations or a third party and can exist on - premise or off - premise.

[0116] Public Cloud: The cloud infrastructure is made available to the general public or a large industry group and is owned by an organization that sells cloud services.

[0117] Hybrid Cloud: The cloud infrastructure is a combination of two or more clouds (private, community, or public), which remain distinct entities but are joined together by standardized or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0118] Cloud software is service - oriented, focusing on statelessness, loose coupling, modularity, and semantic interoperability. At the heart of cloud computing is the infrastructure, which includes a number of interconnected nodes.

[0119] FIG. 8 shows an exemplary cloud computing environment 50. As shown, cloud computing environment 50 includes one or more cloud computing nodes 10 that communicate with local computing devices such as, for example, a personal digital assistant (PDA) or cellular phone 54a, desktop computer 54B, laptop computer 54C, or automotive computer system 54N or combinations thereof, used by cloud consumers. The cloud computing nodes 10 can communicate with one another. These can be physically or virtually grouped (not shown) within one or more networks such as the private, community, public, or hybrid clouds described above, or combinations thereof. The types of computing devices 54A-N shown in FIG. 8 are for illustrative purposes only, and it is understood that the cloud computing nodes 10 and the cloud computing environment 50 can communicate with any type of computerized device through any type of network or addressable network connection (e.g., a web browser), or both.

[0120] Referring now to FIG. 9, a set of functional abstraction layers provided by the cloud computing environment 50 of FIG. 8 is shown. It should be understood that the components, layers, and functions shown in FIG. 9 are for illustrative purposes only and that embodiments of the present invention are not limited thereto. As shown, the layers and corresponding functions described below are provided.

[0121] The hardware and software layer 60 includes hardware and software components. Examples of hardware components can include a mainframe 61; a plurality of servers 62 based on RISC (Reduced Instruction Set Computer) architecture; a plurality of servers 63; a plurality of blade servers 64; a plurality of storage devices 65; and a network and networking components 66. In some embodiments, software components can include network application server software 67 and database software 68.

[0122] The visualization layer 70 provides an abstract layer where examples of virtual entities to be described later are provided; virtual servers 71; virtual storage 72; a virtual network 73 including a virtual private network; virtual applications and operating systems 74; and virtual clients 75.

[0123] In one embodiment, the management layer 80 can provide the following functions. The resource provider 81 provides for the dynamic acquisition of computing resources and other resources used to perform tasks within the cloud computing environment. The measurement and pricing unit 82 provides cost tracking when resources are used within the cloud computing environment and also provides billing or invoicing for the consumption of these resources. In one embodiment, these resources can include application software licenses. The security unit provides protection of data and other resources along with the identification and authentication of cloud consumers and tasks. The user portal unit 83 provides access to the cloud computing environment for consumers and to the system administrator. The service level management unit 84 provides the allocation and management of cloud computing resources and conforms to the required service levels. The service level agreement (SLA) planning and fulfillment unit 85 makes advance preparations for and acquires cloud computing resources required for future requests according to the SLA.

[0124] The workload layer 90 provides an exemplification of functions for utilizing the cloud computing environment. Examples of the workloads and functions provided by this layer can include mapping and navigation 91; software development and lifetime management 92; virtual classroom education delivery 93; data analysis processing 94; transaction processing 95; and device update processing 96.

Description of Reference Numerals

[0125] 100: Computer system 101: Update analysis program 105: General server computer 110: General schedule 111: Server list 130: Network 135: Update Analysis Server Computer 140: Firmware Update Scheduler 145: Server Computer 150: Workload / Event Schedule 155: Configuration Profile 160: System Firmware Level 165: System Hardware Level 500: System Profile Learner 600: Firmware Update Analyzer

Claims

1. A computer-implemented method for updating a device, the method comprising causing a computer to identify that an update associated with the device is available; determine whether the available update associated with the device is permitted; wherein the update is an update of a firmware sub-stream, and in response to a determination that at least a portion of the update is not permitted based on a particular portion of lower-level hardware that is the target of the update, determine whether an alternative firmware sub-stream update that does not target the particular portion of the lower-level hardware is available; and in response to determining that the alternative firmware sub-stream update that does not target the particular portion of the lower-level hardware is available, perform the alternative firmware sub-stream update on the device. A computer-implemented method as set forth above.

2. Determining an optimal time scheduled to perform the firmware update on the device further comprises determining a mutually available time for the device and the workload with respect to one or more additional devices on which the device and the workload are mutually dependent, based on which the computer-implemented method according to claim 1 is determined.

3. Determining an optimal time scheduled to perform the update on the device further comprises analyzing the historical availability of at least one of the devices or the historical update times of the updates performed on the device to perform the update, based on which the computer-implemented method according to claim 1 or 2 is determined.

4. Determining an optimal time scheduled to perform the update on the device further comprises determining a mutually available time for the device and the master device to perform the update, and providing the update for the device, based on which the computer-implemented method according to any one of claims 1 to claim 3 is determined.

5. Determining an optimal time scheduled to perform the update on the device comprises (i) the calendar of the user of the device, (ii) the schedule of the master device, (iii) the workload of the device, (iv) additional devices each having a workload that depends on the device, (v) the battery charge level of the device exceeding a predetermined level, (vi) the historical screen time of the device, and (vii) the network The computer-implemented method according to any one of claims 1 to 4, which is based on

6. The computer-implemented method according to any one of claims 1 to 5, wherein the device is at least one of a mobile device or a server.

7. A computer program for updating a device, the computer program including program instructions for execution by a computer, the computer program causing the computer to identify that an update associated with the device is available; determine whether the available update associated with the device is acceptable; wherein the update is an update of a firmware sub-stream, and in response to a determination that at least a portion of the update is not acceptable based on a specific portion of the lower-level hardware that is the target of the update, determine whether an alternative firmware sub-stream update that does not target the specific portion of the lower-level hardware is available; and perform the alternative firmware sub-stream update on the device in response to the availability of the alternative firmware sub-stream update that does not target the specific portion of the lower-level hardware A computer program

8. Determining the optimal time scheduled to perform the update on the device further includes The computer program according to claim 7, which is based on determining a mutually available time for the device and the workload with respect to one or more additional devices on which the device and the workload are mutually dependent.

9. ​ Determining the optimal time scheduled to perform the update on the device is further based on analyzing the historical availability of at least one of the devices or the historical update times of the updates performed on the device in order to perform the update, computer program according to claim 7 or 8.

10. Determining the optimal time scheduled to perform the update on the device is further Based on determining the mutually available times for the device on which the update is to be performed and the master device and providing the update for the device, computer program according to any one of claims 7 to 9.

11. Determining the optimal time scheduled to perform the update on the device (i) the calendar of the user of the device, (ii) the schedule of the master device, (iii) the workload of the device, (iv) additional devices having respective workloads that depend on the device, (v) the battery charge level of the device exceeding a pre-determined level, (vi) the historical screen time of the device, and (vii) the network Based on, computer program according to any one of claims 7 to 10.

12. The device is at least one of a mobile device or a server, computer program according to any one of claims 7 to 11.

13. A computer system for updating a device, One or more computer processors, One or more computer-readable recording media Including, the computer system Means for identifying that an update associated with the device is available, Means for determining whether the available update associated with the device is acceptable, The update is an update of a firmware substream, and in response to a determination that at least a portion of the update is not allowed based on a specific portion of the lower-level hardware that is the target of the update, Means for determining whether an update of an alternative firmware sub-stream that does not target a specific part of the lower-level hardware is available; Means for performing an update of the alternative firmware sub-stream on the device in response to the availability of an update of the alternative firmware sub-stream that does not target a specific part of the lower-level hardware A computer system including the same. **Claim 14** The means for determining an optimal time scheduled for performing the update on the device further includes The computer system according to claim 13, further including means for determining a mutually available time for the device and the workload with respect to one or more additional devices on which the device is mutually dependent. **Claim 15** The means for determining an optimal time scheduled for performing the update on the device further includes means for analyzing a historical availability of at least one of the devices for performing the update or a historical update time of an update performed on the device, according to claim 13 or 14. The computer system described. **Claim 16** The means for determining an optimal time scheduled for performing the update on the device further includes The computer system according to any one of claims 13 to 15, further including means for determining a mutually available time for the device and the master device for performing the update and providing the update to the device. **Claim 17** A computer-readable recording medium recording a computer program for causing a computer to execute the computer-implemented method according to any one of claims 1 to 6.

Images