Generating a request for reprocessing of a replaceable supply component

Abstract

Generating the request for reprocessing of the replaceable supply component can include sending a request for information about the replaceable supply component to a non-volatile memory of the replaceable supply component. The method can include receiving supply component information from the replaceable supply component, where the supply component information includes data to be decrypted by the exchange service. The method can further include generating a request blob including the supply component information, and cryptographically signing the request blob for sending to the exchange service for reprocessing of the replaceable supply component.

Description

Background Technology

[0001] Various types of devices include replaceable supply components, such as inkjet printhead assemblies and printing material containers for, for example, two-dimensional (2D) or three-dimensional (3D) printing devices. Example printing material containers include inkjet cartridges, toner cartridges, ink supplies, and build material supplies. In some cases, these supply components include integrated circuits, which may be referred to as chips, to communicate with the electronic circuitry of the device in which these supply components are housed. While replaceable supply components can be associated with printing, they can also be used in other contexts, such as in biomedical devices for testing and dispensing fluids and / or other material dispensing devices such as water filter dispensers in refrigerators. Attached Figure Description

[0002] Figure 1 An example method for generating a request for reprocessing of replaceable supply components, according to this disclosure, is illustrated.

[0003] Figure 2 An example method for generating a request for reprocessing of replaceable supply components, according to this disclosure, is illustrated.

[0004] Figure 3 An example block diagram of a computing device including instructions according to the present disclosure is shown, the instructions being used to generate a request for reprocessing of a replaceable supply component.

[0005] Figure 4 An example block diagram of a computing device including instructions according to the present disclosure is shown, the instructions being used to generate a request for reprocessing of a replaceable supply component. Detailed Implementation

[0006] Referring in the following detailed description to the accompanying drawings, which form part of this disclosure, and which illustrate specific examples in which this disclosure may be practiced, it will be understood that other examples may be used and structural or logical changes may be made without departing from the scope of this disclosure. Therefore, the following detailed description is not intended to be restrictive, and the scope of this disclosure is defined by the appended claims. It will be understood that, unless otherwise specifically stated, the functions of the various examples described herein may be combined with each other in part or in whole.

[0007] It may be desirable to reprocess computing supplies in a way that is secure, manageable for tracking and billing, and maintains security and authentication standards. As used herein, a reprocessed computing supply means or includes computing supplies that have been previously used and have been recovered, refilled, or otherwise made available again. As a non-limiting example, a reprocessed computing supply may include a printer cartridge that has been refilled so that it can be reused instead of being discarded. Computing supplies may be referred to herein as supply components and replaceable supply components.

[0008] Previously, reprocessed computing supplies were not reprocessed in a secure and manageable manner for tracking and billing, nor in a way that maintained security and authentication standards. For example, such reprocessed computing supplies lacked consumable management capabilities, making it impossible to reset ink level or toner gas meters. Similarly, third-party chips often used auto-reset chips or other solutions that might not be compatible with the original manufacturer's authentication solutions and could expose computing supplies to security vulnerabilities.

[0009] According to this disclosure, generating a request for reprocessing of a replaceable supply component allows for secure reprocessing of a computing supply (e.g., a supply component). This disclosure describes various components and means for securely reading and writing to the chip of a supply component, as well as an entry point for accepting, processing, and responding to new data to enable reprocessing of the supply component. Furthermore, this disclosure describes various aspects of chip data partitioning, data management, and authentication for enhanced security. Using this method, manufacturers can augment the data on the original supply component chip to provide a richer functional experience.

[0010] An example method consistent with this disclosure includes sending a request for information about a replaceable supply component to the non-volatile memory of the replaceable supply component. The method may include receiving supply component information from the replaceable supply component, wherein the supply component information includes data to be decrypted by an exchange service. The method further includes generating a payload envelope including the supply component information and cryptographically signing the payload envelope before sending it to the exchange service for reprocessing of the replaceable supply component.

[0011] The example computing device disclosed herein includes a non-transitory computer-readable storage medium containing instructions that, when executed, cause the computing device to perform various actions. For example, the non-transitory computer-readable storage medium may include instructions that, when executed, cause the computing device to establish a key with a chip of a replaceable supply component using a KDF-derived key and generate a request blob containing a request for reprocessing of the replaceable supply component using the computing device. The request blob has multiple attributes, each of which has a specific data type. The instructions may cause the computing device to cryptographically sign the request blob and send it to an exchange service.

