WO2021221637A1

WO2021221637A1 - Stored client state

Info

Publication number: WO2021221637A1
Application number: PCT/US2020/030588
Authority: WO
Inventors: Mark A FAHRENKRUG; Cooper G URIE; Laurent Pizot; Scott Starks; Darrel D CHERRY
Original assignee: Hewlett-Packard Development Company, L.P.
Priority date: 2020-04-30
Filing date: 2020-04-30
Publication date: 2021-11-04

Abstract

Examples disclosed herein relate to creating a changelog comprising differences between a current state of a client and a prior state of the client, compressing the changelog, establishing an authenticated connection between the client and a storage service, and providing the compressed changelog to the storage service for version-controlled storage.

Description

STORED CUENT STATE

Background

[0001] Multi-function devices often combine different components such as a printer, scanner, and copier into a single device. Such devices frequently receive refills of consumables, such as print substances (e.g., ink, toner, and/or additive materials) and/or media (e.g., paper, vinyl, and/or other print substrates).

Brief Description of the Drawings

[0002] FIG. 1 is a block diagram of an example computing device for providing a stored client state.

[0003] FIG. 2 is a flowchart of an example method for providing a stored client state.

[0004] FIG. 3 is a block diagram of an example system for providing a stored client state.

[0005] Throughout the drawings, identical reference numbers designate similar, but not necessarily identical, elements. The figures are not necessarily to scale, and the size of some parts may be exaggerated to more dearly illustrate the example shown. Moreover, the drawings provide examples and/or implementations consistent with the description; however, the description is not limited to the examples and/or implementations provided in the drawings. Detailed Description

[0006] Most multi-function-print devices (MFPs) provide several features, such as an option to scan a physical document, which may be controlled via an on-device control panel, a connected application, and/or a remote service. Other options may include printing, copying, faxing, document assembly, etc. ^"The scanning portion of an MFP may comprise an optical assembly located within a sealed endosure. The sealed endosure may have a scan window through which the optical assembly can scan a document, which may be placed on a flatbed and/or delivered by a sheet feeder mechanism.

[0007] In some circumstances, devices may need to communicate with cloud- based servers, providers, and/or systems. Achieving a test and efficient communication for synchronizing a device’s state and history of activity on the device is a challenge of modem IOT cloud computing. This communication may go in both directions, with the device able to push data, such as work product and/or telemetry to fee cloud and the cloud able to assign work, and/or get or set a state on the device.

[0008] Implementations described herein support a cloud-based version history of device states that help achieve guide communication without repeatedly incurring network round trips to the device and back. A complementary design may be implemented between a device and a cloud data model that enables both effitient communication and storage of this device state and history. The communication may allow both data history as well as a current device state to be synchronized. This may be implemented such that different device application programming interfaces (APIs) do not need to be shared and/or supported by the cloud system. Instead, distributed repository concepts may be used to store current and historic device states as an alternative way to maintaining a device shadow. In some implementations, the only API between a device (e.g., an Internet of Things type device) and the cloud system may comprise an API to push or pull changes to a state of the device. Data may be streamed in either direction according to a distributed revision control systems and may not require the communication’s protocol to manage differences in exchanging resource information and/or maintain a history of what resources and/or activity had changed since the last communication in order to pull the latest device state. [0009] The stored client state may comprise, for example, configuration, settings, progress on work tasks, and/or completed results of work tasks. For example, a cloud service may supervise a plurality of agent devices performing the same and/or similar task. In some implementations, the agent devices may comprise different instances of a software agent running on the same physical device, and/or may comprise separate physical hardware devices. The cloud service may maintain a version history of changes to each agent device’s state, which may comprise data regarding work tasks assigned to each agent device by the cloud service.

[0010] FIG. 1 is a block diagram of an example computing device 110 for providing stored client states. Computing device 110 may comprise a processor 112 and a non-transitory, machine-readable storage medium 114. Storage medium 114 may comprise a plurality of processor-executable instructions, such as instructions 120 and instructions 125. In some implementations, instructions 120, 125 may be associated with a single computing device 110 and/or may be communicatively coupled among different computing devices such as via a direct connection, bus, or network.

[0011] Processor 112 may comprise a central processing unit (CPU), a semiconductor-based microprocessor, a programmable component such as a complex programmable logic device (CPLD) and/or field-programmable gate array (FPGA), or any other hardware device suitable for retrieval and execution of instructions stored in machine-readable storage medium 114. In particular, processor 112 may fetch, decode, and execute instructions such as receive connection request instructions 120, client authentication determination instructions 125, establish connection instructions 130, receive updated client state instructions 135, and update stored client state instructions

140.

