WO2024065531A1

WO2024065531A1 - Server, end client, methods and program code

Info

Publication number: WO2024065531A1
Application number: PCT/CN2022/122923
Authority: WO
Inventors: Jian Tao; Fei Liu
Original assignee: Intel Corporation
Priority date: 2022-09-29
Filing date: 2022-09-29
Publication date: 2024-04-04

Abstract

A server is provided. The server comprises interface circuitry, machine-readable instructions and processing circuitry to execute the machine-readable instructions. The machine-readable instructions are executed to install or update the main base operation system on the server. Further, the machine-readable instructions are executed transmit, to the end client, end client data indicative of an end client operation system to be installed or updated on the end client. Further, the machine-readable instructions are executed to generate a main branch for main-taining the main base operation system and a subbranch for maintaining the end client opera-tion system.

Description

Server, End Client, Methods and Program Code

Background

Cloud desktops are an approach to end-user computing where virtual desktops and applica-tions are hosted on cloud-based resources rather than resources in an on-premises corporate data center. Also known as cloud virtual desktops, cloud hosted desktops, or Desktop-as-a-Service (DaaS) , cloud desktops can be accessed from anywhere, using any device, as long as they are connected to the internet.

Cloud desktops can be divided into two solutions, a virtualization-based and a non-virtualiza-tion-based solution. Those solutions have used disk images to manage operation system (OS) and user data. A disk image is organized in data blocks, which could provide more flexibility in distributing images, creating snapshots, and encrypting data. However, over the course of use, e.g., during a longtime run, a performance of the cloud desktop may degrade. Thus, there may be need to improve a performance of a cloud desktop.

Brief description of the Figures

Some examples of apparatuses and/or methods will be described in the following by way of example only, and with reference to the accompanying figures, in which

Fig. 1 shows a block diagram of an example of a server;

Fig. 2 shows a block diagram of an example of an end client;

Fig. 3 shows an example of a dynamical alignment between main base disk image and end client disk image;

Figs. 4a-4e show another example of a dynamical alignment between main base disk image and end client disk image;

Fig. 5 shows an example of a method for a server;

Fig. 6 shows an example of a method for an end client;

Figs. 7a-7f show examples of an implementation of a main branch and subbranches;

Fig. 8 shows an example of a process to generate the differential disk image based on a soft-ware package; and

Fig. 9 shows a computing device.

Detailed Description

Various examples will now be described more fully with reference to the accompanying draw-ings in which some examples are illustrated. In the figures, the thicknesses of lines, layers and/or regions may be exaggerated for clarity.

Accordingly, while further examples are capable of various modifications and alternative forms, some particular examples thereof are shown in the figures and will subsequently be described in detail. However, this detailed description does not limit further examples to the particular forms described. Further examples may cover all modifications, equivalents, and alternatives falling within the scope of the disclosure. Like numbers refer to like or similar elements throughout the description of the figures, which may be implemented identically or in modified form when compared to one another while providing for the same or a similar functionality.

Some embodiments may have some, all, or none of the features described for other embodi-ments. “First, ” “second, ” “third, ” and the like describe a common element and indicate dif-ferent instances of like elements being referred to. Such adjectives do not imply element item so described must be in a given sequence, either temporally or spatially, in ranking, or any other manner. “Connected” may indicate elements are in direct physical or electrical contact with each other and “coupled” may indicate elements co-operate or interact with each other, but they may or may not be in direct physical or electrical contact.

As used herein, the terms “operating” , “executing” , or “running” as they pertain to software or firmware in relation to a system, device, platform, or resource are used interchangeably and can refer to software or firmware stored in one or more computer-readable storage media accessible by the system, device, platform or resource, even though the instructions contained in the software or firmware are not actively being executed by the system, device, platform, or resource.

The description may use the phrases “in an embodiment, ” “in embodiments, ” “in some em-bodiments, ” and/or “in various embodiments, ” each of which may refer to one or more of the same or different embodiments. Furthermore, the terms “comprising, ” “including, ” “having, ” and the like, as used with respect to embodiments of the present disclosure, are synonymous.

It will be understood that when an element is referred to as being “connected” or “coupled” to another element, the elements may be directly connected or coupled or via one or more intervening elements. If two elements A and B are combined using an “or” , this is to be un-derstood to disclose all possible combinations, i.e. only A, only B as well as A and B. An alternative wording for the same combinations is “at least one of the group A and B” . The same applies for combinations of more than 2 Elements.

The terminology used herein for the purpose of describing particular examples is not intended to be limiting for further examples. Whenever a singular form such as “a, ” “an” and “the” is used and using only a single element is neither explicitly or implicitly defined as being man-datory, further examples may also use plural elements to implement the same functionality. Likewise, when a functionality is subsequently described as being implemented using multi-ple elements, further examples may implement the same functionality using a single element or processing entity. It will be further understood that the terms “comprises, ” “comprising, ” “includes” and/or “including, ” when used, specify the presence of the stated features, integers, steps, operations, processes, acts, elements and/or components, but do not preclude the pres-ence or addition of one or more other features, integers, steps, operations, processes, acts, elements, components and/or any group thereof.

Unless otherwise defined, all terms (including technical and scientific terms) are used herein in their ordinary meaning of the art to which the examples belong.

Fig. 1 shows a block diagram of an example of a server 30. The server 30 comprises interface circuitry 32, machine-readable instructions and processing circuitry 34 to execute the ma- chine-readable instructions. The machine-readable instruction may be stored on a storage de-vice, e.g., the storage circuitry 36. The machine-readable instructions are executed to obtain an admin signal indicative of a main base OS.

The admin signal can be obtained by receiving, from an admin end client, the main base OS. For example, an administrator may use the admin end client, e.g., a personal computer, laptop, to maintain the main base OS. The administrator may update the main base OS on the admin end client. The main base OS can be received from the admin end client via the admin signal. In this way, the server can receive needed information to maintain the main base OS.

The main base OS may be part of or may be a main base OS disk image. Alternatively the main base OS may be part of or may be differential data. The main base OS may be transmit-ted (uploaded) from the admin end client to the server. An administrator may use the admin end client to update the main base OS. For example, the information about the updated end client, e.g., differential data, can be transmitted to the server. The server can use the differen-tial data to merge data block of an earlier (lower version) main base OS to generate an up-to-date main base OS. Note that the main base OS is managed by an administrator.

Alternatively, the main base OS can be generated on the server. An administrator can use a virtual machine running on the server to maintain the main base OS, e.g., update the main base OS. Therefore, the main base OS can be received from the virtual machine.

The main base OS, e.g., the main base OS disk image and/or the differential data can be stored in the main branch. In this way, the main branch can comprise multiple versions of the main base OS, which can be distributed to the end client.

Further, the machine-readable instructions are executed to transmit end client data. The end client data is transmitted to an end client. Further, the end client data is indicative of an end client OS to be installed or updated on the end client. By transmitting the end client data to the end client, the latter can receive the data necessary for installation or update the end client OS running on the end client. Further, the machine-readable instructions are executed to gen-erate a main branch for maintaining the main base OS and a subbranch for maintaining the end client OS. By generating two different branches the main base OS and the end client OS can be maintained separately. In this way, an update or installation of the end client OS can be performed individually for the end client. This can improve the performance of the end client, since a merge conflict can be avoided, for example. Further, a manageability of the end client can be improved.

By generating a main branch and a subbranch the main base OS and the end client OS can be maintained independently from each other. The end client may be enabled to manage the version of the end client OS. Thus, a user of the end client can change the end client OS, which is maintained on the subbranch. Further, using the main branch and the subbranch may allow to combine disk images and software packages for installation and update of the end client OS.

For example, if an end client OS which is identical to a main base OS is installed on an end client (e.g., no chances to the end client were made by a user of the end client) the server may transmit a disk image for updating the end client OS. Since the end client OS is identical to a main base OS no merge conflicts may occur. In this way, the update of the end client OS can be performed with decreased workload for the end client.

In contrast, if an end client OS was changed by a user of the end client the server may transmit a software package to the end client for updating the end client OS. Thus, a possible merge conflict can be resolved by the end client based on structured information of the software package. In this way, potential for resolving merge conflicts through the use of a software package can be combined with flexibility on distributing images, creating snapshots, or dif-ferential data through the use of a disk image.