[0012] As a further example, the computing device of this disclosure includes a non-transitory computer-readable storage medium containing instructions that, when executed, cause the computing device to generate a request blob and cryptographically sign the request blob. The request blob includes a request for reprocessing of a replaceable supply component using the computing device. The request blob has multiple attributes, each having a specific data type. The non-transitory computer-readable storage medium may further include instructions that, when executed, cause the computing device to send the request blob to an exchange service and receive a response blob from the exchange service. The response blob has multiple attributes, each having a specific data type.

[0013] As described herein, an encoding device may provide supply data blocks that will be verified by an exchange service, and the exchange service may provide signed data blocks that will be written back to the supply component. As used herein, an encoding device refers to or includes a computing device capable of receiving supply components and writing data to non-volatile memory disposed within the supply component. Non-limiting examples of an encoding device include a printer capable of writing data to a print cartridge disposed therein and capable of communicating with an exchange service. As used herein, an exchange service refers to or includes local or cloud-based services capable of receiving requests for reprocessing of supply components and responding with data to be written to the non-volatile memory of the supply component. Each binary large object (“blob”) of data provided by the encoding device to the exchange service and by the exchange service to the encoding device may contain various contextual information, supply identifiers, and other data.

[0014] Now turn to the attached diagram. Figure 1 An example method 100 for generating a request for reprocessing of replaceable supply components according to this disclosure is illustrated. Although in Figure 1Not illustrated, but method 100 may begin by receiving a replaceable supply component in an encoding device, as described herein. The encoding device can be any form of computing device capable of receiving the replaceable supply component and writing data to it. Non-limiting examples of encoding devices include printers, household appliances (such as refrigerators, dishwashers, washing machines, etc.), and industrial manufacturing equipment. The replaceable supply component can be a device used by the encoding device and capable of being refilled and / or reused. Non-limiting examples of replaceable supply components include printer cartridges for inks, toners, and / or 3D printing substrates; filtration and / or cleaning systems for household appliances (such as carbon filters, mesh / fiber filters, detergents, finishing coatings, etc.); and chemical dispensing cartridges for industrial manufacturing equipment. This disclosure is not limited to the examples described herein, and the encoding device can be any computing device capable of writing data, and the replaceable supply component can be any device capable of being coupled to and / or communicating with the encoding device and storing any type of replaceable supply.

[0015] Encoding devices may include multiple different components. For example, an encoding device may include: a network component (e.g., a cloud component) capable of sending communications to and / or receiving communications from the network; a key derivation function (KDF) component capable of generating KDF-derived keys; and a switching component capable of generating data packets received by the switching service and receiving data packets sent by the switching service.

[0016] As illustrated, method 100 may include, at 101, sending a request for information about the replaceable supply component to the non-volatile memory of the replaceable supply component. The non-volatile memory of the replaceable supply component may be a dedicated memory element controlled by an external controller or memory attached to an on-board microcontroller, etc. For example, as... Figure 2 As illustrated, the switching component of the encoding device can request information about the replaceable supply component from its non-volatile memory. The requested information may include a supply identifier, supply data, and any other data that the encoding device will use to create a request blob for the switching service.

[0017] At 103, method 100 further includes receiving supply component information from the replaceable supply component. The supply component information may include data to be decrypted by the exchange service. In some examples, the supply component information may include structured data as well as potentially unstructured data. For example, regardless of the type of supply component being reprocessed, a top-level protocol (e.g., structured data) may be used, and other unstructured data may be added to that top-level protocol to complete the request blob.

[0018] Supply component information received by the encoding device from the supply component can be formatted in a specific data format. For example, the supply component information can be formatted as a JavaScript Object Notation (JSON) object and represented as a string. The individual properties within the object can be represented as American Standard Code for Information Interchange (ASCII) strings, the interpretation of which can be agreed upon based on the encoded data. However, the examples are not limited to this, and the properties within the object (e.g., supply component information) can be represented as hexadecimal strings, decimal integers, or any other format. While the various examples in this disclosure describe using JSON to format blobs, the examples are not limited to this. Any number of data formats can be used, including CSV, XML, HTML, and C#, etc.

[0019] The supply component information received by the encoding device from the supply component includes several different attributes, each of which is formatted in a specific data format. As a non-limiting example, the supply component information may include version, device information, a unique identifier for the supply component, a request splitter, a counter, a platform, a chip mode identifier, supply data, and previous status.