[0012] Executable instructions 120, 125, 130, 135, 140 may comprise logic stored in any portion and/or component of machine-readable storage medium 114 and executable by processor 112. The machine-readable storage medium 114 may comprise both volatile and/or nonvolatile memory and data storage components. Volatile components are those that do not retain data values upon loss of power. Nonvolatile components are those that retain data upon a loss of power. [0013] The machine-readable storage medium 114 may comprise, for example, random access memory (RAM), read-only memory (ROM), hard disk drives, solid-state drives, USB flash drives, memory cards accessed via a memory card reader, floppy disks accessed via an associated floppy disk drive, optical discs accessed via an optical disc drive, magnetic tapes accessed via an appropriate tape drive, and/or other memory components, and/or a combination of any two and/or more of these memory components. In addition, the RAM may comprise, for example, static random access memory (SRAM), dynamic random access memory (DRAM), and/or magnetic random access memory (MRAM) and other such devices. The ROM may comprise, for example, a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), and/or other like memory device,

[0014] Receive connection request instructions 120 may receive a connection request from a client. For example, a client 150, such as a software and/or virtual machine instance, a client program, and/or a device such as a mobile device and/or an Internet-of-Things type device. The client 150 may request a connection, for example, on a scheduled, periodic and/or an on-demand basis, upon detecting a change in a state of client 150, and/or in response to an instruction from another client, server, system, and/or service. For example, the connection request may comprise a polling request for a work task to be performed by the client.

[0015] In some implementations, client 150 may comprise one of a plurality of clients associated with a service. For example, the service may comprise a graphical and/or animation rendering or cryptocurrency mining service that assigns work tasks associated with a larger operation to each of the plurality of clients comprising graphical processing unite. For another example, the service may comprise a publishing service assigning work tasks for individual pages of a magazine to a plurality of clients comprising printing devices. For yet another example, client 150 may comprise one of a plurality of virtual machines comprising ain instance of an operating system or other software instance to which incoming work - network connection sessions, for example - may be assigned. [0016] Client authentication determination instructions 125 may determine whether the client 150 is authenticated for the connection. For example, client 150 may authenticate via the OAuth protocol. OAuth specifies a protocol for resource owners to authorize third-party access to their server resources without sharing their credentials. For example, OAuth allows access tokens to be issued to third-party clients, such as client 150, by an authorization server, with the approval of the resource owner. The third party then uses the access token to access the protected resources, such as stored client states in some implementations consistent with this disclosure, hosted by the resource server (e.g., device 110). Other authentication schemes may also be used, such as cryptographic key pair authentication, username and password authentication, biometric authentication, physical and/or digital token authentication, etc.

[0017] In some implementations, the instructions to determine whether the client is authenticated for the connection may further comprise instructions to, in response to determining that the client is authenticated for the connection receive a request for the stored client state file from the client, and provide the stored client state file to the client. For example, device 110 may provide the stored client state file to client 150 in order to, for example, identify changes to the client state that should be provided to device 110 and/or to restore the stored client state to client 150 in place of a current state of client 150, such as in case of rolling back to prior version. In such cases, the request for the stored client state file may comprise a request for one of a plurality of historical stored client state files associated with the client 150. For another example, the request for the stored client state file may comprise a request for one of a plurality of historical stored client state files associated with a second client, such as where a stored client state of client 150 is copied to another similar client.

[0018] Establish connection instructions 130 may, in response to determining that the client 150 is authenticated for the connection, establish the connection to the client 150. For example device 110 may establish a network-based connection to client 150 using any of a number of communication protocols such as secure copy (SCP), TCP/IP, UDP, etc. The connection may be stateful and/or stateless.

[0019] Receive updated client state instructions 135 may receive an updated client state from the client 150. For example, the stored client state may comprises a configuration for the client 150, a current status for a work task assigned to the client 150, a memory content stats of client 150, a hardware and/or software fingerprint of client 150, and/or other conditions or status information associated with client 150. In some implementations, the updated client state may comprise at least one change from a prior client state and/or may comprise only the at least one change from the prior client state. For example, instead of providing an entire client state, client 150 may provide only elements of the client state that changed since the last time the client state was provided (e.g., a changelog). In some implementations, device 110 may provide a copy of the prior client state to client 150, client 150 may perform a differential comparison of the prior and current client state, and create a changeiog between the two that may comprise the updated client state to be provided. In some implementations, the at least one change from the prior client state may comprise a compressed plurality of changes from the prior client state to a current client state for the client 150.