The end client data may be part of or may be a software package to update the end client OS. The end client data may be part of or may be a software package to update the main base OS. The end client data may be part of or may be a differential disk image to update the main base OS. For example, an administrator of the admin end client may have used (generated) a soft-ware package to update the main base OS on the admin end client. The server can receive via the admin signal the information about the update, e.g., the software package used, the up-to-date main base OS disk image. A software package is an archive file containing a computer program as well as necessary metadata for its deployment. The computer program can be a source code that has to be compiled and built first. Software package metadata may include package description, package version, and dependencies (other packages that need to be in-stalled beforehand) . For example, the software package may be specifically a directory, pre-sented as a single file, which contains all the information an installer application of the end client needs to install/update a software, e.g., an OS update. That may include the software itself, as well as files that are used only during the installation/update process. For example, a software package can also be referred to as installation package or update package.

In contrast, data blocks, such as part of disk images, used in other systems for updating an end client may not provide enough information for the end client to recognize the structure of the OS, for example, the file structure of the OS. An end client using data blocks can only perform an update of an OS by merging the data blocks. The data blocks may be merged by replacing data blocks of the disk image of the end client OS. When using data blocks, a merge conflict may occur, resulting in lower performance or decreased manageability of the end client. For example, an update of the OS might not be installed on the end client. However, using disk images can provide a straightforward and efficient workflow. Since data blocks do not contain the meta-information of a software package, however, a merge conflict may occur.

Using the main branch and the subbranch the server can either select a software package or data blocks to update the end client. For example, if an end client is connected for the first time to the server the server may transmit data blocks for installing the end client OS (identical to a version of the main base OS) . Alternatively, if an end client OS installed on the end client is identical to a main base OS (maintained on the main branch) the server may transmit data blocks for updating the end client OS, since merge conflicts may be unlikely. Alternatively, if an end client OS installed on the end client was changed by user (different from every main base OS) the server may transmit a software package for updating the end client OS. In this way, the end client can recognize the structure of the update of the end client OS and can identify potential merge conflicts. Further, the end client can solve merge conflicts (as de-scribed below, e.g., in Fig. 2 or Fig. 3) because the end client has an associated subbranch for maintaining the end client OS. In this way, a manageability of the end client can be improved.

For example, an application may be installed on the end client that affects the end client disk image on the end client. Consequently this change should also affect the end client disk image that is maintained on the subbranch. The installed application may lead to a change of the data blocks of the end client disk image. For example, the version of the end client disk image may be changed by installing a user application. However, the server 30 may have no information of the effect on the end client disk image. Therefore, a simple merging of data blocks for updating the end client OS may be not possible, because a merge conflict may occur. By combining the end client data indicative of a software package with the subbranch, the end client can be enabled to maintain the end client disk image. For example, the end client can organize the data blocks of the end client disk image. In this way, the main base OS and the end client OS may be different, avoiding or making it less likely that a merge conflict will occur. Further, the end client can use the end client data to update its end client disk image, for example, by generating differential data. The end client can transmit information about the changed end client OS to the server, e.g., via a version data signal.

Alternatively the end client data may be part of an end client disk image to install the end client OS on the end client. The end client disk image may be identical to the up-to-date (latest) main base disk image maintained on the main branch. In this way, the end client can receive, from the server 30, the up-to-date version of the main base OS. In this case, the main base OS and the end client OS may be identical. The main base disk image may be a disk image of the main base OS, e.g., generated by the administrator or by the server using differential data.

For example, when an end client connects for the first time to the server 30, the server 30 may transmit the up-to-date main base disk image to the end client, since a merge conflict is less likely in this case. In this way, the end client can install the end client OS straightforward, resulting in an efficient installation.

Further, the end client disk image in combination with the subbranch can provide a compre-hensive personalization capability. It can also ensure an improved user experience, making the solution useful for retail, business, healthcare and education.

The main branch and the subbranch may be stored in the storage circuitry 36 of the server 30. An exemplary implementation of the main branch and the subbranch is shown in Fig. 7.

By generating the main branch and the subbranch a management of a specific end client disk image can be provided. The subbranch may be dynamically aligned with the main branch. Further, an end client and/or an end client user can be associated or bind with the subbranch. This is also referred to as 1o1 binding. The 1o1 binding may be a binding relationship between an end client or end client user with the associated subbranch storing the end client OS disk image. In principle, for a plurality of end clients at least one subbranch is generated. For example, for different end clients different subbranches can be generated. In this way, the server 30 can maintain different end client disk images allowing to install different end client OS on different end clients. For each end client comprising a different end client OS an 1o1 binding can be performed. For example, if two end clients use the same end client OS only one subbranch can be generated and thus one 1o1 binding can be performed. Alternatively, if two end clients use different end client OS, two subbranches can be generated and thus two 1o1 binding can be performed.

The 1o1 binding between the main base disk image and the end client disk image can be utilized to assign one specific main base disk image version to an end client. For example, the main branch and the at least one subbranch can be used to maintain a main base disk image version for multiple end client who have received the end client data. The at least one sub-branch may be used to install and update the end client OS assigned to this subbranch. In this way, the server 30 can provide a version management system for main base OS disk images. Thus, the server 30 can determine the version of the end client OS installed on an end client and can address the end client data directly to an intended end client. For example, a first end client may need an update while a second end client may not. Thus, the end client data may be transmitted only to the first end client.

By using the main branch and the subbranch multiple main base disk images can be managed instead of distributing only one main base disk image to each end client. The 1o1 binding can allow a main base disk image to be provided to multiple end clients. The server 30 may main-tain the main branch to track the upgrade records of the main base disk images, e.g., performed by an administrator. The 1o1 binding may allow to transmit to different end clients different version of the main base OS, e.g., based on the upgrade records on the main branch. In this way, an end client may receive an appropriate update that avoids or makes less likely that a merge conflict will occur.

The main branch may be used to maintain the main base OS disk images (of multiple versions) and differential data (used for updating the main base OS) . A subbranch may be used to main-tain the end client OS disk images (of multiple version) and differential data (used for updat-ing the end client OS) . The end client OS disk image and/or the differential data may be received from the end client. For example, the server may have transmitted a first main base OS to the end client. The first main base OS is maintained on the subbranch of the end client. A user of the end client may update the end client OS. The end client may transmit a version data signal indicative of the end client OS version, e.g., differential data, to the server. The server may maintain this differential data on the subbranch. Further, the server can use the differential data to generate an up-to-date end client OS disk image by merge data blocks based on the main base OS. In this way, a data traffic between end client and server can be reduced. Alternatively, the server may receive, from the end client, the up-to-date end client OS disk image.

For example, when an end client is registered on the server 30 for the first time, the server 30 generates a subbranch and maintains the subbranch for the newly registered end client. The server may maintain the subbranch to track a specific main base disk image version (the end client disk image) associated with the newly registered end client, for example, normally the up-to-date version of the main base disk image. The server 30 transmits the end client data, which may comprise the (up-to-date) main base disk image to install the end client OS on the end client. Further, the 1o1 binding between the end client and/or an end client user and the subbranch may be generated. In this way, a need of a distribution of the same sever disk image to each end client can be eliminated. This may allow a user of the end client to perform an operation based on the end client disk image maintained on the associated subbranch. In this way, a user of the end client can have a full-fledged personalization option of the end client OS. This can avoid a merge conflict, for example, during a longtime run, as all those modifi-cations can be maintained on the subbranch accordingly. For example, for multiple end clients multiple end clients disk images (and differential data) can be stored on multiple subbranch on the storage circuitry 36 of the server 30.

Generating the main branch and the subbranch for maintaining a main base disk image and an end client disk image for none-virtualization-based cloud desktop solutions can enable a one-click distributing using the main base disk image. For example, the main base disk image (of the main base OS) can be distributed to multiple end clients at the same time. The multiple end client disk images can be maintained on at least one subbranch.

Further, a remote access can be provided. For example, the 1o1 binding can be used to gen-erate a binding relationship with an end client user, e.g., using login data of an end client user.

In this way, when the user logs on to an end client, e.g., another end client, the end client can receive its specific, e.g., individualized, end client disk image for installing the end client OS on the end client.