[0020] The version attribute includes a string representing the version of a data blob structure in the format "1.X". In some examples, the version is written as an ASCII string, but this is not an exception. The device information attribute includes a blob structure describing metadata closely related to the encoding device. Device information can be written as a JSON object, but this is not an exception. Non-limiting examples of device information attributes include a device unique identifier, firmware version, serial number, and product number. The device unique identifier attribute can include a unique identifier for the encoding device that generated the request. This can be a hardware security identifier or some other identifier that can be used to track the encoding device over time. The device unique identifier can be formatted as a hexadecimal string. The firmware version attribute can include the version of the firmware running on the encoding device and can be formatted as an ASCII string. The serial number attribute can include the published serial number of the encoding device and can be formatted as an ASCII string. The product number attribute can include the product SKU number used for the encoding device and can be formatted as an ASCII string.

[0021] The unique identifier for a supply component includes a supply identifier for a given platform. For example, a particular supply component might have a first supply identifier for an inkjet printing platform and a second supply identifier for a laser printing platform. The unique identifier for a supply component can be represented as an ASCII string, but examples are not limited to this. Request splitter attributes can include any decimal integer that differs between multiple requests. Request splitters can be a mixture of timestamps, counters, or other data, but must be unique between requests. Counter attributes include the number of times the supply component has been previously reprocessed and can be provided by the supply component. In various examples, counter attributes are represented as decimal integers.

[0022] Platform attributes can be used to identify the technology used for encoding supply data, and thus the general format of the supply component data. Platform attributes can be written as ASCII strings and include an indication of the technology type. For example, a platform attribute may include a first annotation type to indicate that the supply component is for inkjet printing and that the supply component data is written for an inkjet printer. As another example, a platform attribute may include a second annotation type to indicate that the supply component is for laser printing and that the supply component data is written for a laser printer.

[0023] A chip pattern identifier can be used to indicate the template that the exchange service will use to decode data in a requested blob. In other words, for a given chip type, a codec can be used to extract the data. Within a platform, the chip pattern identifier can indicate which template or set of templates to choose from when decoding supply data. In various non-limiting examples, the chip pattern identifier can be written as a decimal integer.

[0024] Supply data attributes can be platform- and product-specific. For example, ink products are entered with data specific to an inkjet platform, and laser products are entered with data specific to a laser printing platform. Each of these attributes contains a platform-specific structure, as described below. A blob can contain one type of supply data attribute. Supply data attributes can be formatted as JSON objects, but examples are not limited to this.

[0025] Previous status attributes can include confirmation of successful reprocessing of a previous supply item. Previous status attributes can be formatted as a JSON object. The attributes of the previous status include a unique identifier for the previously reprocessed supply item, a request distributor for the previously reprocessed supply item, and the reprocessing status for the previously reprocessed supply item.

[0026] As described above, the unique identifier for a previously reprocessed supply component includes a supply identifier specific to a given platform. For example, a particular supply component may have a first supply identifier for an inkjet printing platform and a second supply identifier for a laser printing platform. The unique identifier for a previously reprocessed supply component may be represented as an ASCII string, but examples are not limited to this. The request splitter attribute for a previously reprocessed supply component includes any decimal integer that differs across multiple requests. The reprocessing status for a previously reprocessed supply component includes a status mapping to an error code table that reflects whether a previous response blob was reprocessed.

[0027] As described herein, the supply data attributes of a supply component object can be platform- and product-specific. For example, ink products are input with data specific to an inkjet platform, and laser products are input with data specific to a laser printing platform. Each of these attributes contains a platform-specific structure. For instance, attributes of an inkjet supply data object might include a template master, a base key table, data storage, challenge length, and partition data. The template master includes an integer representing the template version. The base key table attribute, data storage attribute, and challenge length attribute might include a Base64 string used for signature verification. The partition data attribute might include raw partitions from the supply storage device. The data contained in the partition data attribute can be parsed using a corresponding supply template, which can be looked up using a chip pattern identifier and template version.

[0028] The attributes of a laser supply data object may include encryption elements, last used date, installation date, protected status, reuse, and count. The encryption element attribute includes encryption elements and / or digital signatures used to establish trust, and in some examples may be formatted as a 192-byte string. The last used date attribute may include the date the supply was last used, and may be formatted as a 4-byte date code. The installation date may include an immutable cartridge installation date, which may be empty in some cases. The installation date may be formatted as a 4-byte date code. The protected status attribute may include data about whether the anti-theft protection function was activated by the user for the corresponding supply component. The protected status attribute may be formatted as a 2-byte integer. If the protected status attribute is 0, it indicates that the supply component is not protected. The reuse attribute may include data indicating that the supply component has been reused. The reuse attribute may be formatted as a 1-byte integer. The count attribute may include an indication of the number of times the supply component has undergone reprocessing events, such as those reported by the exchange service. The count attribute may be represented as a Base64 encoded bit field. Other attributes may be included in the laser supply data object. For example, it may include different and / or additional attributes that incorporate historical data and / or feature settings.

