OPTIMIZING A UNIT UPDATE PLAN
Patent Information
- Application Number
- DE102021131913
- Authority / Receiving Office
- DE · DE
- Patent Type
- Patents
- Current Assignee / Owner
- Priority Date
- 2020-12-14
- Filing Date
- 2021-12-03
- Publication Date
- 2025-08-14
- Estimated Expiration
- 2041-12-03
Smart Images

Figure 00000000_0000_ABST
Abstract
Description
BACKGROUND
[0001] The present invention relates generally to the field of device updating and, more particularly, to optimizing software and firmware update scheduling.
[0002] A software update modifies, corrects, or changes any current software program on a computer, mobile handheld device, or smart appliance. Software updates typically involve small improvements rather than major changes. Software updates can address any new security issues, software bugs, or problems with existing software. Software updates are often necessary to keep a device running without software problems. Staying up to date with software updates ensures that a device is running the latest software. While minor software updates can occur when the device requiring the update is in use by the user, major software updates may require the device to be out of use when the software update is 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 advanced operating instructions without requiring any hardware upgrades. Firmware updates are used to enhance the capabilities of a computing device or to fix problems with a computing device. By keeping firmware updates up to date, a computing device is able to run efficiently.
[0004] There are already published documents in this context. Document US 6 167 567 A describes techniques for automated updates of software stored on a client computer in a network client-server environment. For this purpose, an update script is stored on a network server for each software product to be updated, which is then used for the update. Document US 2013 / 0 346 955 A1 describes adaptive patching of computer programs based on a calendar. The time for a scheduled update can be based on entries in the calendar. Furthermore, document US 2006 / 0 106 806 A1 describes a system and method for software updates for mobile devices.Despite these advances, there is still a need to further improve software updates on network devices so that there is little or no disruption or impact on workflows. SUMMARY
[0005] This problem is solved by the subject matter of the independent patent claims. Further embodiments are also contained in the dependent patent claims.
[0006] 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 the available update associated with the device is permissible. The computer-implemented method further includes, in response to the available update associated with the device being permissible, determining an optimal scheduled time for performing the update on the device. The computer-implemented method further performs the update on the device at the scheduled time.
[0007] According to another embodiment of the present invention, a computer program product for updating a device is disclosed. The computer program product includes one or more computer-readable storage media and program instructions stored on the one or more computer-readable storage media. 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 the available update associated with the device is permissible. The program instructions further include instructions for determining, in response to the available update associated with the device being permissible, an optimal scheduled time for performing the update on the device.The program instructions also contain instructions to perform the update on the unit at the scheduled time.
[0008] 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 storage media, and computer program instructions, wherein the computer program instructions are stored on the one or more computer-readable storage media for execution by the 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 the available update associated with the device is permissible.The program instructions further include instructions for determining an optimal scheduled time for performing the update on the device in response to the available update associated with the device being allowed. The program instructions further include instructions for performing the update on the device at the scheduled time. BRIEF DESCRIPTION OF THE DRAWINGS
[0009] The drawings included in this disclosure are incorporated in and constitute a part of the specification. They illustrate embodiments of the present disclosure and, in addition to the description, serve to explain the principles of the disclosure. The drawings only illustrate certain embodiments and are not limiting of the disclosure. Fig. 1 is a functional block diagram of a network computing environment, generally designated 100, for scheduling an optimal time for a firmware update in accordance with at least one embodiment of the present invention. Fig. 2 is a flowchart diagram illustrating operational steps for generating a configuration file according to at least one embodiment of the present invention. Fig. 3 is a flowchart diagram illustrating operations for scheduling a firmware update according to at least one embodiment of the present invention. Fig. 4 is a functional block diagram of a data processing system, generally designated 400, for scheduling an optimal time for a software update in accordance with at least one embodiment of the present invention. Fig. 5 is a flowchart diagram illustrating operations for generating calendar options for a child unit according to at least one embodiment of the present invention. Fig. 6 is a flowchart diagram illustrating operational steps for scheduling a software update in accordance with at least one embodiment of the present invention. Fig. 7 is a block diagram illustrating components of a computer, generally designated 700, suitable for executing an update analysis program 101 in accordance with at least one embodiment of the present invention. Fig. 8 is a cloud computing environment according to an embodiment of the present invention. Fig. 9 illustrates abstraction model layers according to an embodiment of the present invention. DETAILED DESCRIPTION
[0010] The present invention relates generally to the field of device updating and, more particularly, to optimizing scheduling of software and firmware updates.
[0011] New versions of software and firmware are periodically released to a user to fix minor issues, install new features, or otherwise modify the current software or firmware on a computing device such as a server, laptop, mobile handheld device, or smart appliance. Keeping software and firmware updates on a computing device up-to-date is necessary to ensure that the device is running the latest version or that the device is free of bugs. If a user delays updating their device, it may cause the device to slow down, freeze, or respond in an undesirable manner, ultimately negatively impacting the user experience. In some cases, software updates include security fixes.In these cases, failing to keep a unit up-to-date with the latest software updates can leave the unit exposed to security vulnerabilities.
[0012] Small updates may be able to be performed in the background of the unit while a user is using the unit. Larger updates typically require the unit to be temporarily turned off or restarted, making the unit temporarily unavailable to a user. Turning off or restarting a user unit can be inconvenient for a user and disrupt their work schedule. For this reason, many users put off performing updates on their units. In general, prompts on a user unit can be used to remind the user to update their unit's software or firmware immediately or at a later time specified by the user.For major updates, the user unit may also require a sufficient battery level and be connected to a charger.
[0013] Embodiments of the present invention recognize that determining the most appropriate time to update a group of devices is difficult, particularly for devices that are not tied to a single location and / or do not have a specific scheduled use. For example, if a user is currently using their device, updating the device immediately is likely to be inconvenient for the user because they are currently using their device. Embodiments of the present invention further recognize that if a user wants to update their device's software at a scheduled time, and the scheduled time for updating the device's software has arrived, the scheduled time may no longer be convenient for the user.Accordingly, some operating systems schedule automatic updates during times of day with generally low usage, which may be convenient for some users but not for others. The user may also simply forget to perform the update at the scheduled time, or a power source and / or power cable may not be readily available at the scheduled update time. Any of these scenarios can result in a user's device being out of date with software updates, potentially exposing the device to security vulnerabilities and unwanted performance issues.
[0014] Embodiments of the present invention further address the following problems or disadvantages in scheduling and performing system updates: (i) a user may not have sufficient expertise or feel insecure performing system updates on their own, requiring assistance from a more experienced person; (ii) some operating systems force updates without consulting the user, which may result in loss of data and / or productivity; (iii) inexperienced users may not even be aware that updates are available and / or necessary; and (iv) important information may be inadvertently deleted if an entity is not updated within a certain time threshold.
[0015] Embodiments of the present invention improve the above-mentioned deficiencies by analyzing a user's schedule to find an optimal and convenient time to schedule a software update. Embodiments of the present invention consider that many factors influence the optimal time for a software update. Accordingly, embodiments of the present invention analyze many factors, such as, but not limited to, a user's personal and work calendar, a device's battery level and / or charging threshold, a device's screen time, a network status, and a Wi-Fi connection, to determine and schedule an optimal time to proceed with a software update. In one embodiment, mutually available update times are determined for a plurality of interdependent devices.In one embodiment, available times for future device updates are learned based at least in part on past device availability for updates and past update times for one or more devices.
[0016] Embodiments of the present invention further recognize that server computer updates are complex in many ways. Updates may force system downtime, require a user to re-login to a server computer, or may even be incompatible with a server. For example, if server hardware versions do not support the latest firmware updates, the server may need to maintain the current, older version. Conversely, other servers may not require a corresponding firmware version for the hardware versions installed in those servers. As another example, certain server computers for system-level testing may require a specific firmware version for verification. Users of the server may not want firmware updates for a particular code stream, but may want updates for other code streams.
[0017] Embodiments of the present invention further recognize that scheduling server updates across a cluster of servers is both difficult and costly for a server computer administrator / IT team. For example, an update time 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 negative impact on the workload of other devices. Furthermore, automatic updates may not be feasible at all due to the need for different update versions, the order in which the updates must be performed, and the fact that certain updates may only be applicable to certain server computers.For example, a system testing room may have multiple test areas focused on different functions with different workload runtimes. During code releases and updates, there may be times when test teams do not require server updates, do not require updates for all servers, do not require patches unrelated to a test focus, or do not require patches that are not targeted to specific hardware versions. Accordingly, embodiments of the present invention contemplate a need for automatically scheduling machine updates for a server group, taking into account the respective workloads, availability, hardware versions, usability, and update requirements of the particular server in the server group.
[0018] Embodiments of the present invention provide one or more of the following features, characteristics, operations, and / or advantages: (i) managing code updates / patches for specific servers in a data center-like environment; (ii) identifying scheduled events along with one or more system workloads to automatically determine optimal times to perform software updates / patches and thereby reduce system downtime; (iii) automatically updating various server computers based on server computer availability and one or more firmware substream update requests during system use / testing; and (iv) automatically updating various server computers based on server computer availability and server hardware versions during testing and during use (e.g.if a server computer has an outdated FICON card that does not support a particular firmware update, another firmware update that does not target the outdated FICON card is identified); and automatically scheduling and updating a server update based on system usage (interdependence of other servers or compute devices that require use of a particular server for which an update is scheduled), server computer availability, and firmware substream update requirements.
[0019] The present invention may be a system, a method, and / or a computer program product with any possible degree of technical integration. The computer program product may include a computer-readable storage medium (or media) with computer-readable program instructions for causing a processor to carry out aspects of the present invention.
[0020] The computer-readable storage medium may be any physical device capable of retaining and storing instructions for use by an instruction execution unit. The computer-readable storage medium may be, for example, but is 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 the computer-readable storage medium includes the following: a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM), orFlash memory), a static random access memory (SRAM), a portable CD-ROM, a DVD (Digital Versatile Disc), a memory stick, a floppy disk, a mechanically encoded device such as punched cards or raised structures in a groove on which instructions are stored, and any suitable combination thereof. A computer-readable storage medium, as used herein, shall not be construed as containing 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., pulses of light traveling through fiber optic cables), or electrical signals transmitted through a wire.
[0021] Computer-readable program instructions described herein may be downloaded from a computer-readable storage medium to respective computing / processing units or to an external computer or storage unit via a network such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, fiber optic transmission lines, wireless transmission, routers, firewalls, switching units, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing unit receives computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing unit.
[0022] Computer-readable program instructions for performing operations of the present invention may be assembly language instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including object-oriented programming languages such as Smalltalk, C++, or the like, as well as conventional procedural programming languages such as the C programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server.In the latter case, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, over the Internet using an Internet service provider). In some embodiments, electronic circuits, including, for example, programmable logic circuits, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), may execute the computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuits to perform aspects of the present invention.
[0023] Aspects of the present invention are described herein with reference to flowchart and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart and / or block diagram, as well as combinations of blocks in the flowchart and / or block diagram, may be implemented using computer-readable program instructions.
[0024] These computer-readable program instructions may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine, such that instructions executing via the processor of the computer or other programmable data processing apparatus produce a means for implementing the functions / steps specified in the flowchart and / or block diagram block(s). These computer-readable program instructions may also be stored on a computer-readable storage medium capable of directing a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer-readable storage medium on which instructions are stored comprises an article of manufacture, including instructions implementing aspects of the function(s) specified in the flowchart and / or block diagram block(s).implement the function / step specified in the blocks of the flow charts and / or block diagrams.
[0025] The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of process steps to be performed on the computer, other programmable apparatus, or other device to produce a computer-implemented process such that the instructions executing on the computer, other programmable apparatus, or other device implement the functions / steps specified in the block(s) of flowcharts and / or block diagrams.
[0026] 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 comprising one or more executable instructions for performing the particular logical function or functions. In some alternative implementations, the functions specified in the block may occur in a different order than shown in the figures. For example, two blocks shown in succession may actually execute substantially concurrently, or the blocks may sometimes execute in reverse order depending on the corresponding functionality.It is further to be understood that each block of the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by special purpose hardware-based systems that perform the specified functions or steps, or by combinations of special purpose hardware and computer instructions.
[0027] The descriptions of the various embodiments of the present invention have been presented for illustrative purposes and are not intended to be exhaustive or limited to the disclosed embodiments. Those skilled in the art will appreciate that numerous modifications and variations are possible without departing from the scope and spirit of the described embodiments. The terminology used herein has been chosen to best explain the principles of the embodiments, practical application, or technical improvement over current technologies, or to enable others skilled in the art to understand the embodiments disclosed herein.
[0028] The present invention will now be described in detail with reference to the figures. Fig. 1 is a functional block diagram of a network computing environment, generally designated 100, for scheduling an optimal time for a firmware update in accordance with at least one embodiment of the present invention. Fig. Figure 1 provides an illustration of only a single implementation and does not imply any limitations on the environments in which various embodiments may be implemented. Those skilled in the art may make numerous modifications to the illustrated environment without departing from the spirit and scope of the invention as claimed.
[0029] The data processing system 100 includes an administrator server computer 105, an update analysis server computer 135, and server computer 145, which are interconnected via a network 130. In various embodiments of the invention, the administrator server computer 105, the update analysis server computer 135, and the server computer 145 are each a data processing unit, which may be a standalone unit, a management server, a web server, a mobile unit, or any other electronic unit or data processing system capable of receiving, sending, and processing data. In one embodiment, the administrator server computer 100, the update analysis server computer 135, and the server computer 145 represent a server data processing system that uses multiple computers as a server system, e.g.,in a cloud computing environment. In one embodiment, the administrator server computer 100, the update analysis server computer 135, and the server computer 145 represent a data processing system that utilizes clustered computers and components (e.g., database server computers, application server computers, web server computers, etc.) that serve as a single pool of seamless resources when accessed within the network computing environment 100. In general, the administrator server computer 105, the update analysis server computer 135, and the server computer 145 represent any programmable electronic device or combination of programmable electronic devices capable of executing machine-readable program instructions and communicating with each other and with other devices (not shown) over a network, such asthe network 130 within the network data processing environment 100 to exchange data.
[0030] The administrator server computer 105 includes an administrator plan 110 and a server list 111. In one embodiment, the administrator server computer 105 controls updates for the server computer 145. In one embodiment, the administrator server computer 105 monitors the performance conditions and workloads of the server computer 145. In one embodiment, the administrator server computer 105 transmits updates to other servers in the network 130, such as the server computer 145. In one embodiment, the administrator server computer 105 automatically and / or through a user administrator approves firmware updates to be distributed to one or more of the server computers 145.
[0031] In one embodiment, schedule 110 includes information about a schedule of administrator server computer 105. In one embodiment, schedule 110 includes information about the current and / or future workload of administrator server 105 related to updates being performed for server computer 145. In one embodiment, schedule 110 includes information and times for other administrative tasks in addition to updates. For example, these administrative tasks may include various meetings, a lunch break, appointments, or other events associated with a particular user with administrator privileges. In one embodiment, schedule 110 includes information about the times from server list 111 of server computer 145 that the server computer administrator 105 is responsible for updating.In one embodiment, the server list 111 contains a list of the server computers managed by the server computer administrator 105.
[0032] In one embodiment, the server computers included in server list 111 are assigned a priority value. For example, a higher priority value for a server computer would be placed ahead of a server computer with a lower priority value for updating according to schedule 110. Thus, a server computer with a higher priority value would be updated before a server computer with a lower priority value. In one embodiment, a priority value is based on determining the need to perform a server update for server computer 145. For example, a server with firmware version 2.0 has a higher need to be updated than a server with firmware version 2.1. In one embodiment, a priority value is determined by comparing the current firmware and the firmware update.In one embodiment, the server list 111 changes over time as a server computer 145 managed by the server computer administrator 105 is either added or removed.
[0033] The update analysis server 135 includes an update analysis program 101, which further includes a firmware update analyzer 600, a firmware update scheduler 140, and a system profile learner 500. In one embodiment, the firmware update analyzer 600 is a module or subprogram of the update analysis program 101 that analyzes firmware updates for the server computer 145. In one embodiment, the firmware update analyzer 600 combines information contained in the administrator plan 110 with the (discussed below with respect to Fig. 4) availability information of one or more of the server computers 145 to determine whether a particular server computer 145 requires an update, and if an update is required, 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 of the server computers 145. In one embodiment, the firmware update scheduler 140 schedules and stores firmware update reminders within a workload / event schedule 150 of the server computer 145. In one embodiment, the firmware update scheduler 140 schedules and stores firmware update reminders within the schedule 110 of the administrator server computer 105.
[0035] The system profile learner 500 is a module or subprogram of the update analysis program 101, which determines the respective system configuration profile 155 of the server computer 145. In one embodiment, the system profile learner 500 determines the firmware or hardware versions of the server computer 145. In one embodiment, the system profile learner 500 determines the available times of the server computer 145 for performing updates. Further embodiments of the system profile learner 500 are described below with respect to Fig. 2 described in more detail.
[0036] The server computer 145 contains the workload / event plan 150, the system configuration profile 155, system firmware versions 160, and system hardware versions 165. In one embodiment, the server computer 145 is managed by the administrator server computer 105. In one embodiment, the workload / event plan 150 contains historical workload data associated with a particular server computer 145. In one embodiment, the workload / event plan 150 contains scheduled events such as software or firmware updates, current and / or future workloads, and system downtime associated with a particular server computer 145. In one embodiment, the system configuration profile 155 contains corresponding configuration parameters for the server computer 145. In one embodiment, the system configuration profile 155 contains the hardware and firmware versions associated with a server computer 145.In one embodiment, the update analyzer 101 identifies the firmware versions and hardware versions to determine whether a server computer 145 requires a firmware update. In one embodiment, the firmware versions requiring an update are determined based on a user prompt or predetermined invalid configurations. If a firmware version cannot be patched, these firmware versions are stored as exceptions in the system configuration profile 155, in one embodiment. In one embodiment, the hardware versions requiring an update are determined based on a user prompt, predetermined invalid configurations, or unsupported hardware. If a hardware version cannot be patched, these hardware versions are stored as exceptions in the system configuration profile 155, in one embodiment.In one embodiment, the workload / event plan 150 is included in the system configuration profile 155.
[0037] In one embodiment, system configuration profile 155 includes rules for a particular server computer 145. Rules for server computer 145 may include the versions of firmware or hardware that update analyzer 101 should or should not update, as well as the specific firmware or hardware versions for which updating is permitted or prohibited. Rules for server computer 145 may be determined by the firmware or hardware requirements specific to a particular server computer 145.
[0038] In one embodiment, the server computer 145 has multiple firmware versions. In one embodiment, the firmware versions operate, manage, and control the server computer 145. For example, the server computer 145 includes an installed version, an activated version, and a permissible version. Generally, an installed version of server firmware is installed and installed in memory after the managed system is powered off and on. An activated version is the version of the server firmware or power subsystem firmware that is active and running in memory. A permissible version is the backup version of a server or power subsystem firmware. Typically, a permissible firmware version is the version the server uses to remove the installed version.In one embodiment, the system firmware versions 160 include information about one or more of the installed versions, enabled versions, or allowed versions.
[0039] In one embodiment, system hardware versions 165 include hardware components with a low or high version. Generally, an operating system's hardware version controls the use of physical system resources, such as the memory manager, process manager, and disk drivers. Hardware versions should not be updated if indicated by a user prompt, a default invalid configuration, or unsupported hardware.
[0040] In various embodiments of the present invention, the update analysis program 101 manages software updates or patches for a specific server computer in a data center environment. In one embodiment, the update analysis program 101 determines that a server update is needed. In one embodiment, the update analysis program 101 creates a configuration file, as described with respect to Fig. 3 described in more detail below. In one embodiment, the update analyzer 101 uses the firmware update analyzer 600 to determine an optimal time to schedule a server update. The update analyzer 101 uses the firmware update scheduler 140 to update the schedule 110 and the server computer workload / event schedule 150 based on the server computer configuration profile 155. In one embodiment, the update analyzer 101 schedules an optimal server update time in the schedule 110.
[0041] In one embodiment, the administrator server computer 105 identifies scheduled events with the system workload to determine optimal times to perform a firmware update or patch, thereby reducing machine downtime. In one embodiment, the administrator server computer 105 updates various ones of the server computers 145 based on the availability of one or more of the server computers 145, firmware substream update requests, or system usage. In one embodiment, the firmware substream includes LPAR, OSA, CFCC (Coupling), Power, and HMC / SE. In one embodiment, the administrator server computer 105 updates various ones of the server computers 145 based on server computer availability and hardware versions.For example, if a server computer 145 does not support a firmware update, the server computer 145 may use specific updates that do not target that legacy hardware.
[0042] In one embodiment, the update analysis program 101 determines multiple optimal times for a server update. In these embodiments, the update analysis program 101 assigns a score to each available time. In one embodiment, the update analysis program 101 automatically performs an update on the servers at the scheduled optimal time based on prior learning from previous update attempts.
[0043] In one embodiment, the update analysis program 101 determines that there is no overlap between the workload / event plan 150 and the plan 110. For example, the update analysis program 101 determines that there is no overlap between the workload / event plan 150 and the plan 110 if either plan indicates that there is a calendar event at that time. Thus, if the workload / event plan 150 indicates that there is an event on January 4, 2020, from 3:00 PM to 4:00 PM, the update analysis program 101 determines that there is no overlap between the two plans on January 4, 2020, from 3:00 PM to 4:00 PM. However, if both plans indicate that no calendar events are scheduled from 3:00 PM to 4:00 PM on January 4, the update analyzer 101 indicates that there is an overlap between workload / event plan 150 and plan 110.If no overlapping time is initially specified, the update analysis program 101 increases the duration of the overlapping time. For example, if the update analysis program 101 determines that there are no available overlapping times on January 4, the analysis program 101 increases the overlapping time to two days to determine whether there are any available overlapping times on January 4 and January 5.
[0044] Fig. 2 is a flowchart diagram, generally designated 200, illustrating operational steps for generating a configuration file in accordance with at least one embodiment of the present invention. Fig. Figure 2 merely provides an illustration of one embodiment and does not imply any limitations with regard to the environments in which various embodiments may be implemented. Those skilled in the art may make numerous modifications to the illustrated environment without departing from the spirit and scope of the invention as claimed.
[0045] In a step S202, the update analysis program 101 identifies server computer firmware versions. For example, the update analysis program 101 identifies the server computer's embedded software instructions to identify the server computer firmware versions. In one embodiment, the identified firmware versions are stored in a configuration file, such as the system configuration file 155. In one embodiment, the firmware versions are automatically retrieved from specific firmware configuration files and operating system configuration schemas on the server computer 145. In one embodiment, the firmware versions of the server computer 145 are manually entered into the system configuration profile 155 by a user with administrator privileges.
[0046] In a step S204, the update analysis program 101 identifies the server computer hardware versions. For example, the update analysis program 101 identifies the embedded software instructions of the server computer to determine the server computer hardware versions. In one embodiment, the identified hardware versions are stored in a configuration file, such as the system configuration file 155. In one embodiment, the hardware versions are automatically retrieved from specific hardware configuration files and operating system configuration schemas on the server computer 145. In one embodiment, the hardware versions of the server computer 145 are manually entered into the system configuration profile 155 by a user with administrator privileges.
[0047] In a decision step S206, the update analysis program 101 determines whether there are any firmware versions that do not require an update. In one embodiment, the update analysis program 101 determines that a particular firmware version should not be updated for a particular server computer 145 based on one or more of, but not limited to, a user prompt, predetermined invalid configurations, and unsupported firmware. For example, it may be determined that a firmware update is not needed if the current firmware versions do not support the new update. For example, firmware versions may need to remain unchanged in a server test environment to simulate a specific client operation and potentially reproduce a specific problem.For example, if a client previously experienced a problem with its firmware, firmware versions should remain unchanged to reproduce the previously encountered problem. If it is determined that there are firmware versions that require an update (decision step S206, branch "YES"), the update analysis program 101 proceeds to step S208. If it is determined that there are no firmware versions that require an update (decision step S206, branch "NO"), the update analysis program 101 proceeds to decision step S210.
[0048] In step S208, the update analysis program 101 stores information in the configuration file about which particular firmware versions for a server computer require an update and which particular firmware versions for a server computer do not require an update and / or should not be updated.
[0049] In decision step S210, the update analysis program 101 determines whether there are any hardware versions that do not require an update. In one embodiment, the update analysis program 101 may determine that a particular version of a hardware element should not be updated for a particular server computer 145 based on one or more of, but not limited to, a user prompt, predetermined invalid configurations, and unsupported hardware. For example, predetermined invalid hardware configurations may include the system resource settings assigned to a specific device. In one embodiment, unsupported hardware may mean that the physical hardware within the system cannot support the update.When testing future unreleased prototype versions of hardware in the server computer 145, one embodiment may prevent the specific prototype hardware from being updated with currently released firmware versions to avoid hardware failure. If it is determined that there are hardware versions that require an update (decision step S210, branch "YES"), the update analysis program 101 proceeds to step S212. If it is determined that there are no hardware versions that require an update (decision step S210, branch "NO"), the update analysis program 101 proceeds to step S214.
[0050] In step S212, the update analysis program 101 stores information in the configuration file about which specific hardware versions for a server computer require an update and which specific hardware versions for a server computer do not require an update and / or should not be updated.
[0051] In step S214, the update analysis program 101 retrieves the server computer workload / event plan 150 and stores it in the system configuration file 155.
[0052] In a step S216, the update analysis program 101 creates a configuration file.
[0053] Fig. 3 is a flowchart diagram, generally designated 300, illustrating operational steps for scheduling a firmware update in accordance with at least one embodiment of the present invention. Fig. Figure 3 merely provides an illustration of one embodiment and does not imply any limitations on the environments in which various embodiments may be implemented. Those skilled in the art may make numerous modifications to the illustrated environment without departing from the spirit and scope of the invention as claimed.
[0054] In a decision step S302, the update analysis program 101 determines whether an update is available for a server computer, such as the server computer 145. If it is determined that no update is available (decision step S302, branch "NO"), the update analysis program 101 returns to the beginning of the work steps. If it is determined that an update is available (decision step S302, branch "YES"), the update analysis program 101 proceeds to a decision step S304.
[0055] In decision step S304, the update analysis program 101 determines whether there is a server computer that requires an update. In one embodiment, the update analysis program 101 determines whether a server computer requires an update based on, but not limited to, one or more of a user request, predetermined invalid configurations, and unsupported firmware. In one embodiment, the update analysis program 101 compares the current firmware versions of each server computer with the most recent update to determine whether a server computer is running an outdated version. If it is determined that there is no server computer that requires an update (decision step S304, branch "NO"), the update analysis program 101 returns to the beginning of the operating steps.If it is determined that there is a server computer that needs an update (decision step S304, branch "YES"), the update analysis program 101 proceeds to a step S306.
[0056] In step S306, the update analysis program 101 loads a system configuration profile associated with the server computer. For example, the update analysis program 101 loads the system configuration profile 155 described above in accordance with Fig. 2 is generated for a specific server computer 145.
[0057] In step S308, the update analysis program 101 determines whether there is an overlap of plans within a specified period of time. In one embodiment, the update analysis program 101 compares the server computer administrator plan 110 with the server computer workload / event plan 150 to determine overlapping available times for performing an update within a predetermined period of time. If it is determined that there is no overlap of plans within the specified period of time (decision step S310, branch "NO"), the update analysis program 101 proceeds to step S312. If it is determined that there is an overlap of plans within the specified period of time (decision step S310, branch "NO"), the update analysis program 101 proceeds to step S314.
[0058] In step S312, the update analysis program 101 increases the predetermined time period for performing the update. In one embodiment, the update analysis program 101 may increase the length of time within the time period. For example, if the update analysis program 101 does not detect sufficiently long consecutive time periods to perform the update for both the server computer 145 and the server computer administrator 105, the acceptable time period in which the update can be performed is increased to determine whether there is an overlap between the units in another future time period.If it is determined that the future time period in which an update is to be performed is increased and no acceptable overlapping time period for performing the update is found, the update analysis program 101 may perform a forced update of the server computer 145.
[0059] In step S314, the update analysis program 101 schedules a firmware update. In one embodiment, the update analysis program 101 schedules the update for one or more of the server computers 145 based on comparing the administrator schedule 110 and the respective server computer workload / event schedules 150 for the one or more server computers 145 that require the update. In one embodiment, the update analysis program 101 schedules the update for one or more of the server computers 145 based on comparing the administrator schedule 110 and the respective server computer workload / event schedules of all server computers 145 to determine a firmware scheduling time for one or more of the server computers 145 that require the update.Although only one of the server computers 145 may require an update, other server computers 145 may be dependent on the particular server computer 145 that requires the update. Accordingly, an overlapping time for performing the update is determined based on the administrator schedule 110 of the administrator server computer 105, the particular server computer 145 that requires the update, and one or more additional server computers 145 that may be dependent on the particular server computer 145 that requires the update, in order to find a time that minimizes the impact of updating one server computer on these other dependent server computers. In one embodiment, the update analysis program 101 updates one or more of the server computers 145 at the same time. It should be understood that the steps of FIG. Fig. 3 can be repeated to determine whether additional server computers 145 require the available update.
[0060] Fig. 4 is a functional block diagram of a data processing system, generally designated 400, for scheduling an optimal time for a software update in accordance with at least one embodiment of the present invention. Fig. Figure 4 provides an illustration of only a single implementation and does not imply any limitations on the environments in which various embodiments may be implemented. Those skilled in the art may make numerous modifications to the illustrated environment without departing from the spirit and scope of the invention as claimed.
[0061] A user device 401 may represent a user's computing device, e.g., a laptop computer, a tablet computer, a netbook computer, a personal computer, a desktop computer, a personal digital assistant (PDA), a smartphone, wearable devices (e.g., smart glasses, smart watches, e-textiles, augmented reality (AR) headsets, etc.), or any other programmable computer systems known in the art. Device 401 may represent one or more devices. In general, device 401 represents any electronic device or combination of electronic devices capable of executing computer-readable instructions.
[0062] Data processing system 400 includes user device 401 and server 135, which are connected via a network 430. User device 401 includes a user interface 403 and an application 404. User interface 403 is a program that provides an interface between a user of an end-user device, such as user device 401, and a plurality of applications residing on the device (e.g., application 404). A user interface, such as user interface 403, refers to information (e.g., graphics, text, and sound) that a program presents to a user, as well as the control sequences the user uses to control the program. There are a variety of types of user interfaces. In one embodiment, user interface 403 is a graphical user interface (GUI).A graphical user interface is a type of user interface that allows users to interact with electronic devices such as a computer keyboard and mouse using graphical icons and visual indicators such as secondary notation, as opposed to text-based interfaces, typed command labels, or text navigation. In computing, GUls were introduced in response to the perceived steep learning curve of command-line interfaces, which require commands to be typed on the keyboard. Actions in GUls are often performed by directly manipulating the graphical elements. In another embodiment, user interface 403 is a script or an application programming interface (API).
[0063] Application 404 may represent one or more applications (e.g., an application suite) executing on user device 401. In various example embodiments, application 404 may be an application residing on a user device. In other embodiments, application 404 may be another mobile device application (e.g., a web browser, an enterprise messaging application, a social media application, an application for updating a device's software, firmware, and / or hardware versions, etc.). For example, application 404 is a client-side application associated with server 435 (e.g., a client-side application associated with update analyzer 101).
[0064] In an additional embodiment, application 404 may be executed to perform processing steps of update analysis program 102 (i.e., application 404 may represent update analysis program 102 executing on user device 401) in accordance with various embodiments of the present invention. For example, using application 404, a user of user device 401 may receive update reminders, view software, firmware, and / or hardware updates scheduled for a user device, select specific updates, and allow, decline, and cancel scheduled updates.
[0065] The user devices 401 further include an update notification system 405, a schedule 410, a device status 415, location services 420, and a device role 425. In one embodiment, the update notification system 405 is a component or subprogram of the update analysis program 102 used to alert the user device 401 that an update is available. In some embodiments, the notification by the update notification system 405 may be a pop-up window or a drop-down list. In one embodiment, the schedule 410 further includes historical screen usage of the user devices 401. For example, if a user device is typically in use every Wednesday from 2:00 PM to 5:00 PM, the update analysis program 102 stores the information in the schedule 410.In one embodiment, the schedule 410 includes the historical charge level of the user device 401. It will be apparent to one of ordinary skill in the art that the schedule 410 may include the user's schedule (calendar) for one or more of the user devices 401.
[0066] In one embodiment, device status 415 includes various performance conditions of a user device, such as the device's charge level and Wi-Fi status. In one embodiment, charge level indicates the percentage of battery charge of a device. In one embodiment, charge level indicates whether a device is currently charging. In one embodiment, battery level indicates whether the battery charge is above a predetermined threshold necessary to perform a particular update. In one embodiment, device status 415 includes historical usage of the device and historical charging times of the device. In one embodiment, Wi-Fi status may be categorized based on the strength of the user device's 401 Wi-Fi connection to a Wi-Fi network. In one embodiment, location services 420 include various location information for a user device's current and future locations.In one embodiment, the device role 425 contains various information about a particular user device, such as whether the device is an administrator device or a child device.
[0067] The server 435 includes an update analysis program 102, which further includes a device firmware update analyzer 300, a firmware scheduler 440, and a device profile learner 450. In one embodiment, the program 102 is a subprogram of the program 101. In one embodiment, the program 102 is different or separate from the program 101. In one embodiment, the device firmware update analyzer 300 is a module or subprogram of the update analysis program 102 that is used to analyze firmware updates. In one embodiment, the device firmware update analyzer 300 combines the administrator schedule with the availability of the server with the (discussed below with respect to Fig. 5) availability information of one or more of the user devices 401 to determine whether a particular user device 401 requires an update, and if an update is required, whether the update is permitted.
[0068] In one embodiment, firmware scheduler 440 is a module or subprogram of update analysis program 102 used to schedule updates on a user device. In one embodiment, firmware scheduler 440 schedules and stores firmware update reminders in schedule 410. In one embodiment, firmware scheduler 440 schedules and stores firmware update reminders within schedule 410 of user device 401.
[0069] In one embodiment, the device profile learner 450 is a module or subprogram of the update analysis program 102 that determines the firmware or hardware versions of the user device 401 for performing updates. In one embodiment, the device profile learner 450 determines the available times of the user device 401. Further embodiments of the device profile learner are described below with respect to Fig. 6 described in more detail.
[0070] In one embodiment, the user device 401 may require a software update, firmware update, and / or hardware update. In one embodiment, the update analysis program 102 analyzes the schedule 410, the device status 415, the location services 420, and the device role 425 to determine an optimal time to update software on the user device 401. In one embodiment, the update analysis program 102 determines an optimal time to update the software based on a plurality of factors, e.g.,, but is not limited to, one or more of: a device user's schedule, a device usage history, a device screen time history, a current device location, a future device location, a device charging history, a current device charge level, a device Wi-Fi connection history, and a current device Wi-Fi connection. In one embodiment, the update analyzer 102 determines a time to perform the software update when the device is likely not in use, has a sufficient charge level, and has a sufficient Wi-Fi connection. In one embodiment, the update analyzer 102 schedules the date and time of such an update in the schedule 410 once such an optimal time is determined.
[0071] In one embodiment, a user may need assistance updating the software, firmware, and / or hardware on their device. Accordingly, the update analyzer 102 may determine whether the device requiring the update is an administrator device or a child device. In one embodiment, the update analyzer 102 schedules a software update for a child device when both the administrator device and the child device are available. In one embodiment, the update analyzer 102 links an administrator device to one or more child devices. In one embodiment, the update analyzer 102 notifies an administrator device of available update times for one or more child devices. In one embodiment, the update analyzer 102 updates a family of mobile devices.
[0072] In one embodiment, the update analysis program 102 determines multiple optimal times for a user device update. The update analysis program 102 may assign a score to each available time. In one embodiment, the update analysis program 102 automatically performs an update of one or more user devices at the scheduled optimal time based on prior learning from previous update attempts and / or previous times of a performed update.
[0073] In one embodiment, the update analysis program 102 determines that there is no overlapping available time between the child schedule and the administrator schedule. In one embodiment, the child schedule is the schedule of the user device requiring the update, and the administrator schedule is the schedule of the user device providing update support. For example, the update analysis program 102 may determine that there is no overlap between the child schedule and the administrator schedule if either schedule indicates that there is a calendar event at that time. If no overlapping time is initially specified, the update analysis program 102 increases the duration of the overlap time. For example, if the update analysis program 102 determines that there are no available overlapping times on January 4, the analysis program 102 increases the overlap time to two days to determine if there is a calendar event on January 4.There are overlapping available times on January 1st and January 5th.
[0074] Fig. 5 is a flowchart diagram illustrating operations for generating calendar options for a child unit generally designated 500 in accordance with at least one embodiment of the present invention. Fig. Figure 5 merely provides an illustration of one embodiment and does not imply any limitations on the environments in which various embodiments may be implemented. Those skilled in the art may make numerous modifications to the illustrated environment without departing from the spirit and scope of the invention as claimed.
[0075] In a decision step S502, the update analysis program 102 determines whether an update is available. If it is determined that no update is available (decision step S502, branch "NO"), the update analysis program 101 returns to step S502. If it is determined that an update is available (decision step S502, branch "YES"), the update analysis program 102 proceeds to a decision step S504.
[0076] In decision step S504, the update analysis program 102 determines whether a user device requires an available update (e.g., a software / firmware and / or hardware update). In one embodiment, the update analysis program 102 determines that a user device does not require an update if the device's hardware or firmware cannot support the available update. If it is determined that no update is available (decision step S504, branch "NO"), the update analysis program 102 returns to step S504. If it is determined that an update is available (decision step S504, branch "YES"), the update analysis program 102 proceeds to step S506.
[0077] In step S506, the update analysis program 102 executes a device profile learner. Embodiments of the device profile learner are described below with reference to Fig. 6 described in more detail.
[0078] In a decision step S508, the update analysis program 102 determines whether an administrator entity exists to assist in updating a childhood support service. If it is determined that there is no administrator entity (decision step S508, branch "NO"), the update analysis program 102 proceeds to a step S510. If it is determined that there is an administrator entity (decision step S508, branch "YES"), the update analysis program 102 proceeds to a step S514.
[0079] In decision step S510, the update analysis program 102 determines whether there is a plan overlap over a predetermined period of time. If it is determined that there is no plan overlap over the predetermined period of time (decision step S510, branch "NO"), the update analysis program 102 proceeds to step S512. If it is determined that there is a plan overlap over the specified period of time (decision step S510, branch "NO"), the update analysis program 102 proceeds to step S514.
[0080] In step S512, the update analyzer 102 increases the overlap time. In one embodiment, the update analyzer 102 may increase the length of time in the period. For example, if the update analyzer 102 detects insufficiently long consecutive time periods to perform the update for both the server administrator unit and the child unit, the acceptable time period in which the update can be performed is increased to determine if there is an overlap between the administrator unit and the child unit at another future time period. If it is determined that the future time period in which an update should be performed is increased and no acceptable overlapping time period is found to perform the update, the update analyzer 102 may perform a forced update of the child unit.
[0081] In step S514, the update analysis program 102 generates calendar options for the administrator unit. In one embodiment, the update analysis program 102 stores the available update time in the administrator unit's calendar.
[0082] In step S516, the update analysis program 102 generates calendar options for the child unit. In one embodiment, the update analysis program 102 stores the available update time in the child unit's calendar.
[0083] Fig. 6 is a flowchart diagram illustrating operational steps for scheduling a user device update, generally designated 600, in accordance with at least one embodiment of the present invention. Fig. Figure 6 merely provides an illustration of one embodiment and does not imply any limitations on the environments in which various embodiments may be implemented. Those skilled in the art may make numerous modifications to the illustrated environment without departing from the spirit and scope of the invention as claimed.
[0084] In step S602, the update analysis program 102 determines the availability of the device user. In one embodiment, the update analysis program 102 determines the availability of the device user based on the schedule 410.
[0085] In a decision step S604, the update analysis program 102 determines whether the user is available. For example, the update analysis program 102 may determine whether the user is available if the device update requires user input, e.g., entering a password, accepting or rejecting the update, selecting various user options during the update, etc. If it is determined that the user is unavailable (decision step S604, branch "NO"), the update analysis program 102 proceeds to a step S606. If it is determined that the user is available (decision step S604, branch "YES"), the update analysis program 102 proceeds to a step S610.
[0086] In step S606, the update analysis program 102 determines the type of the user event. In one 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 work meeting, a doctor's appointment, or a lunch date. In one embodiment, the update analysis program 102 determines the type of the user event based on the location mentioned in the calendar event. In one embodiment, the update analysis program 102 prompts the user to specify the event type.
[0087] In a decision step S608, the update analysis program 102 determines whether the user event requires use of the device. For example, the update analysis program 102 determines that the user event is a doctor's appointment and does not require the device. In another example, the update analysis program 102 determines that the user event is a work meeting, which requires the device. In one embodiment, the update analysis program 102 determines whether the user event requires use of the device based on the location mentioned in the calendar event using the location services 420. In one embodiment, the update analysis program 102 determines whether the user event requires use of the device location to track the device.For example, if the update analysis program 102 determines that the unit is located in a cafe, the update analysis program 102 may determine that the event does not require use of the unit. In one embodiment, the update analysis program 102 prompts the user to indicate whether they require their unit for an event. In one embodiment, the update analysis program 102 evaluates historical unit usage for similar event types to determine whether the user event requires use of the unit. If it is determined that the event does not require the unit (decision step S608, branch "NO"), the update analysis program 102 proceeds to step S610. If it is determined that the event does require the unit (decision step S608, branch "YES"), the update analysis program 102 proceeds to step S614.
[0088] In step S610, the update analysis program 102 analyzes the device user's screen time. In one embodiment, the update analysis program 102 determines whether a user historically uses their device at a particular time. For example, the update analysis program 102 determines whether a user historically uses their device on Tuesdays at 6:00 p.m.
[0089] In a decision step S612, the update analysis program 102 determines whether the user device is currently in use. In one embodiment, a device is in use when the user is currently using the device. In one embodiment, a device is in use when an application is executing on the device. In one embodiment, a device is in use when data is being transferred to and / or from the device. If it is determined that the device is in use (decision step S612, branch "YES"), the update analysis program 102 proceeds to step S614. If it is determined that the device is not in use (decision step S612, branch "NO"), the update analysis program 102 proceeds to a decision step S616.
[0090] In decision step S616, the update analysis program 102 determines whether an acceptable network connection exists. In one embodiment, an acceptable network connection is a network speed above a predetermined threshold for performing a particular update. In one embodiment, an acceptable network connection is a network bandwidth above a predetermined threshold for performing a particular update. If it is determined that there is no acceptable network connection (decision step S616, branch "NO"), the update analysis program 102 proceeds to step S614. If it is determined that the device has an acceptable network connection (decision step S612, branch "YES"), the update analysis program 102 proceeds to a decision step S618.
[0091] In decision step S618, the update analysis program 102 determines whether a charge level of the user device is acceptable. In one embodiment, an acceptable charge level is determined based at least in part on a percentage of remaining battery life being above a predetermined threshold for performing a particular update. In one embodiment, an acceptable charge level is further determined based on the amount of power consumed during a particular update. In one embodiment, an acceptable charge level is further determined based on the battery type, battery age, and historical battery usage data of a particular user device. If it is determined that there is no acceptable charge level (decision step S618, branch "NO"), the update analysis program 102 proceeds to step S614.If it is determined that the unit has an acceptable charge level (decision step S618, branch “YES”), the update analysis program 102 proceeds to a step S620.
[0092] In step 614, the update analysis program 102 marks the predetermined time period for updating the user unit in the firmware scheduler 440 as unavailable.
[0093] In step 620, the update analysis program 102 marks the predetermined time period for updating the user unit in the firmware scheduler 440 as available.
[0094] Fig. 7 is a block diagram illustrating components of a computing device, generally designated 700, adapted to execute an update analysis program 101 and an update analysis program 102 in accordance with at least one embodiment of the invention. The data processing unit 700 includes one or more processors 704 (e.g., one or more computer processors), a data transmission structure 702, a memory 706 such as a RAM 716 and a cache 718, a persistent memory 708 which further includes the update analysis program 101 such as the firmware update analyzer 600, the firmware update scheduler 140, and the system profile learner 500, and the update analysis program 102 such as the unit firmware update analyzer 300, the firmware scheduler 440, and the unit profile learner 450, a data transmission unit 712, one or moreseveral I / O interfaces 714, a display 722 and one or more external units 720. It should be clear that . Fig. 7 is merely illustrative of one embodiment and does not imply any limitations on the environments in which various embodiments may be implemented. Rather, numerous modifications may be made to the illustrated environment.
[0095] As illustrated, computer system 700 operates via communications structure 702, which provides communications between the one or more computer processors 704, memory 706, persistent storage 708, network adapter 712, and one or more input / output (I / O) interfaces 714. Communications structure 702 may be implemented using any architecture suitable for passing data or control information between the one or more processors 704 (e.g., microprocessors, communications and network processors, etc.), memory 706, one or more external devices 720, and any other hardware components within a system. For example, communications structure 702 may be implemented using one or more buses.
[0096] Memory 706 and persistent storage 708 are computer-readable storage media. In the illustrated embodiment, memory 706 includes random access memory (RAM) 716 and cache 718. In general, memory 706 may include any suitable one or more volatile or non-volatile computer-readable storage media.
[0097] Program instructions for the update analysis program 101 and the update analysis program 102 may be stored in the persistent memory 708, or more generally, in any computer-readable storage medium, for execution via one or more of the memory 706 by one or more of the respective computer processors 704. The persistent memory 708 may be a magnetic hard disk drive, a semiconductor disk, 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.
[0098] Media used by persistent storage 708 may also be removable. For example, a removable hard disk drive may be used as persistent storage 708. Other examples include optical and magnetic disks, USB flash drives, and smart cards that are inserted into a drive to transfer to another computer-readable storage medium that is also part of persistent storage 708.
[0099] In these examples, the data transmission unit 712 provides data transmission with other data processing systems or devices. In these examples, the data transmission unit 712 may include one or more network interface cards. The data transmission unit 712 may provide data transmission over both physical and wireless data transmission connections. In the context of some embodiments of the present invention, the source of the various input data may be physically located remotely from the data processing unit 700 such that the input data may be received via the data transmission unit 712 and the output may be transmitted accordingly.
[0100] The one or more I / O interfaces 714 enable input and output of data to or from other devices that can be connected to the data processing device 700. For example, the one or more I / O interfaces 714 can provide a connection to the one or more external devices 720, e.g., to a keyboard, a keypad, a touch-sensitive screen, or other suitable input devices. The one or more external devices 720 can also include portable computer-readable storage media such as USB flash drives, portable optical or magnetic disks, and memory cards. Software and data for practicing embodiments of the present invention can be stored on such portable computer-readable storage media and loaded into the persistent memory 708 via the one or more I / O interfaces 714.The multiple I / O interfaces 714 may also be connected to a display 722. The display 722 provides a mechanism for displaying data to a user and may be, for example, a computer monitor.
[0101] It should be understood that, although this disclosure contains a detailed description of cloud computing, implementation of the teachings herein is not limited to a cloud computing environment. Rather, embodiments of the present invention may be implemented in conjunction with any type of computing environment now known or later developed.
[0102] Cloud computing is a service delivery model for enabling seamless, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with a service provider. This cloud model can include at least five characteristics, at least three service models, and at least four deployment models. The properties are as follows:
[0103] On-Demand Self-Service: A cloud user can unilaterally and automatically provision computing capabilities such as server time and network storage as needed, without requiring human interaction with the service provider.
[0104] Broad Network Access: Capabilities are available over a network and accessed through standard mechanisms that support use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs).
[0105] Resource pooling: The provider's computing resources are pooled to serve multiple users using a multi-tenant model, with various physical and virtual resources dynamically allocated and reassigned as needed. There is a perceived location independence, as the user generally has no control or knowledge over the exact location of the provided resources, but may be able to specify a location at a higher level of abstraction (e.g., country, state, or data center).
[0106] Rapid Elasticity: Capabilities can be provisioned quickly and elastically for rapid horizontal scaling out, in some cases automatically, and released quickly for rapid scale-in. To the user, the capabilities available for provisioning often appear unlimited, and they can be purchased in any quantity at any time.
[0107] Measured Service: Cloud systems automatically control and optimize resource usage by leveraging measurement capabilities at a certain level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource consumption can be monitored, controlled, and reported, creating transparency for both the provider and the user of the service. The service models are as follows:
[0108] Software as a Service (SaaS): The capability provided to the user consists of using the provider's applications running on a cloud infrastructure. The applications are accessible from various client devices via a thin client interface such as a web browser (e.g., web-based email). The user does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.
[0109] Platform as a Service (PaaS): The ability provided to the user is to deploy applications created or obtained by the user, using programming languages and tools supported by the provider, on the cloud infrastructure. The user does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but has control over the deployed applications and possibly over configurations for the application hosting environment.
[0110] Infrastructure as a Service (IaaS): The capability provided to the user consists of providing processing, storage, networking, and other basic computing resources, allowing the user to deploy and run any software, including operating systems and applications. The user does not manage or control the underlying cloud infrastructure, but has control over operating systems, storage, deployed applications, and possibly limited control over selected network components (e.g., host firewalls). The deployment models are as follows:
[0111] Private Cloud: The cloud infrastructure is operated solely for an organization. It can be managed by the organization or a third party and can be located on its own premises or on a third-party site.
[0112] Community Cloud: The cloud infrastructure is shared by multiple organizations and supports a specific user community with common objectives (e.g., objectives, security requirements, policies, and compliance considerations). It can be managed by the organizations or a third party and can be located on their own premises or on a shared premises.
[0113] 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.
[0114] Hybrid Cloud: Cloud infrastructure is a composition of two or more clouds (private, community, or public) that remain separate entities but are interconnected by a standardized or proprietary technology that enables data and application portability (e.g., cloud targeting for load balancing between clouds).
[0115] A cloud computing environment is service-oriented with a focus on state independence, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that contains a network of interconnected nodes.
[0116] Fig. 8 is a block diagram illustrating a cloud computing environment 50 according to at least one embodiment of the present invention. The cloud computing environment 50 includes one or more cloud computing nodes 10 with which local computing devices employed by cloud users, such as the personal digital assistant (PDA) or mobile phone 54A, the desktop computer 54B, the laptop computer 54C, and / or the automotive computer system 54N, can communicate. The nodes 10 can communicate with each other. They can be physically or virtually aggregated into one or more networks such as private, community, public, or hybrid clouds (not shown), as described above, or a combination thereof. This enables the cloud computing environment 50 to provide infrastructure, platforms, and / or software as a service for which a cloud user does not need to maintain resources on a local computing device.It should be noted that the types of in . Fig. 8 are intended to be merely illustrative and that the computing nodes 10 and the cloud computing environment 50 may communicate with any type of computer-based device via any type of network and / or via any type of network-accessible connection (e.g., using a web browser).
[0117] Fig. 9 is a block diagram illustrating a set of functional abstraction model layers implemented by the cloud computing environment 50 of FIG. 1 according to at least one embodiment of the present invention. Fig. 9. It should be clear from the outset that the Fig.The components, layers, and functions shown in Figure 9 are intended to be illustrative only, and embodiments of the invention are not limited thereto. As shown, the following layers and corresponding functions are provided:
[0118] A hardware and software layer 60 includes hardware and software components. Examples of hardware components include: mainframe computers 61; Reduced Instruction Set Computer (RISC)-based servers 62; servers 63; blade servers 64; storage devices 65; and networks and network components 66. In some embodiments, software components include network application server software 67 and database software 68.
[0119] A virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual servers 71, virtual storage 72, virtual networks 73, including virtual private networks, virtual applications and operating systems 74; and virtual clients 75.
[0120] In one example, a management layer 80 may provide the functions described below. Resource provisioning 81 provides for the dynamic procurement of computing resources and other resources used to perform tasks within the cloud computing environment. Metering and pricing 82 provides cost tracking when using resources within the cloud computing environment, as well as billing or invoicing for the consumption of these resources. In one example, these resources may include application software licenses. Security provides identity verification for cloud users and tasks, as well as protection for data and other resources. A user portal 83 provides users and system administrators with access to the cloud computing environment.Service level management 84 provides the allocation and management of cloud computing resources so that the required service objectives are met. Service level agreement (SLA) planning and fulfillment 85 provides the advance ordering and procurement of cloud computing resources for which future requirements are anticipated, according to an SLA.
[0121] A workload layer 90 provides examples of the functionality for which the cloud computing environment can be used. Examples of workloads and functions that can be provided by this layer include: Mapping and Navigation 91; Software Development and Lifecycle Management 92; Providing training in virtual classrooms 93; Data analytics processing 94; transaction processing 95; and unit update processing 96.
Claims
[1] A computer-implemented method for updating a unit, comprising: Determine that an update related to the unit is available, where the update is a firmware update; Determine whether the available update associated with the unit is permissible; in response to a determination that the firmware update is not permitted based, at least in part, on a particular element of legacy hardware targeted by the firmware update: - Determine whether an alternative firmware update is available that does not target the specific element of obsolete hardware; and - in response to the availability of an alternative firmware update that does not target the specific piece of legacy hardware, performing the alternative firmware update on the unit; Determining an optimal scheduled time to perform the update on the device in response to the available update associated with the device being allowed; and Perform the update on the unit at the scheduled time, wherein determining the optimal scheduled time to perform the update on the unit is based on matching a schedule of an administrator unit with workloads of a unit to be updated. [2] The computer-implemented method of claim 1, wherein determining an optimal scheduled time to perform the update on the device is further based on analyzing at least one of a historical availability of the device to perform updates or historical update times at which updates were performed on the device. [3] The computer-implemented method of claim 1, wherein determining the optimal scheduled time to perform the update on the device is based on: (i) a user of the device's calendar, (ii) additional devices with respective workloads dependent on the device; (iii) a battery charge level of the device being above a predetermined level, (iv) historical screen time data of the device, and (v) a network. [4] The computer-implemented method of claim 1, wherein the unit is at least one of a mobile unit or a server. [5] The computer-implemented method of claim 1, wherein the update is at least one of a software update, a firmware update. [6] A computer program product for updating a device, the computer program product comprising one or more computer-readable storage media and program instructions stored on the one or more computer-readable storage media, the program instructions including instructions according to any one of claims 1 to 5. [7] A computer system for updating a unit, comprising: one or more processors; one or more computer-readable storage media; and Computer program instructions, the computer program instructions stored on the one or more computer-readable storage media for execution by the one or more computer processors, the computer program instructions including instructions according to any one of claims 1 to 5.
Citation Information
Patent Citations
Software update for a plurality of mobile devices
US20060106806A1
Calendar aware adaptive patching of a computer program
US20130346955A1
Technique for automatically updating software stored on a client computer in a networked client-server environment
US6167567A