Further, maintaining the main base disk image on the main branch can improve a version tracking and/or a rollback. In this way, data security of the main base OS can be increased, since changes, e.g., an update, made by an administrator (e.g., on the admin end client) can be better logged. Also the version tracking and/or a rollback of the end client OS can be in-creased maintaining the end client disk image on the subbranch.

The subbranch can also provide full-fledged personalization capabilities. For example, by maintaining the end client OS on the subbranch the user can perform certain actions on the end client OS. The user may install driver, install application and/or personalize settings of the end client OS.

In an example, the end client data may be indicative of a software package to update the end client OS or a (server) disk image to install or update the end client OS. For example, the disk image may be a full main base disk image to install or a differential main base disk image to update the end client OS. As described above the main base disk image may be used to install the end client OS on the end client. For example, when an end client first connects to the server 30 it receive the end client data, which may be indicative of a main base disk image maintained on the main branch. For example, the main base disk image may be the up-to-date main base disk image, e.g., the highest/newest version of the main base disk image.

Alternatively, the end client data may be indicative of a software package to update the end client OS. For example, the software package can be used to update the end client OS running on the end client, e.g., to the up-to-date version of the main base OS. In this way, the end client OS can be kept up-to-date. By using the software package a merge conflict can be avoided as described above. Data about the updated end client OS may be maintained on the subbranch. For example, the server 30 may transmit a software package to update the end client OS from version 1.2 to version 2. Thus, the server 30 may already have the information that the version of the end client OS may be version 2, and may maintain it on the subbranch associated with the end client.

When an administrator of the main base OS wants to update the main base OS, e.g. from a first main base OS (which may be part of the first main base disk image) to a second main base OS, a software package (part of the software package data) may be used. The first main base OS may be a version 1 of the main base OS and the second main base OS may be a version 2 of the main base OS.

For example, the software package may be generated on the admin end client or used on the admin end client to generate the up-to-date main base OS, e.g., updating the main base OS version 1 to the main base OS version 2. The software package can be used to update to the second main base OS by changing data of the first main base OS. The change of data to generate the second main base OS from the first main base OS can be reflected in the differ-ential data. The generation of the differential data is based on the first main base disk image. The second main base OS can be maintained by the first main base disk image and the differ-ential data. The second main base disk image may be generated based on the differential data and the first main base disk image. For example, the main base OS version 1 may be updated based on the main base disk image an the differential data to the main base OS version 2.

The information about this update, e.g., the second main base OS disk image, the differential data or the software package can be transmitted, from the admin end client, to the server. In this way, the server 30 can perform a version management mechanism based on that infor-mation. For example. the server 30 may merge the differential data, e.g., data blocks, into the first main base disk image to generate the second disk image. In this way, a need to transmit the second main base OS disk image can be omitted. Further, the software package data or the differential data used for updating the first main base OS can be transmitted to an end client by the end client data to update the end client OS. Thus, the server 30 can maintain the end client OS update history on the subbranch.

In an example, the end client data may be transmitted by a publish–subscribe pattern or a producer/consumer mode. In software architecture a publish-subscribe pattern is where send-ers of messages, called publishers (the server 30) , do not program the messages to be sent directly to specific receivers (the end client) , called subscribers, but instead categorize pub-lished messages into classes without knowledge of which subscribers, if any, there may be. Similarly, subscribers express interest in one or more classes and only receive messages that are of interest, without knowledge of which publishers, if any, there are. In this way, a greater network scalability and a more dynamic network topology can be achieved, with a resulting decreased flexibility to modify the server 30 and the structure of the software package. How-ever, since it may not be necessary to change the software package, the disadvantage of less flexibility is not relevant.

In an example, the processing circuitry 32 may be further to obtain version data indicative of a version of an OS installed on the end client. The version data may be stored in the storage circuitry 36 of the server 30. The version data may be part of the version data signal. The version data can be obtained by assuming that the up-to-date version of the main base OS is installed on the end client. Alternatively, in an example, the version data may be obtained by receiving, from the end client, the version data, e.g., via a version data signal. In this way, the server 30 can receive information about the end client OS version, e.g., when a user of the end client has changed the end client OS. Thus, the server 30 can maintain the end client OS on the subbranch with an increased accuracy and/or reliability.

The version data, e.g., an end client meta configuration data, can comprise an end client disk image. For example, a user of the end client may have changed the end client OS. Thus, by receiving the end client disk image the server 30 can be enabled to transmit the end client disk image to another end client used by the same user. A user binding can be generated to bind the user to the end client disk image. In this way, the user can access its end client disk image from multiple end clients, which may increase an experience of the user. Alternatively, the version data can be an information about an installation of an end client OS update by use of a software package. For example, the version data may comprise a receipt information for the end client data indicating an installation of the up-to-date main base OS on the end client to get the up-to-date end client OS. In this way, data traffic between the server 30 and the end client can be reduced.

Alternatively, the version data can comprise differential data of the end client OS (described in greater detail below, e.g., in Fig. 2) . In this way, a data traffic can be reduced. The server 30 can generate an up-to-date end client disk image on the subbranch based on the actually end client disk image and the differential data (comparable to the main base disk image gen-eration on the main branch) .

By obtaining the version data the server 30 can maintain the end client disk image on the subbranch. The server 30 and the end client may maintain the server/end client OS version based on the disk image on the main branch or the subbranch, respectively. In principle, the main base OS and the end client OS can be dynamically aligned with the publish-subscribe pattern. The server 30 can have a full picture of updating information of the end client OS version, e.g., on the subbranch. For example, on the subbranch the end client OS disk images and differential data may be maintained. Information about the installation/update and version of the end-client operating system may be also stored on the end-client, for example. Both the server 30 and the client can have an end client data list, e.g., a software package list, which can be checked for updating the OS. In this way, the server 30 and/or the end client can choose from the end client data list a needed or desired OS update.

In an example, the end client data may be indicative of an optional update. For example, the end client data may comprise a software package that does not need to be installed on each or any end client. Further, the processing circuitry 32 may be further to determine, based on the version data, whether the end client data is transmitted to the end client. For example, if the optional update is not needed for an end client the end client data may be not transmitted to the end client. Alternatively, the end client data may comprise optional update data indicative of the optional update, e.g., which version needs to be updated by the end client data. The optional update data can be used via the publish–subscribe pattern such that the end client can recognize whether an update is needed or not. In this way, the end client can be enabled to receive the optional update if needed. Alternatively, in an example, the end client data may be indicative of a mandatory update to be installed on the end client.

In an example, the processing circuitry 32 may be further to receive user data indicative of a user using the end client and transmit end client data based on the user data to the end client. In this way, an end client OS can be installed on multiple end clients assigned to the user, which may increase an experience of the user. The user data may allow identifying a user of the end client. For example, the user data may comprise an identifier of the user, e.g., login data of the user or an account identification of the user. Thus, a user can be identified based on the user data, such that the server 30 can transmit an end client OS to an end client used by the user, e.g., for the first time.

The server 30 comprises circuitry that is configured to provide the functionality of the server 30.For example, the server 30 comprises interface circuitry 32, processing circuitry 34 and (optional) storage circuitry 36. For example, the processing circuitry 34 may be coupled with the interface circuitry 32 and with the storage circuitry 36. For example, the processing cir-cuitry 34 may be configured to provide the functionality of the server 30, in conjunction with the interface circuitry 32 (for exchanging information, e.g., with the end client) and the storage circuitry 36 (for storing information, such as machine-readable instructions) . Likewise, the server 30 may comprise means that is/are configured to provide the functionality of the server 30.The components of server 30 are defined as component means, which may correspond to, or implemented by, the respective structural components of the server 30. For example, the server 30 of Figs. 1 comprises means for processing 34, which may correspond to or be im-plemented by the processing circuitry 34, means for communicating 32, which may corre-spond to or be implemented by the interface circuitry 32, and (optional) means for storing information 36, which may correspond to or be implemented by the storage circuitry 36. In general, the functionality of the processing circuitry 34 or means for processing 34 may be implemented by the processing circuitry 34 or means for processing 34 executing machine-readable instructions. Accordingly, any feature ascribed to the processing circuitry 34 or means for processing 34 may be defined by one or more instructions of a plurality of machine-readable instructions. The server 30 may comprise the machine-readable instructions, e.g., within the storage circuitry 36 or means for storing information 36.