[0029] Once supply component information is received from the supply component and through the switching service component of the encoding device, the supply component information is encapsulated and sent to the switching service. Accordingly, in response to receiving supply component information from the replaceable supply component, method 100 may include generating a KDF-derived key. To generate a KDF-derived key, the switching service component of the encoding device may send a request to the KDF-derived component of the encoding device. (See also: Regarding...) Figure 2 As described, the KDF derived key component can return the generated KDF derived key to the exchange service component.

[0030] like Figure 1 As illustrated, method 100 further includes, at 105, generating a request blob including supply component information. The request blob may include a header and a payload, and in some examples may be a JSON Network Exchange (JWE) data structure. The header may include a description of the encryption operations and parameters employed by the blob. In various examples, the header is a JOSE (JSON Object Signing and Encryption) header. The payload of the request blob includes the message to be protected (supply component information).

[0031] The parameters of the JOSE header can include zip, jti, iat, exp, kid, identityP1, and identityAckP1. The zip header is used for communication optimization and includes a "DEF" value, which indicates that the payload was compressed before encryption. The jti header includes a JWT ID for detecting replay. As used herein, replay refers to or includes repeated reprocessing requests. The iat header includes an "issued at" timestamp. The exp header includes an expiration timestamp. The kid header includes a key ID. The identityP1 header includes an indication of Identity Envelope version 1, reflecting the encoding device's initial registration with the exchange service, or updating the encoding device's registration with the exchange service if an error occurs. The identityAckP1 header includes confirmation that the encoding device has registered with the exchange service and can use the current master key. Once a master key is established between the encoding device and the exchange service and until it is revoked, the request blob will not include "identityP1" or "identityAckP1".

[0032] The KDF-derived keys used at various points during blob transmission and reception depend on the master key. Key establishment can be performed by registering the encoding device with the key registration service. The key registration service responds with a packet payload named "entity_config". This packet can be provided back to the encoding device in the "identityAckP1" attribute. After registration, the exchange service queries the key registration service for the KDF-derived keys.

[0033] If the encoding device is reset to its factory default settings, it may be unable to process the exchange service for the encoding device blob due to an unknown masterKeyId error, a signature verification error, or an identityAck envelope verification error. In such cases, the encoding device can send the blob containing the identityP1 envelope from the JOSE header to the exchange service to establish a new envelope master key.

[0034] The `kid` attribute in the JOSE header varies depending on whether the message is from an encoding device to an exchange service or from an exchange service to an encoding device. For communication from an encoding device to an exchange service, the `kid` attribute in the JOSE header follows this format:

[0035]

[0036] The masterKeyId attribute can be used during envelope generation (e.g., regarding...). Figure 2 The key (discussed) is generated by the firmware of the encoding device and can be Base64URL encoded. The deviceProductUniqueID attribute can be a unique identifier for the encoding device and can be lowercase letters and hyphens. The serviceName attribute is "svc_supply_encoding". keyIndex can be an incrementing index used to generate a one-time AES key. Since both communication from the encoding device to the exchange service and communication from the exchange service to the encoding device use the key index, the key index used for communication from the encoding device to the exchange service increments independently of the key index used for communication from the exchange service to the encoding device.

[0037] For communication between the exchange service and the encoding device, the kid attribute in the JOSE header follows the following format:

[0038]

[0039]

[0040] Similar to the `kid` attribute for communication from an encoding device to a switching service, the `masterKeyId` attribute can be used during envelope generation (e.g., regarding...). Figure 2 The key (discussed) is generated by the firmware of the encoding device and can be Base64URL encoded. The deviceProductUniqueID attribute can be a unique identifier for the encoding device and can be lowercase letters and hyphens. The serviceName attribute is "svc_supply_encoding". keyIndex can be an incrementing index used to generate a one-time AES key. Since both communication from the encoding device to the exchange service and communication from the exchange service to the encoding device use the key index, the key index used for communication from the encoding device to the exchange service increments independently of the key index used for communication from the exchange service to the encoding device.

[0041] At 107, method 100 further includes cryptographically signing the request blob before sending it to the exchange service for reprocessing of the replaceable supply component. In various examples, cryptographically signing the request blob includes creating the request blob using a KDF-derived key, as per [reference needed]. Figure 2 As further described, payload encryption and signing can be based on authentication encryption using AES128-GCM, and the encryption key can be rotated with each payload.

[0042] In various examples, the request blob is provided to the exchange service for reprocessing of replaceable supply components. Since the process described herein can be performed on a network-based system or without a network connection, method 100 may include providing the request blob for copying and pasting in a web browser, and / or providing the request blob directly to the exchange service via a network connection.