[00203 Update stored client state instructions 140 may update a stored client state file associated with the client 150. For example, device 110 may maintain a version- controlled repository of stored client states for client 150 and/or a plurality of clients. Version-controlled repositories are a component of software configuration management, version control, also known as revision control or source control. These repositories may be used in the management of changes to documents, computer programs, large web sites, state files, and other collections of information. Changes may be identified by a number and/or letter code, termed the "revision number", "revision level", or simply "revision". For example, an initial set of files is "revision 1". When the first change is made, the resulting set is "revision 2", and so on. Each revision may be associated with a timestamp and the person making the change. Revisions may be compared, restored, and with some types of files, merged.

[0021] FIG. 2 is a flowchart of an example method 200 for stored client states. Although execution of method 200 is described below with reference to computing device 110 and client 150, other suitable components for execution of method 200 may be used. [0022] Method 200 may begin at stage 205 and advance to stage 210 where device 110 and/or client 150 may create a changeiog comprising differences between a current state of a client and a prior state of the client. In some implementations, the changelog may comprise differences between the current state of the client 150 and the prior state of the client 150 but may disregard a change to an element of the prior state of the client comprising a read-only element. For example, certain elements of the state file of client 150 may be designated as read-only, such as device identifiers and/or secure information. Changes to such elements may be detected but may not be updated in the stored state file in order to preserve the read-only status in the stoned version.

[0023] Method 200 may then advance to stage 220 where computing device 110 may compress the changelog. For example, device 110 and/or client 150 may execute a compression algorithm, such as RLE, Huffman, LZ77, etc. to compress the changelog.

[0024] Method 200 may then advance to stage 230 where computing device 110 may establish an authenticated connection between the client and a repository service. For example, device 110 and/or client 150may execute device authentication determination instructions 125 to determine whether the client 150 is authenticated for the connection. For example, client 150 may authenticate via the OAuth protocol.

OAuth specifies a protocol for resource owners to authorize third-party access to their server resources without sharing their credentials. For example, OAuth allows access tokehs to be issued to third-party clients, such as client 150, by an authorization server, with the approval of the resource owner. The third party then uses the access token to access the protected resources, such as stored client states in some implementations consistent with this disclosure, hosted by the resource server (e.g., device 110). Other authentication schemes may also be used, such as cryptographic key pair authentication, username and password authentication, biometric authentication, physical and/or digital token authentication, etc.

[0025] In some implementations, the instructions to determine whether the client is authenticated for the connection may further comprise instructions to, In response to determining that the client is authenticated for the connection receive a request for the stored client state file from the client, and provide the stored client state file to the client. For example, device 110 may provide the stored client state file to client 150 in order to, for example, identify changes to the client state that should be provided to device 110 and/or to restore the stored client state to client 150 in place of a current state of client 150, such as in case of rolling back to prior version. In such cases, the request for the stored client state file may comprise a request for one of a plurality of historical stoned client state files associated with the client 150. For another example, the request for the stored client state file may comprise a request for one of a plurality of historical stored client state files associated with a second client, such as where a stored client state of client 150 is copied to another similar client.

[0026] Method 200 may then advance to stage 240 where computing device 110 and/or client 150 may provide the compressed changelog to the storage service for version-controlled storage. In some implementations, providing the compressed changelog to the storage service for version-controlled storage may occur in response to detecting a change to the prior state of the client

[0027] Device 110, for example, may execute receive updated client state instructions 135 to receive an updated client state from the client 150. For example, the stored client state may comprises a configuration for the client 150, a current status for a work task assigned to the client 150, a memory content stats of client 150, a hardware and/or software fingerprint of client 150, and/or other conditions or status information associated with client 150. In some implementations, the updated client state may comprise at least one change from a prior client state and/or may comprise only the at least one change from the prior client state. For example, instead of providing an entire client state, client 150 may provide only elements of the client state that changed since the last time the client state was provided (e.g., a changelog). In same implementations, device 110 may provide a copy of the prior client state to client 150, client 150 may perform a differential comparison of the prior and current client state, and create a changelog between the two that may comprise the updated client state to be provided. In some implementations, the at least one change from the prior client state may comprise a compressed plurality of changes from the prior client state to a current client state for the client 150.

[0028] Update stored client state instructions 140 may update a stored client state file associated with the client 150. For example, device 110 may maintain a version- controlled repository of stored client states for client 150 and/or a plurality of clients. Version-controlled repositories are a component of software configuration management, version control, also known as revision control or source control. These repositories may be used in the management of changes to documents, computer programs, large web sites, state files, and other collections of information. Changes may be identified by a number and/or letter code, termed the "revision number”, "revision level”, or simply "revision". For example, an initial set of files is "revision Γ. When the first change is made, the resulting set is "revision 2", and so on. Each revision may be assodated with a timestamp and the person malting the change. Revisions may be compared, restored, and with some types of files, merged.

[0029] Method 200 may then end at stage 250.

[0030] FIG. 3 is a block diagram of an example apparatus 300 for providing stored client states. Apparatus 300 may comprise a multi-function printer device 302 comprising a storage medium 310, and a processor 312. Device 302 may comprise and/or be associated with, for example, a general and/or special purpose computer, server, mainframe, desktop, laptop, tablet, smart phone, game console, printer, multifunction device, and/or any other system capable of providing computing capability consistent with providing the implementations described herein. Device 302 may store, in storage medium 310, a connection engine 320, a profile engine 325, and a version control engine 330.

[0031] Each of engines 320, 325, 330 may comprise any combination of hardware and programming to implement the functionalities of the respective engine. In examples described herein, such combinations of hardware and programming may be implemented in a number of different ways. For example, the programming for the engines may be processor executable instructions stored on a non-transitory machine-readable storage medium and the hardware for the engines may indude a processing resource to execute those instructions. In such examples, the machine-readable storage medium may store instructions that, when executed by the processing resource, implement engines 320, 325, 330. In such examples, device 302 may comprise the machine-readable storage medium storing the instructions and the processing resource to execute the instructions, or the machine-readable storage medium may be separate but accessible to apparatus 300 and the processing resource.

[0032] Connection engine 320 may receive a connection request from a client, authenticate the client 150, and in response to authenticating the client 150, establish a connection to the client 150. For example, connection engine 320 may execute receive connection request instructions 120, client authentication determination instructions 125, and/or establish connection instructions 130.

[0033] State engine 325 may receive a compressed changelog comprising configuration changes made to a state associated with the client 150. For example, state engine 325 may execute receive updated client state instructions 135.

[0034] Version control engine 330 may update a stored client state file associated with the client 150 according to the compressed changelog and maintain a version history of the stored client state file. For example, version control engine 330 may execute update stored client state instructions 140.

[0035] In the foregoing detailed description of the disclosure, reference is made to the accompanying drawings that form a part hereof, and in which is shown by way of illustration how examples of the disclosure may be practiced. These examples are described in sufficient detail to allow those of ordinary skill in the art to practice the examples of this disclosure, and it is to be understood that other examples may be utilized and that process, electrical, and/or structural changes may be made without departing from the scope of the present disclosure.

Claims

What is Claimed is:

1. A non-transitory machine-readable medium storing instructions executable by a processor to: receive a connection request from a client; determine whether the client is authenticated for the connection; and in response to determining that the client is authenticated for the connection: establish the connection to the client, receive an updated client state from the client, and update a stored client state file associated with the client.

2. The non-transitory machine-readable medium of claim 1, wherein the connection request comprises a polling request for a work task to be performed by the client.

3. The non-transitory machine-readable medium of claim 1 , wherein the stored client state comprises a configuration for the client.

4. The non-transitory machine-readable medium of claim 1 , wherein the stored client state comprises a current status for a work task assigned to the client

5. The non-transitory machine-readable medium of claim 1, wherein the instructions to receive the updated client state comprise instructions to receive at least one change from a prior client state.

6. The non-transitory machine-readable medium of claim 5, wherein the instructions to receive the at least one change from the prior client state comprise instructions to receive only the at least one change from the prior client state.

7. The non-transitory machine-readable medium of claim 6, wherein the at least one change from the prior client state comprises a compressed plurality of changes from the prior client state to a current client state for the client.

6. The non-transitory machine-readable medium of claim 1, wherein the instructions to determine whether the client is authenticated for the connection further comprise instructions to, in response to determining that the client is authenticated for the connection: receive a request for the stored Client state file from the client; and provide the stored client state file to the client

9. The non-transitory machine-readable medium of claim 7, wherein the request for the stored client state file comprises a request for one of a plurality of historical stored client state files associated with the client.

10. The non-transitory machine-readable medium of claim 7, wherein the request for the stored client state file comprises a request for one of a plurality of historical stored client state files associated with a second client

11. A method comprising: creating a changelog comprising differences between a current state of a client and a prior state of the client; compressing the changelog; establishing an authenticated connection between the client and a storage service; and providing the compressed changelog to the storage service for version-controlled storage.

12. The method of Claim 10, wherein creating the Changelog comprising differences between the current state of the client and the prior state of tile client further comprises disregarding a change to an element of the prior state of the client comprising a read-only element.

13. The method of Claim 11, the authenticated connection between the client and the storage service comprises an OAuth protocol -based connection.

14. The method of claim 11, wherein providing the compressed changelog to the storage service for version-controlled storage occurs in response to detecting a change to the prior state of the client.

15. A system, comprising: a connection engine to: receive a connection request from a client, authenticate the client, and in response to authenticating the client, establish a connection to the client; a state engine to: receive a compressed changeiog comprising configuration changes made to a state associated with the client; and a version control engine to: update a stored client state file associated with the client according to the compressed changelog, and maintain a version history of the stored client state file.