As shown in Fig. 1 the respective interface circuitry 32 is coupled to the respective processing circuitry 34 at the server 30. In examples the processing circuitry 34 may be implemented using one or more processing units, one or more processing devices, any means for processing, such as a processor, a computer or a programmable hardware component being operable with accordingly adapted software. Similar, the described functions of the processing circuitry 34 may as well be implemented in software, which is then executed on one or more programma-ble hardware components. Such hardware components may comprise a general-purpose pro-cessor, a Digital Signal Processor (DSP) , a micro-controller, etc. The processing circuitry 34 is capable of controlling the interface circuitry 32, so that any data transfer that occurs over the interface circuitry 32 and/or any interaction in which the interface circuitry 32 may be involved may be controlled by the processing circuitry 34.

In an example the server 30 may comprise a memory and at least one processing circuitry 34 operably coupled to the memory and configured to perform the below mentioned method.

In examples the interface circuitry 32 may correspond to any means for obtaining, receiving, transmitting or providing analog or digital signals or information, e.g. any connector, contact, pin, register, input port, output port, conductor, lane, etc. which allows providing or obtaining a signal or information. The interface circuitry 32 may be wireless or wireline and it may be configured to communicate, e.g., transmit or receive signals, information with further internal or external components.

The server 30 may be a computer, processor, control unit, (field) programmable logic array ( (F) PLA) , (field) programmable gate array ( (F) PGA) , graphics processor unit (GPU) , appli-cation-specific integrated circuit (ASICs) , integrated circuits (IC) or system-on-a-chip (SoCs) system.

More details and aspects are mentioned in connection with the examples described below. The example shown in Fig. 1 may comprise one or more optional additional features corre-sponding to one or more aspects mentioned in connection with the proposed concept or one or more examples described below (e.g., Fig. 2 –9) .

Fig. 2 shows a block diagram of an example of an end client 50. The end client 50 comprises interface circuitry 52, machine-readable instructions and processing circuitry 54 to execute the machine-readable instructions. The machine-readable instruction is executed to receive, from a server, end client data indicative of an end client OS to be installed or updated on the end client 50. Further, it is to install or update the end client OS on the end client 50 based on the end client data. The end client 50 may be a counterpart of the server as described with reference to Fig. 1. For example, the end client OS may be maintained on a subbranch by the server as described above. By receiving the end client data an end client OS version can be kept up-to-date. The end client OS version can be maintained on a subbranch of the server, e.g., by an end client disk image. Further, the end client 50 can personalize the end client OS on the end client 50, since the end client OS version can be maintained on the subbranch of the server. Further, the machine-readable instruction is to transmit, to the server, version data indicative of an end client OS installed on the end client. By transmitting the version data the subbranch for maintaining the end client OS can be kept up-to-date. The version data is de-scribed in further detail above. For example, the version data may comprise an end client disk image or differential data.

When the end client 50 connects to the server for the first time, the end client 50 can receive the up-to-date main base disk image from the server. Thus, the end client 50 can install the end client OS based on data blocks. In an example, the processing circuitry 54 may be further to transmit, to the server, subscription data indicative of interest in receiving an update of the end client OS. In this way, the end client 50 can request a further update from the server. When the end client 50 is notified about an updated (up-to-date) main base OS version, the end client 50 may fetch this (up-to-date) main base OS version by receiving the end client data. The end client data may comprise a software package to update the end client OS to the (up-to-date) main base OS. In this way, the end client OS can be updated to an up-to-date end client OS.

In an example, the processing circuitry 54 may be further to detect if an installation or update of the OS was successful. Further, the processing circuitry 54 may be to transmit, to the server, receipt data indicative of a successful installation or update of the end client OS. By transmit-ting the receipt data the server can be informed about the successful installation, which could be indicative for the end client OS. For example, the version data as described above may comprise the receipt data. In this way, the server can be informed about the end client OS version in a simplified way.

In an example, the processing circuitry 54 may be further to generate a first end client disk image of the end client OS. By generating the first end client disk image a disk image indic-ative of the currently installed end client OS version can be generated. The first end client disk image can be maintained on the subbranch of the server. Further, the processing circuitry 54 may be to update the end client OS using software package data. The update of the end client OS may be maintained on the subbranch. For example, the software package data may be part of or may be the end client data. Also the processing circuitry 54 may be to generate, after updating, differential data based on the first end client disk image. The differential data may be indicative for the changes of the end client OS after the update compared to before the update. For example, the differential data may be a data block indicative for the changes of the first end client OS with respect to an updated second end client OS. Further, the pro-cessing circuitry 54 may be to generate a second end client disk image of the updated end client OS based on the first end client disk image and the differential data. In this way, the end client 50 can generate a second (up-to-date) end client disk image, which can be trans-mitted to the server, e.g., via version data.

The end client OS can work with an end client disk images. For example, the end client OS can work with data blocks. A user of the end client 50 can manage the end client version running on the end client 50. This end client OS can be maintained separately from main base OS by use of the main branch and the subbranch. Both, the end client OS and the main base OS can be aligned dynamically as described above.

In an example, the processing circuitry 54 may be further to determine whether to install or update end client OS based on a policy of the end client 50. For example, the end client may determine whether the update is a mandatory update, if the client has already installed an update for this OS version. In this way, the end client can improve the installation or update of the end client OS.

The end client 50 can check before an installation stage if an update was installed. In an ex-ample, the processing circuitry 54 may be further to check an installation configuration, e.g., a registry key, for installing or updating the OS. For example, the processing circuitry 54 may check whether a software package is already installed or not on the end client 50. For example, if an end client OS version 2.2 is installed on the end client 50, end client data comprising a software package to update to an OS version 2.2 may not be used for updating the end client OS.

As the end client 50 (or the user of it) may have full-fledged personalization capabilities of the end client OS the user could install a desired application/software on the end client 50. Therefore, by using a software package a merge conflict can be avoided during updating. For example, a merge conflict can be determined in advance and an action to avoid the merge conflict can be performed by the end client 50. For example, the end client 50, e.g., a software package tool installed on it, can set static checking rules. The static checking rules can be used as installation pre-requirements. For example, it can be checked whether a registry key is fulfilled when a certain software is installed (or not) and/or if a certain end client OS version is installed (or not) .

Optionally or alternatively, the end client 50 can check at an installation stage if an update was installed. For example, an administrator of the server may have pushed an updated to the end client side. The pushed update can be installed in a quiet mode installation on the end client 50. The end client 50 can check in a log file of the installation whether the installation was successful.

In an example, the processing circuitry 54 may be further to generate output data indicative of a failure of the installation or update of the end client OS. The output data may be generated based on a, e.g., checking log file, checking registry key. Further, the processing circuitry 54 may be to transmit the output data to an outputting device to inform a user about the failure of the installation or update of the end client OS. For example, the output on a user device may be triggered by the end client 50. The user device can be a laptop, personal computer, tablet, for example. The output may be displayed on a display of the user device. The user device may comprise or may be the end client 50.

Optionally or alternatively, the end client 50 can check at a runtime stage if an update was installed. This may be the final possibility for the end client 50 to detect a merge conflict. When a user starts the end client OS a warning may be prompted to the user, e.g., via a display of the end client 50. The warning can be triggered by the processing circuitry 54. Thus, the user can be informed about the merge conflict and can take action to resolve the merge conflict. When the merge conflict is solved the end client 50 may generate differential data. The dif-ferential data may be generated based on the end client OS after the update compared to before the update. The differential data can be transmitted to the server, e.g., can be comprised by the version data. The server can update the end client disk image on the subbranch for version tracking.

By separating the main base OS from the end client OS, both can be maintained on different branches. This makes it possible to define certain rules for checking the installation of the end client OS. It may also enable the user to take action to resolve a conflict state, such as a merge conflict. Further, the end client OS can be dynamically aligned with the main base OS.