[0043] Figure 2 An example method 200 for generating a request for reprocessing of replaceable supply components according to the present disclosure is illustrated. Figure 2 The diagram illustrates the delay sequence of communication between encoding device 252, user 248, and switching service 250. (See also: Regarding...) Figure 1 As briefly described, method 200 can begin at the start of the first transaction after a reset or key error. During this process, an identity envelope is generated prior to runtime.

[0044] At 202, method 200 includes user 248 sending a query for information about replaceable supply components via a browser to switching component 246 of encoding device 252. At 204, method 200 includes switching service component 246 of encoding device 252 sending a request for an identification envelope to network service component 242 of encoding device 252.

[0045] In response to receiving a request for the identification envelope, at 206, the network service component 242 of the encoding device 252 can create a master key. In response to generating the master key, at 208, the network service component 242 of the encoding device 252 can send the identification envelope back to the exchange service component 246 of the encoding device 252.

[0046] Once the switching service component 246 of the encoding device 252 obtains the identification envelope, the process continues at runtime, as illustrated. Regarding Figure 1 The method during runtime is discussed in more detail. At 210, method 200 includes the switching service component 246 of the encoding device 252 sending a request for supply component information to the replaceable supply component 240. For example, as in Figure 1 As described at 101, the switching service component can send a request for information about the replaceable supply component to the non-volatile memory of the replaceable supply component. In response to receiving the request for information about the replaceable supply component, at 212, the replaceable supply component 240 responds to the switching service component 246 of the encoding device 252 with the requested information about the replaceable supply component. For example, as in... Figure 1As described at 103, method 200 includes receiving supply component information from a replaceable supply component, wherein the supply component information includes data to be decrypted by the exchange service at 103.

[0047] In response to receiving information about the replaceable supply component at 212, at 214, the exchange service component 246 of the encoding device 252 requests a KDF-derived key from the KDF-derived component 244. In various examples, the KDF-derived key can be used to establish a key between the non-volatile memory of the replaceable supply component and the encoding device. For example, at 216, the KDF-derived component 244, in cooperation with the exchange service component 246 of the encoding device 252, can derive a KDF-derived key from the master key (generated at 206). At 218, the KDF-derived component 244 returns the KDF-derived key to the exchange service component 246 of the encoding device 252. This KDF-derived key can be used to cryptographically sign the request blob, as discussed herein.

[0048] At 220, the switching service component 246 of the encoding device 252 creates a request blob. (See also: Regarding...) Figure 1 As described, the request blob includes supply component information in the request blob content and an identifier envelope in the request blob header (generated at 208). Once the request blob is created by the exchange service component 246 of the encoding device 252, it is provided to the user 248 at 222. The user 248 can copy and paste the request blob into a browser used for the exchange service 254. In some examples, the encoding device 252 sends the request blob directly to the exchange service 254.

[0049] In various examples, method 200 includes, at 224, user 248 logging into exchange service 250, and at 226, forwarding the request blob to exchange service 250. Although Figure 2 The illustration shows a user logging in at step 224 (e.g., after the request blob is generated), but the example is not limited to this. A user can log in to the exchange service 250 at any time during runtime.

[0050] At 226, user 248 provides a request blob to exchange service 250. At 228, exchange service 250 provides a response blob with reprocessing instructions to user 248. Encoding device 252 can receive the response blob from exchange service 250. Regardless of how the encoding device receives the response blob from the exchange service, the response blob can include multiple attributes, each with a JSON data type. As described herein, the examples are not limited to the JSON data format, and other data formats can be used.

[0051] At 230, user 248 provides the response blob received from exchange service 250 to exchange service component 246 of encoding device 252. At 232, exchange service component 246 of encoding device 252 sends a message to KDF derivation component 244 to obtain another KDF derivation key. For example, in response to receiving a response blob from the exchange service, encoding device 252 can obtain a second KDF derivation key. The KDF derivation key generated at 234 is different from the KDF derivation key generated at 218. At 234, KDF derivation component 244 returns the KDF derivation key to exchange service component 246 of encoding device 252. At 236, exchange service component 246 of encoding device 252 decrypts the reprocessing instruction. In other words, in response to receiving the second KDF derivation key, the encoding device decrypts the blob. At 238, exchange service component 246 of encoding device 252 sends the reprocessing instruction to replaceable supply component 240. In some examples, the reprocessing instructions append or modify data in the chip of the replaceable supply component to designate the replaceable supply component as the reprocessed supply component.

[0052] The response blob shares the same architecture as the request blob and is specific to the type of supply component being reprocessed. For example, if the supply component is an ink cartridge, the response blob includes several characteristics, including signature data, write partitions, and a host-provided data file. The signature data characteristic includes a data block containing the reprocessing mode, key ID, and signature. The write partition characteristic includes a binary representation of the raw data that needs to be written to the ink cartridge supply component. The host-provided data file characteristic includes one or more host-provided data file blocks, as defined by the host-provided data file specification. This parameter is optional because host-provided data file functionality has become available on different platforms.

[0053] If the supply is a laser supply component, the laser reprocessing data can include multiple characteristics. For example, the laser reprocessing data can include a count attribute, which is represented as a 3-bit field on the supply component, where each set bit indicates a remanufacturing cycle. Other attributes can be included in the laser reprocessing data. For example, different and / or additional attributes can be included, such as fill level, multiple reprocessing cycles, and digital signature attributes.

[0054] When describing data to be written back to the supply, the response blob can indicate which data to write to the supply component and where in the supply component's memory it should be written. The format of the write block can vary between technology platforms, but one option is as follows:

[0055] address1||length1||data1||address2||length2||data2||…

[0056] Figure 3 An example block diagram of a computing device 309 according to the present disclosure, including instructions for generating a request for reprocessing of a replaceable supply component, is shown. Figure 3 As illustrated, computing device 309 may include processor 311 and computer-readable storage medium 313. Computing device 309 may be similar to... Figure 2 The encoding device 252 is shown in the diagram. Thus, the computing device 309 can perform... Figure 1 Method 100 illustrated in the figure and Figure 2 Method 200 is illustrated in the figure.

[0057] Processor 311 may be a central processing unit (CPU), a semiconductor-based microprocessor, and / or other hardware devices suitable for controlling the operation of computing device 309. Computer-readable storage medium 313 may be an electronic storage device, magnetic storage device, optical storage device, or other physical storage device that contains or stores executable instructions. Therefore, computer-readable storage medium 313 may be, for example, random access memory (RAM), electrically erasable programmable read-only memory (EEPROM), storage devices, optical discs, etc. In some examples, computer-readable storage medium may be a non-transitory storage medium, wherein the term "non-transitory" does not cover transient propagation signals. As described in detail below, computer-readable storage medium 313 may be encoded with a series of executable instructions 315 to 321.

[0058] As illustrated, computer-readable storage medium 313 can store instructions 315, which, when executed, cause computing device 309 to establish a key with a chip of replaceable supply component using a KDF-derived key, as per the diagram. Figure 1 and Figure 2 The subject of discussion.

[0059] Computer-readable storage medium 313 may store instructions 317, which, when executed, cause computing device 309 to generate a request blob comprising a request for reprocessing of a replaceable supply component using the computing device. The request blob has multiple attributes, each with a specific data type. Any number of standard data formats can be supported, including CSV, XML, HTML, and C#. As described herein, the request blob may include successful reception of a previous response blob and encoded acknowledgment.

[0060] Computer-readable storage medium 313 may store instructions 319 and 321, wherein instruction 319, when executed, causes computing device 309 to cryptographically sign a request blob, and instruction 321, when executed, causes computing device 309 to send the request blob to an exchange service. In some examples, computer-readable storage medium 313 includes instructions that, when executed, cause computing device 309 to receive a response blob from the exchange service, the response blob having multiple attributes, each of which has a JSON data type.

[0061] Similarly, regarding Figure 1 and Figure 2 The computer-readable storage medium 313 discussed may include instructions that, when executed, cause the computing device 309 to obtain a second KDF-derived key in response to receiving a response blob from the exchange service. In some examples, the computer-readable storage medium 313 includes instructions that, when executed, cause the computing device 309 to decrypt the response blob in response to receiving the second KDF-derived key. The computer-readable storage medium 313 may further include instructions that, when executed, cause the computing device 309 to append or modify data in the chip of the replaceable supply component to designate the replaceable supply component as a reprocessed supply component.

[0062] Figure 4 An example block diagram of a computing device 409 according to the present disclosure, including instructions for generating a request for reprocessing of a replaceable supply component, is shown. Figure 4 As illustrated, computing device 409 may include processor 411 and computer-readable storage medium 413. Computing device 409 may be similar to... Figure 3 The computing device 309 shown in the figure and Figure 2 The encoding device 252 is shown in the diagram. Thus, the computing device 409 can perform... Figure 1 Method 100 illustrated in the figure and Figure 2 Method 200 is illustrated in the figure.