The end client 50 comprises circuitry that is configured to provide the functionality of the end client 50. For example, the end client 50 comprises interface circuitry 52, processing circuitry 54 and (optional) storage circuitry 56. For example, the processing circuitry 54 may be cou-pled with the interface circuitry 52 and with the storage circuitry 56. For example, the pro-cessing circuitry 54 may be configured to provide the functionality of the end client 50, in conjunction with the interface circuitry 52 (for exchanging information, e.g., with the server) and the storage circuitry 56 (for storing information, such as machine-readable instructions) . Likewise, the end client 50 may comprise means that is/are configured to provide the func-tionality of the end client 50. The components of end client 50 are defined as component means, which may correspond to, or implemented by, the respective structural components of the end client 50. For example, the end client 50 of Figs. 2 comprises means for processing 54, which may correspond to or be implemented by the processing circuitry 54, means for communicating 52, which may correspond to or be implemented by the interface circuitry 52, and (optional) means for storing information 56, which may correspond to or be implemented by the storage circuitry 56. In general, the functionality of the processing circuitry 54 or means for processing 54 may be implemented by the processing circuitry 54 or means for processing 54 executing machine-readable instructions. Accordingly, any feature ascribed to the pro-cessing circuitry 54 or means for processing 54 may be defined by one or more instructions of a plurality of machine-readable instructions. The end client 50 may comprise the machine-readable instructions, e.g., within the storage circuitry 56 or means for storing information 56.

As shown in Fig. 2 the respective interface circuitry 52 is coupled to the respective processing circuitry 54 at the end client 50. In examples the processing circuitry 54 may be implemented using one or more processing units, one or more processing devices, any means for processing, such as a processor, a computer or a programmable hardware component being operable with accordingly adapted software. Similar, the described functions of the processing circuitry 54 may as well be implemented in software, which is then executed on one or more programma-ble hardware components. Such hardware components may comprise a general-purpose pro-cessor, a Digital Signal Processor (DSP) , a micro-controller, etc. The processing circuitry 54 is capable of controlling the interface circuitry 52, so that any data transfer that occurs over the interface circuitry 52 and/or any interaction in which the interface circuitry 52 may be involved may be controlled by the processing circuitry 54.

In an example the end client 50 may comprise a memory and at least one processing circuitry 54 operably coupled to the memory and configured to perform the below mentioned method.

In examples the interface circuitry 52 may correspond to any means for obtaining, receiving, transmitting or providing analog or digital signals or information, e.g. any connector, contact, pin, register, input port, output port, conductor, lane, etc. which allows providing or obtaining a signal or information. The interface circuitry 52 may be wireless or wireline and it may be configured to communicate, e.g., transmit or receive signals, information with further internal or external components.

The end client 50 may be a computer, processor, control unit, (field) programmable logic array ( (F) PLA) , (field) programmable gate array ( (F) PGA) , graphics processor unit (GPU) , application-specific integrated circuit (ASICs) , integrated circuits (IC) or system-on-a-chip (SoCs) system.

More details and aspects are mentioned in connection with the examples described above and/or below. The example shown in Fig. 2 may comprise one or more optional additional features corresponding to one or more aspects mentioned in connection with the proposed concept or one or more examples described above (e.g., Fig. 1) and/or below (e.g., Fig. 3 –9) .

Fig. 3 shows an example of a dynamical alignment between main base disk image and end client disk image. The 1o1 binding can be used for maintaining the end client disk image. For the 1o1 binding a main branch 310 and a subbranch 320 is generated. The main base disk image is maintained on the main branch 310 and the end client disk image is maintained on the subbranch 320.

For example, the server (e.g., the server described in Fig. 1) may generate differential data (blocks) 331, 332, 333 for maintaining main base disk images. For example, the server may generate a differential data (block) 331 for updating a main base disk image OS V1 341 (ver-sion 1 of the main base OS) to a main base disk image OS V2 342 (version 2 of the main base OS) . The update of the main base disk image OS V1 341 to main base disk image OS V2 342 may be done by a software package 351. The software package 351 may be part of or may be the end client data. The software package 351 may be transmitted to the end client via a pub-lish system 305. The publish system 305 may be beneficial for a publish-subscribe pattern. The publish system 305 may be used to publish

different software packages

351, 352, 353 for updating different OS versions. The software packages 351, 352, 353 may be generated by the server.

The end client may subscribe for notifications from the publish system 305. Further, the end client may fetch the

software package

351, 352, 353 from the publish system 305. The soft-

ware package

351, 352, 353 can be used to update the end client OS. For example, the end client disk image OS V1 371 may be updated using the software package 351 to an end client disk image OS V2 372. Optionally, the end client can inform the server about a successful installation of the up-to-date OS version, e.g., via the version data. Further, the end client may share the end client disk image with the server, e.g., by transmitting the end

client disk image

371, 372, 373 or the differential data (blocks) 381, 382, 383. Comparable to the server the end client may create differential data (blocks) 381, 382, 383 for maintaining the end client disk image.

The

software package

351, 352, 353 may be published by a publish-subscribe pattern. The

software package

351, 352, 353 may be installed by publish-subscribe pattern.

An update of the main base OS and the end client OS may be as follows. An administrator may change the main base OS by installing a software. This change can be maintained on the main branch 310. The installation of the software may be performed by a software package. For example, the main base OS V2 may be updated by a software package identical to the software package 352. The server may generate differential data. The differential data can be acquired based on a preview main base disk image should or backing-file for the top/latest main base disk image. Further, the main base disk image on the main branch 310 may be updated from main base disk image OS V2 342 to main base disk image OS V3 343. The server may publish the software package 352 through the publish system 305 to the end client.

The end client may update the end client OS V2 372 using the software package 352. However, there may be a merge conflict. Thus, the end client may solve this merge conflict and may update the end client OS V2 372 to an end client disk image OS V2.1 373. The end client disk image OS V2.1 373 may be different from the main base disk image OS V3 343.

Further, the end client may generate differential data 382. The differential data can be ac-quired based on a preview end client disk image should or backing-file for the top/latest end client disk image. The subbranch 320 can be updated based on the differential data to maintain the end client OS. In this way, the sub-branch can be dynamically aligned with the main branch.

For example, a mandatory update may be generated by the server that causes the end client to install the same OS version as the server. In this way, the main base disk image OS Vn 344 can be identical to the end client disk image OS Vn 374.

More details and aspects are mentioned in connection with the examples described above and/or below. The example shown in Fig. 3 may comprise one or more optional additional features corresponding to one or more aspects mentioned in connection with the proposed concept or one or more examples described above (e.g., Fig. 1 -2) and/or below (e.g., Fig. 4 –9) .

Figs. 4a-4e show another example of a dynamical alignment between main base disk image and end client disk image. Fig. 4a shows a main branch 410 for maintaining the main base disk image. A first end client may be registered at the server. Thus, a first subbranch 420 for the first end client may be generated. The first subbranch 420 may be initialized with the main base OS V1. Thus, in the beginning the first end client OS, namely the end client OS V1, may be identical to the up-to-date main base OS. A user of the first end client may have perform some changes to the first end client OS Client based on the first end client OS V1. The changes can be maintained on the first subbranch 420 with associated version number first end client OS V1.1/V1.2/V1.3.

In Fig. 4b the OS is updated from main base OS V1 to main base OS V2. Thus, on the main branch the main base disk image OS V1 and the main base disk image OS V2 may be main-tained. Further, a second end client may be registered at the server. Since the second end client is registered for the first time, the main base disk image OS V2 may be used to install the end client OS on the second end client. A second subbranch 422 for the second end client may be generated. The second subbranch 422 may be initialized with the main base OS V2 according to the main base disk image OS V2. A user may perform certain changes to the second end client OS V2 leading to the second end client OS V2.1/V2.2/V2.3/V2.4. For each change differential data may be generated based on the end client disk image OS V2 (or alternatively the previous end client disk image OS version, e.g., for the end client disk image OS V2.3 the end client disk image OS V2.2) . The differential data can be maintained on the second sub-branch 422 to maintain the second end client OS. The first end client may not need to update, since the update to OS version 2 may be an optional update of the main base OS.