[0063] Processor 411 may be a central processing unit (CPU), a semiconductor-based microprocessor, and / or other hardware devices suitable for controlling the operation of computing device 409. Computer-readable storage medium 413 may be an electronic storage device, magnetic storage device, optical storage device, or other physical storage device that contains or stores executable instructions. Therefore, computer-readable storage medium 413 may be, for example, random access memory (RAM), electrically erasable programmable read-only memory (EEPROM), storage devices, optical discs, etc. In some examples, computer-readable storage medium may be a non-transitory storage medium, wherein the term "non-transitory" does not cover transient propagation signals. As described in detail below, computer-readable storage medium 413 may be encoded with a series of executable instructions 423 to 429.

[0064] Computer-readable storage medium 413 may store instructions 423, which, when executed, cause computing device 409 to generate a request blob comprising a request for reprocessing of replaceable supply components using the computing device. The request blob has multiple attributes, each having a specific data type. Computer-readable storage medium 413 may store instructions 425, which, when executed, cause computing device 409 to cryptographically sign the request blob. Computer-readable storage medium 413 may store instructions 427, which, when executed, cause computing device 409 to send the request blob to an exchange service.

[0065] Computer-readable storage medium 413 may store instructions 429, which, when executed, cause computing device 409 to receive a response blob from a switching service. This response blob has multiple attributes, each with a specific data type. In some examples, computer-readable storage medium 413 may store instructions that, when executed, cause computing device 409 to append or modify data in the memory chip of a replaceable supply component to designate the replaceable supply component as a reprocessed supply component.

[0066] In some examples, computer-readable storage medium 413 may store instructions that, when executed, cause computing device 409 to receive a response blob including an error identifier. In this case, computing device 409 can identify the error type from the response blob. For example, the response blob may include an indication of an error, rather than reprocessing data for a supply part. The error blob may employ the same encapsulation method as the request blob and response blob. The format used for the error object includes version, device unique identifier, unique identifier for the supply part, original request distributor, error distributor, error status, and original error data.

[0067] The version attribute includes a string representing the version of the error blob structure in the format "1.X". The unique identifier includes a unique identifier for the encoding device that generated the request. This could be a hardware security identifier or some other identifier that can be used to track individual encoding devices over time. The unique identifier for the supply part includes an identifier for the supply part applicable to a given platform. This can differ between inkjet and laser printing products. The original request splitter includes the request splitter attribute for the request blob or response blob that encountered the error on the encoding device. The error splitter includes approximately the number of seconds since 1970 when the error blob was generated, or a counter for the number of error messages sent, which can allow differentiation from other duplicate blobs. The error status includes the encoding of the fault encountered that generated the blob. Furthermore, the original error data includes any error-related data that firmware developers can find useful for debugging problems with the encoding device. This error-related data can vary between platforms and products and can be left blank in some cases.

[0068] Error codes can be shared across product platforms and series, so a standard exhaustive search can be used to identify error types. Various errors may include, but are not limited to, 'ok', 'badSignature', 'wrongConsumable', 'wrongRequest', 'failedWrite', 'missingSupply', 'failedRead', 'noEngineResponse', 'attributeMismatch', 'unknownEngine', 'remanDataVerificationFailed', 'remanDataParsingError', and 'remanDataInvalid'. An 'ok' error indicates that no error was identified, the data was expanded, and it was successfully written to the correct supply component. A 'badSignature' error indicates that the received response blob could not be authenticated. A 'wrongConsumable' error indicates that the received blob was not prepared for the currently inserted supply component. A 'wrongRequest' error indicates that the received blob was prepared for the supply component but had an incorrect request splitter. A 'failedWrite' error indicates that an attempt to write to remanWriteBlocks failed and could not be recovered. The `missingSupply` error indicates that an attempt to read or write data failed because no supply could be communicated with. The `failedRead` error indicates that an attempt to read data from a supply failed, even though the supply could be detected. The `noEngineResponse` error indicates that the formatter-side cloud communication application has not yet received a response from the engine. The `attributeMismatch` error indicates that the received response blob does not contain the same supply and device identification data as the initial request. The `unknownEngine` error indicates that the engine encountered an error not described above. The `remanDataVerificationFailed` error indicates that an error was encountered while decrypting the response blob. The `remanDataParsingError` error indicates that an error occurred while parsing the response blob pattern. The `remanDataInvalid` error indicates that the attributes in the response blob do not meet certain expectations, such as exceeding the maximum allowed number of reprocessing events for that supply.

[0069] In various examples, computer-readable storage medium 413 may store instructions that, when executed, cause computing device 409 to generate a second request blob in response to identification of an error type, the second request blob including a request for reprocessing of a replaceable supply component using the computing device; to cryptographically sign the second request blob; and to send the second request blob to an exchange service.

[0070] Although specific examples have been illustrated and described herein, various alternative and / or equivalent embodiments may be used in place of the specific examples shown and described without departing from the scope of this disclosure. This application is intended to cover any rewriting or modification of the specific examples discussed herein. Therefore, this disclosure is intended to be limited only by the claims and their equivalents.

Claims

1. A method for generating a request for reprocessing of a replaceable supply component, comprising: The exchange service component of the printing device sends a request for information about the replaceable supply component to the non-volatile memory of the replaceable supply component. In response to the request to send supply component information, the supply component information is received from the replaceable supply component at the exchange service component of the printing device, wherein the supply component information includes data to be decrypted by the exchange service; In response to receiving the supply component information, a request blob including the supply component information is generated, the request blob including a header having an identifier envelope for registering the printing device with the exchange service; In response to generating the request blob, the request blob is cryptographically signed and sent to the exchange service for reprocessing of the replaceable supply component; Receive a response from the exchange service, the response carrying data to be written to the non-volatile memory of the supply component; as well as The printing device writes the data to be written to the non-volatile memory of the supply component into the non-volatile memory of the replaceable supply component.

2. The method according to claim 1, comprising: A key derivation function KDF is generated in response to receiving supply component information from the replaceable supply component.

3. The method according to claim 1, wherein, Encryptively signing the request blob involves using a KDF-derived key to create the request blob.

4. The method according to claim 1, comprising: Provide the requested blob to copy and paste in the browser.

5. The method according to claim 1, comprising: The request blob is provided to the exchange service.

6. A non-transitory computer-readable storage medium, comprising instructions that, when executed, cause a computing device to: Use the key derivation function KDF to derive a key and establish a key with the chip of the replaceable supply component; Generate a request blob, the request blob including a request for reprocessing of the replaceable supply component using a printing device including the computing device, the request blob having multiple attributes, each of which has a specific data type, the request blob including a header having an identifier envelope for registering the printing device with an exchange service; Encrypt and sign the request blob; and The request blob is sent to the exchange service using the exchange service component of the printing device. The printing device receives a response from the exchange service at the exchange service component, the response carrying data to be written to the non-volatile memory of the replaceable supply component; as well as The data is written to the non-volatile memory of the replaceable supply component using the printing device.

7. The non-transitory computer-readable storage medium according to claim 6, wherein, The response received from the exchange service is a response blob, which has multiple attributes, each of which has a JSON data type.

8. The non-transitory computer-readable storage medium according to claim 6, wherein, The request blob includes confirmation of successful reception of the previous response blob and the encoded confirmation.

9. The non-transitory computer-readable storage medium of claim 6, further comprising instructions that, when executed, cause the computing device to: A second KDF derived key is obtained in response to receiving a response blob from the exchange service.

10. The non-transitory computer-readable storage medium of claim 9, further comprising instructions that, when executed, cause the computing device to: The response blob is decrypted in response to receiving the second KDF derived key.

11. The non-transitory computer-readable storage medium of claim 9, further comprising instructions that, when executed, cause the computing device to: Data is appended or modified to the chip of the replaceable supply component to designate the replaceable supply component as a reprocessed supply component.

12. A non-transitory computer-readable storage medium comprising instructions that, when executed, cause a computing device to: Generate a request blob, the request blob including a request for reprocessing of replaceable supply parts using a printing device including the computing device, the request blob having multiple attributes, each of which has a specific data type, the request blob including a header having an identifier envelope for registering the printing device with an exchange service; Encrypt and sign the request blob; The request blob is sent to the exchange service using the exchange service component of the printing device. Receive a response blob from the exchange service, the response blob having multiple attributes, each of which has a specific data type; as well as In response to receiving the response blob, data is appended to the memory chip of the replaceable supply component using the printing device.

13. The non-transitory computer-readable storage medium according to claim 12, wherein, Adding data to the memory chip of the replaceable supply component includes adding the data to the memory chip of the replaceable supply component to designate the replaceable supply component as a reprocessed supply component.

14. The non-transitory computer-readable storage medium of claim 12, further comprising instructions that, when executed, cause the computing device to: Receive a response blob including an error identifier; and The error type is identified from the response blob.

15. The non-transitory computer-readable storage medium of claim 14, further comprising instructions that, when executed, cause the computing device to: A second request blob is generated in response to the identification of the error type, the second request blob including a request for reprocessing of the replaceable supply component using the computing device; Encrypt and sign the second request blob; and The second request blob is sent to the exchange service.

Images