In Fig. 4c the OS is updated from main base OS V2 to main base OS V3. Thus, on the main branch the main base disk image OS V1, the main base disk image OS V2 and the main base disk image OS V3 may be maintained. Further, a third end client may be registered at the server. Since the third end client is registered for the first time the main base disk image OS V3 may be used to install the end client OS on the third end client. A third subbranch 424 for the third end client may be generated. The third subbranch 424 may be initialized with the main base OS V3 according to the main base disk image OS V3.

Further, the update of the main base OS may be a mandatory update (also referred to as force update) . Since the third end client has already an up-to-date third end client OS no further update is needed. The first end client and the second client have on older version of the OS, which does not contain the mandatory update of version 3 of the OS. Thus, the first end client and the second end client may need to perform a merge operation. Further, both may update the table force update list to indicate whether the mandatory update was installed correctly.

By generating a hybrid update solution a merge conflict can be avoided. For a mandatory update, the server may generate a tunnel, e.g., a TCP channel, to transmit the end client data, e.g., the software package, to the end client, e.g., via a publish system. Further, a quite instal-lation script may be used by the software package. The agent installed and running on the client side can perform a quiet installation or upgrading. If still a merge conflict appears by the quite installation the user can take action to resolve the merge conflict. For example, on the second subbranch 422 a merge conflict may appear. Thus, the user can resolve the merge conflict and update to a higher version. For example, if a merge conflict appears in a V2.5 update the user may update the end client to version 2.6.

In Fig. 4d the OS is updated from main base OS V3 to main base OS V4. Thus, on the main branch the main base disk image OS V1, the main base disk image OS V2, the main base disk image OS V3 and the main base disk image OS V4 may be maintained. Further, a fourth end client may be registered at the server. Since the fourth end client is registered for the first time the main base disk image OS V4 may be used to install the end client OS on the fourth end client. A fourth subbranch 426 for the fourth end client may be generated. The fourth sub-branch 426 may be initialized with the main base OS V4 according to the main base disk image OS V4.

Fig 4e shows the system comprising the main branch 410 and the

subbranches

420, 422, 424, 426. Based on the dynamical alignment of the main base disk image and end client disk image several effects can be achieved. A change of the main base OS, e.g., caused by an adminis-trator, can be maintained on the main branch independently from the end client OS. The main branch can be maintained by the administrator of the server. Each client may use the up-to-date main base disk image for installation of the end client OS when the end client is registered for the first at the server.

More details and aspects are mentioned in connection with the examples described above and/or below. The example shown in Fig. 4 may comprise one or more optional additional features corresponding to one or more aspects mentioned in connection with the proposed concept or one or more examples described above (e.g., Fig. 1 -3) and/or below (e.g., Fig. 5 –9) .

Fig. 5 shows an example of a method 500 for a server. The method 500 comprises installing or updating 510 a main base OS on the server. Further, the method 500 comprises transmitting 520, to the end client, end client data indicative of an end client OS to be installed or updated on the end client. Further, the method comprises generating 530 a main branch for maintaining the main base OS and a subbranch for maintaining the end client OS. The method 500 may be performed by a server as described in Fig. 1.

More details and aspects are mentioned in connection with the examples described above and/or below. The example shown in Fig. 5 may comprise one or more optional additional features corresponding to one or more aspects mentioned in connection with the proposed concept or one or more examples described above (e.g., Fig. 1 -4) and/or below (e.g., Fig. 6 –9) .

Fig. 6 shows an example of a method 600 for an end client. The method 600 comprises re-ceiving 610, from a server, end client data indicative of an end client OS to be installed or updated on the end client. The method 600 further comprises installing or updating 620 the end client OS on the end client based on the end client data. The method 600 may further comprise transmitting 630, to the server, version data indicative of an end client operation system installed on the end client. The method 600 may be performed by an end client as described in Fig. 2.

More details and aspects are mentioned in connection with the examples described above and/or below. The example shown in Fig. 6 may comprise one or more optional additional features corresponding to one or more aspects mentioned in connection with the proposed concept or one or more examples described above (e.g., Fig. 1 -5) and/or below (e.g., Fig. 7 –9) .

Figs. 7a-7f show examples of an implementation of a main branch and subbranches. As can be seen in Fig. 7a multiple main base OS version may be stored on the main branch. Each main base OS version may be part of or may be a different main base disk image. For example, the main base OS version 1 is based on the main base disk image of version 0 and the differ-ential data determined based on a software package.

Fig. 7b shows two different subbranches for two different end clients. The end client client1 may receive the main base OS version 1 and the end client client2 may receive the main base OS version 3. In this way, both end clients may run a different end client OS.

Fig. 7c shows the same two different subbranches as shown in Fig. 7b. Further, Fig. 7c updates to version 2 and version 3 on the end client client1.

Fig. 7d shows that the end client OS may be changed from version 3 to a version 3.1 and a version 3.2, e.g., by a user of the client2. Fig. 7e shows that a software package may be trans-mitted to the client2 to update the end client OS to a version 4. As can be seen in Fig. 7f a merge potential merge conflict can be resolved by the client2.

More details and aspects are mentioned in connection with the examples described above and/or below. The example shown in Fig. 7 may comprise one or more optional additional features corresponding to one or more aspects mentioned in connection with the proposed concept or one or more examples described above (e.g., Fig. 1 -6) and/or below (e.g., Fig. 8 –9) .

Fig. 8 shows an example of a process to generate the differential disk image (differential data blocks) based on the base OS disk image.

In 810 an OS loader may load the main base disk image, e.g., a file comprising the main base disk image, into a memory, e.g., the storage device of an admin end client or the storage device of the server as described with reference to Fig. 1. Further, the OS loader may run the OS accordingly.

In 812 the installation or update of the main base OS may be initialized. In 814 the OS instal-lation or update operations read/write may go through a filesystem layer. In 816 the read/write operations may go through a disk image block device driver. The disk image block device driver may be installed on the main base OS in advance for handle disk image operations.

In 818 differential data blocks or a differential main base disk image may be generated, e.g., by converting file operations into main base disk image read/write operations. For example, differential disk image may be merged into the main base disk image to generate a newer (up-to-date) version of the main base disk image.

In 820 the differential data blocks or the differential main base disk image may be merged into the base OS disk image. In this way, a newer (up-to-date) version main base disk image of the main base OS can be generated.

More details and aspects are mentioned in connection with the examples described above and/or below. The example shown in Fig. 8 may comprise one or more optional additional features corresponding to one or more aspects mentioned in connection with the proposed concept or one or more examples described above (e.g., Fig. 1 -7) and/or below (e.g., Fig. 9 –9) .

Fig. 9 shows a computing device 900. The computing device 900 houses a board 902. The board 902 may include a number of components, including but not limited to a processor 904 and at least one communication chip 906. A server as described above (e.g., with reference to Fig. 1) or an end client as described above (e.g., with reference to Fig. 2) may be part of the processor 904 as shown in Fig. 9.

The processor 904 is physically and electrically coupled to the board 902. In some examples the at least one communication chip 906 is also physically and electrically coupled to the board 902. In further examples, the communication chip 906 is part of the processor 904.

Depending on its applications, computing device 900 may include other components that may or may not be physically and electrically coupled to the board 902. These other components include, but are not limited to, volatile memory (e.g., DRAM) , non-volatile memory (e.g., ROM) , flash memory, a graphics processor, a digital signal processor, a crypto processor, a chipset, an antenna, a display, a touchscreen display, a touchscreen controller, a battery, an audio codec, a video codec, a power amplifier, a global positioning system (GPS) device, a compass, an accelerometer, a gyroscope, a speaker, a camera, and a mass storage device (such as hard disk drive, compact disk (CD) , digital versatile disk (DVD) , and so forth) . The com-munication chip 906 enables wireless communications for the transfer of data to and from the computing device 900. The term “wireless” and its derivatives may be used to describe cir-cuits, devices, systems, methods, techniques, communications channels, etc., that may com-municate data through the use of modulated electromagnetic radiation through a non-solid medium. The term does not imply that the associated devices do not contain any wires, alt-hough in some examples they might not. The communication chip 906 may implement any of a number of wireless standards or protocols, including but not limited to Wi-Fi (IEEE 802.11 family) , WiMAX (IEEE 802.16 family) , IEEE 802.20, long term evolution (LTE) , Ev-DO, HSPA+, HSDPA+, HSUPA+, EDGE, GSM, GPRS, CDMA, TDMA, DECT, Blue-tooth, derivatives thereof, as well as any other wireless protocols that are designated as 3G, 4G, 5G, and beyond. The computing device 900 may include a plurality of communication chips 906. For instance, a first communication chip 906 may be dedicated to shorter range wireless communications such as Wi-Fi and Bluetooth and a second communication chip 906 may be dedicated to longer range wireless communications such as GPS, EDGE, GPRS, CDMA, WiMAX, LTE, Ev-DO, and others.

The processor 904 of the computing device 900 includes an integrated circuit die packaged within the processor 904. In some examples, the integrated circuit die of the processor in-cludes one or more devices that are assembled in an ePLB or eWLB based P0P package that that includes a mold layer directly contacting a substrate, in accordance with examples. The term “processor” may refer to any device or portion of a device that processes electronic data from registers and/or memory to transform that electronic data into other electronic data that may be stored in registers and/or memory.

The communication chip 906 also includes an integrated circuit die packaged within the com-munication chip 906. In accordance with another example, the integrated circuit die of the communication chip includes one or more devices that are assembled in an ePLB or eWLB based P0P package that that includes a mold layer directly contacting a substrate, in accord-ance with examples.

More details and aspects are mentioned in connection with the examples described above. The example shown in Fig. 9 may comprise one or more optional additional features corre-sponding to one or more aspects mentioned in connection with the proposed concept or one or more examples described above (e.g., Fig. 1 –8) .

The aspects and features described in relation to a particular one of the previous examples may also be combined with one or more of the further examples to replace an identical or similar feature of that further example or to additionally introduce the features into the further example.

Examples may further be or relate to a (computer) program including a program code to exe-cute one or more of the above methods when the program is executed on a computer, proces-sor or other programmable hardware component. Thus, steps, operations or processes of dif-ferent ones of the methods described above may also be executed by programmed computers, processors or other programmable hardware components. Examples may also cover program storage devices, such as digital data storage media, which are machine-, processor-or com-puter-readable and encode and/or contain machine-executable, processor-executable or com-puter-executable programs and instructions. Program storage devices may include or be dig-ital storage devices, magnetic storage media such as magnetic disks and magnetic tapes, hard disk drives, or optically readable digital data storage media, for example. Other examples may also include computers, processors, control units, (field) programmable logic arrays ( (F) PLAs) , (field) programmable gate arrays ( (F) PGAs) , graphics processor units (GPU) , ap-plication-specific integrated circuits (ASICs) , integrated circuits (ICs) or system-on-a-chip (SoCs) systems programmed to execute the steps of the methods described above.

It is further understood that the disclosure of several steps, processes, operations or functions disclosed in the description or claims shall not be construed to imply that these operations are necessarily dependent on the order described, unless explicitly stated in the individual case or necessary for technical reasons. Therefore, the previous description does not limit the execu-tion of several steps or functions to a certain order. Furthermore, in further examples, a single step, function, process or operation may include and/or be broken up into several sub-steps, - functions, -processes or -operations.

The computer-executable instructions can be part of, for example, an operating system of the computing system, an application stored locally to the computing system, or a remote appli-cation accessible to the computing system (e.g., via a web browser) . Any of the methods de-scribed herein can be performed by computer-executable instructions performed by a single computing system or by one or more networked computing systems operating in a network environment. Computer-executable instructions and updates to the computer-executable in-structions can be downloaded to a computing system from a remote server.

Further, it is to be understood that implementation of the disclosed technologies is not limited to any specific computer language or program. For instance, the disclosed technologies can be implemented by software written in C++, C#, Java, Perl, Python, JavaScript, Adobe Flash, C#, assembly language, or any other programming language. Likewise, the disclosed tech-nologies are not limited to any particular computer system or type of hardware.

Furthermore, any of the software-based embodiments (comprising, for example, computer-executable instructions for causing a computer to perform any of the disclosed methods) can be uploaded, downloaded, or remotely accessed through a suitable communication means. Such suitable communication means include, for example, the Internet, the World Wide Web, an intranet, cable (including fiber optic cable) , magnetic communications, electromagnetic communications (including RF, microwave, ultrasonic, and infrared communications) , elec-tronic communications, or other such communication means.

As used in this application and the claims, a list of items joined by the term “and/or” can mean any combination of the listed items. For example, the phrase “A, B and/or C” can mean A; B; C; A and B; A and C; B and C; or A, B and C. As used in this application and the claims, a list of items joined by the term “at least one of” can mean any combination of the listed terms. For example, the phrase “at least one of A, B or C” can mean A; B; C; A and B; A and C; B and C; or A, B, and C. Moreover, as used in this application and the claims, a list of items joined by the term “one or more of” can mean any combination of the listed terms. For exam-ple, the phrase “one or more of A, B and C” can mean A; B; C; A and B; A and C; B and C; or A, B, and C.

The disclosed methods, apparatuses, and systems are not to be construed as limiting in any way. Instead, the present disclosure is directed toward all novel and nonobvious features and aspects of the various disclosed embodiments, alone and in various combinations and sub combinations with one another. The disclosed methods, apparatuses, and systems are not lim-ited to any specific aspect or feature or combination thereof, nor do the disclosed embodi-ments require that any one or more specific advantages be present or problems be solved.

Theories of operation, scientific principles, or other theoretical descriptions presented herein in reference to the apparatuses or methods of this disclosure have been provided for the pur-poses of better understanding and are not intended to be limiting in scope. The apparatuses and methods in the appended claims are not limited to those apparatuses and methods that function in the manner described by such theories of operation.

Although the operations of some of the disclosed methods are described in a particular, se-quential order for convenient presentation, it is to be understood that this manner of descrip-tion encompasses rearrangement, unless a particular ordering is required by specific language set forth herein. For example, operations described sequentially may in some cases be rear-ranged or performed concurrently. Moreover, for the sake of simplicity, the attached figures may not show the various ways in which the disclosed methods can be used in conjunction with other methods.

If some aspects have been described in relation to a device or system, these aspects should also be understood as a description of the corresponding method. For example, a block, device or functional aspect of the device or system may correspond to a feature, such as a method step, of the corresponding method. Accordingly, aspects described in relation to a method shall also be understood as a description of a corresponding block, a corresponding element, a property or a functional feature of a corresponding device or a corresponding system.

As used herein, the term “module” refers to logic that may be implemented in a hardware component or device, software or firmware running on a processing unit, or a combination thereof, to perform one or more operations consistent with the present disclosure. Software and firmware may be embodied as instructions and/or data stored on non-transitory computer-readable storage media. As used herein, the term “circuitry” can comprise, singly or in any combination, non-programmable (hardwired) circuitry, programmable circuitry such as pro-cessing units, state machine circuitry, and/or firmware that stores instructions executable by programmable circuitry. Modules described herein may, collectively or individually, be em-bodied as circuitry that forms a part of a computing system. Thus, any of the modules can be implemented as circuitry. A computing system referred to as being programmed to perform a method can be programmed to perform the method via software, hardware, firmware, or com-binations thereof.

In the following, some examples of the proposed concept are presented:

An example (e.g., example 1) relates to a server, the server comprising interface circuitry, machine-readable instructions and processing circuitry to execute the machine-readable in-structions to obtain an admin signal indicative of the main base operation system, transmit, to the end client, end client data indicative of an end client operation system to be installed or updated on the end client, and generate a main branch for maintaining the main base operation system and a subbranch for maintaining the end client operation system.

An example (e.g., example 1a) relates to a processing module, comprising means for pro-cessing and means for storing information, wherein the processing module is configured to obtain an admin signal indicative of the main base operation system, transmit, to the end client, end client data indicative of an end client operation system to be installed or updated on the end client, and generate a main branch for maintaining the main base operation system and a subbranch for maintaining the end client operation system.

Another example (e.g., example 2) relates to a previous example (e.g., example 1) or to any other example, wherein the end client data is indicative of a software package to update the end client operation system or a disk image to install or update the end client operation system.

Another example (e.g., example 3) relates to a previous example (e.g., one of the examples 1 or 2) or to any other example, wherein the end client data is transmitted by a publish–subscribe pattern.

Another example (e.g., example 4) relates to a previous example (e.g., one of the examples 1 to 3) or to any other example, wherein the processing circuitry is further to obtain version data indicative of a version of an end client operation system installed on the end client.

Another example (e.g., example 5) relates to a previous example (e.g., example 4) or to any other example, wherein the version data is obtained by receiving, from the end client, the version data.

Another example (e.g., example 6) relates to a previous example (e.g., one of the examples 4 or 5) or to any other example, wherein the end client data is indicative of an optional update and the processing circuitry is further to determine, based on the version data, whether the end client data is transmitted to the end client.

Another example (e.g., example 7) relates to 1, 2, 3, 4 or 5 wherein the end client data is indicative of a mandatory update to be installed on the end client.

Another example (e.g., example 8) relates to a previous example (e.g., one of the examples 1 to 7) or to any other example, wherein the processing circuitry is further to receive user data indicative of a user using the end client, and transmit end client data based on the user data to the end client.

An example (e.g., example 9) relates to an end client, the end client comprising interface circuitry, machine-readable instructions and processing circuitry to execute the machine-read-able instructions to receive, from a server, end client data indicative of an end client operation system to be installed or updated on the end client, install or update the end client operation system on the end client based on the end client data, and transmit, to the server, version data indicative of an end client operation system installed on the end client.

Another example (e.g., example 10) relates to a previous example (e.g., example 9) or to any other example, wherein the processing circuitry is further to transmit, to the server, subscrip-tion data indicative of interest in receiving an update of the end client operation system.

Another example (e.g., example 11) relates to a previous example (e.g., one of the examples 9 to 10) or to any other example, wherein the processing circuitry is further to detect if an installation or update of the operation system was successful, and transmit, to the server, re-ceipt data indicative of a successful installation or update of the end client operation system.

Another example (e.g., example 12) relates to a previous example (e.g., one of the examples 9 to 11) or to any other example, wherein the processing circuitry is further to generate a first end client disk image of the end client operation system, update the end client operation sys-tem using software package data, generate, after updating, differential data based on the first end client disk image, and generate a second end client disk image of the updated end client operation system based on the first end client disk image and the differential data.

Another example (e.g., example 13) relates to a previous example (e.g., one of the examples 9 to 12) or to any other example, wherein the processing circuitry is further to determine whether to install or update end client OS based on a policy of the end client.

Another example (e.g., example 14) relates to a previous example (e.g., one of the examples 9 to 13) or to any other example, wherein the processing circuitry is further to check an in-stallation configuration for installing or updating the operation system.

Another example (e.g., example 15) relates to a previous example (e.g., one of the examples 9 to 14) or to any other example, wherein the processing circuitry is further to generate output data indicative of a failure of the installation or update of the end client operation system, and transmit the output data to an outputting device to inform a user about the failure of the in-stallation or update of the end client operation system.

Another example (e.g., example 16) relates to a previous example (e.g., one of the examples 9 to 15) or to any other example, wherein the processing circuitry is further to resolve a merge conflict of the update of the end client operation system.

An example (e.g., example 17) relates to a method, comprising obtaining an admin signal indicative of a main base operation system, transmitting, to the end client, end client data indicative of an end client operation system to be installed or updated on the end client, and generating a main branch for maintaining the main base operation system and a subbranch for maintaining the end client operation system.

An example (e.g., example 18) relates to a method, comprising receiving, from a server, end client data indicative of an end client operation system to be installed or updated on the end client, installing or updating the end client operation system on the end client based on the end client data, and transmitting, to the server, version data indicative of an end client opera-tion system installed on the end client.

Another example (e.g., example 19) relates to a non-transitory, computer-readable medium comprising a program code that, when the program code is executed on a computer, a proces-sor, or a programmable hardware component, performs the method according to example 17.

Another example (e.g., example 19a) relates to a computer program having a program code for performing the method of the above examples (e.g., example 17) , when the computer program is executed on a computer, a processor, or a programmable hardware component.

Another example (e.g., example 20) relates to a non-transitory, computer-readable medium comprising a program code that, when the program code is executed on a computer, a proces-sor, or a programmable hardware component, performs the method according to example 18.

Another example (e.g., example 20a) relates to a computer program having a program code for performing the method of the above examples (e.g., example 18) , when the computer program is executed on a computer, a processor, or a programmable hardware component.

The following claims are hereby incorporated in the detailed description, wherein each claim may stand on its own as a separate example. It should also be noted that although in the claims a dependent claim refers to a particular combination with one or more other claims, other examples may also include a combination of the dependent claim with the subject matter of any other dependent or independent claim. Such combinations are hereby explicitly proposed, unless it is stated in the individual case that a particular combination is not intended. Further-more, features of a claim should also be included for any other independent claim, even if that claim is not directly defined as dependent on that other independent claim.

Claims

A server, the server comprising interface circuitry, machine-readable instructions and processing circuitry to execute the machine-readable instructions to:

obtain an admin signal indicative of the main base operation system ;

transmit, to the end client, end client data indicative of an end client operation system to be installed or updated on the end client; and

generate a main branch for maintaining the main base operation system and a sub-branch for maintaining the end client operation system.
The server according to claim 1, wherein

the end client data is indicative of a software package to update the end client operation system or a disk image to install or update the end client operation system.
The server according to claim1, wherein

the end client data is transmitted by a publish–subscribe pattern.
The server according to claim1, wherein

the processing circuitry is further to obtain version data indicative of a version of an end client operation system installed on the end client.
The server according to claim 4, wherein

the version data is obtained by receiving, from the end client, the version data.
The server according to claim 4, wherein

the end client data is indicative of an optional update and

the processing circuitry is further to determine, based on the version data, whether the end client data is transmitted to the end client.
The server according to claim 1, wherein

the end client data is indicative of a mandatory update to be installed on the end client.
The server according to claim1, wherein

the processing circuitry is further to:

receive user data indicative of a user using the end client; and

transmit end client data based on the user data to the end client.
An end client, the end client comprising interface circuitry, machine-readable instructions and processing circuitry to execute the machine-readable instructions to:

receive, from a server, end client data indicative of an end client operation system to be installed or updated on the end client;

install or update the end client operation system on the end client based on the end client data; and

transmit, to the server, version data indicative of an end client operation system in-stalled on the end client.
The end client according to claim 9, wherein

the processing circuitry is further to transmit, to the server, subscription data indicative of interest in receiving an update of the end client operation system.
The end client according to any of the claims 9, wherein

the processing circuitry is further to:

detect if an installation or update of the operation system was successful; and

transmit, to the server, receipt data indicative of a successful installation or update of the end client operation system.
The end client according to any of the claims 9, wherein

the processing circuitry is further to:

generate a first end client disk image of the end client operation system;

update the end client operation system using software package data;

generate, after updating, differential data based on the first end client disk image; and

generate a second end client disk image of the updated end client operation system based on the first end client disk image and the differential data.
The end client according to any of the claims 9, wherein

the processing circuitry is further to determine whether to install or update end client OS based on a policy of the end client.
The end client according to any of the claims 9, wherein

the processing circuitry is further to check an installation configuration for installing or updating the operation system.
The end client according to any of the claims 9, wherein

the processing circuitry is further to:

generate output data indicative of a failure of the installation or update of the end client operation system; and

transmit the output data to an outputting device to inform a user about the failure of the installation or update of the end client operation system.
The end client according to any of the claims 9, wherein

the processing circuitry is further to resolve a merge conflict of the update of the end client operation system.
A method, comprising:

obtaining an admin signal indicative of a main base operation system;

transmitting, to the end client, end client data indicative of an end client operation system to be installed or updated on the end client; and

generating a main branch for maintaining the main base operation system and a subbranch for maintaining the end client operation system.
A method, comprising:

receiving, from a server, end client data indicative of an end client operation system to be installed or updated on the end client;

installing or updating the end client operation system on the end client based on the end client data; and

transmitting, to the server, version data indicative of an end client operation system installed on the end client.
A non-transitory, computer-readable medium comprising a program code that, when the program code is executed on a computer, a processor, or a programmable hardware com-ponent, performs the method according to claim 17.
A non-transitory, computer-readable medium comprising a program code that, when the program code is executed on a computer, a processor, or a programmable hardware com-ponent, performs the method according to claim 18.