Universal cloud printing protocol

Abstract

The invention provides a universal cloud printing system and method. According to the method, cloud-based printing is comprehensively considered from the perspective of a server and a printer. By using printer metadata and explicit constraints, the server may accommodate various types of printers. Various printers of different manufacturers, specifications, formats, or functions can print payloads in unison. A status code from the printer is defined and triggers a response operation of the server.

Description

Technical Field

[0001] This application claims priority to the filing date of U.S. application No. 17 / 940,428, filed on September 8, 2022, the disclosure of which is hereby incorporated by reference into this document. Background Art

[0002] A cloud printer is a printer that connects directly to a remote server via a printing protocol. Designing and implementing such a protocol is difficult, and no widespread standard exists. To date, such protocols have been developed by printer hardware manufacturers, which has led to systemic flaws in interacting with the server. For example, existing protocols developed by printer manufacturers tend to be pull-based, slow, and do not support firmware upgrades. Status codes are ambiguous, making it unclear to the remote server what action to take.

[0003] Existing push-based protocols often use Message Queuing Telemetry Transport (MQTT) and may not be flexible and reliable enough. When MQTT is used for printing, the print results must be separate MQTT packets, which may cause problems when using an MQTT broker. Existing printing protocols sometimes perform pipelining of messages, but this may introduce problems with out-of-order printing.

[0004] Existing protocols assume specific content formats and printer capabilities, and often only work with printers from a specific vendor. Other printers will not print the same payload in the same way, for example if the paper width is different or if it is not equipped with a paper cutter. Summary of the invention

[0005] The present disclosure provides a universal cloud printing system and method that merges the perspectives of the server and the printer in cloud-based printing. By using printer metadata and explicit constraints, the server is able to adapt to various types of printers. Printers of different manufacturers, specifications, formats, or functions can print payloads consistently. For example, print tasks from a remote server can be printed consistently regardless of whether the printer has different paper widths, paper cutters, etc. The status code of the printer is clearly defined and triggers a response action from the server.

[0006] One aspect of the present disclosure provides a method for implementing universal printing in a cloud printing network, the method comprising: receiving respective printer metadata from multiple different types of printers on one or more processors; generating a print task message for a given printer among the multiple different types of printers on one or more processors, wherein the generation process includes using the printer metadata from the given printer; and sending the print task message to the given printer among the multiple different types of printers through the one or more processors.

[0007] According to some examples, the method may also include: receiving, on one or more processors, a status from a given printer among a plurality of different types of printers; and automatically performing a response operation in response to receiving the status. The status may indicate a status of a print job and / or a status of a given printer.

[0008] According to some examples, receiving printer metadata includes receiving respective connection messages from a plurality of different types of printers, each connection message including printer metadata for a respective printer. The method may further include: establishing a respective ordered bidirectional communication channel between the one or more processors and the respective printer in response to each connection message. In addition, the method may further include: initiating a firmware upgrade for a given printer on the communication channel by the one or more processors.

[0009] According to some examples, the method may further include: receiving information from each of the plurality of different types of printers, the information representing options specific to the respective printer. An example of such an option is sound. The printer metadata may represent content format, device attributes, capabilities, or other information.

[0010] Another aspect of the present disclosure provides a universal cloud printing system, which includes a memory and one or more processors communicating therewith. The one or more processors can be configured to receive printer metadata from each printer of a plurality of different types of printers, generate a print task message for a given printer of a plurality of different types of printers (wherein the generation process includes using printer metadata from a given printer), and send the print task message to a given printer of a plurality of different types of printers. In addition, the one or more processors can also be configured to receive a status from a given printer of a plurality of different types of printers, and automatically perform a response operation upon receiving the status. The status can indicate the status of the print task, the status of a given printer of a plurality of different types of printers, or other status.

[0011] Receiving printer metadata may include receiving a connection message from each printer of a plurality of different types of printers, each connection message containing printer metadata for a respective printer. The one or more processors may be further configured to establish a respective ordered bidirectional communication channel between the one or more processors and the respective printer in response to each connection message. The one or more processors may be further configured to initiate a firmware upgrade for a given printer via the communication channel.

[0012] According to some examples, the one or more processors may be further configured to receive connection information from each of the plurality of different types of printers, the information indicating options specific to the respective printer. These options may include sound, etc. The printer metadata may indicate content format, device attributes, capabilities, or other printer information. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] Figure 1 is an illustration of an example system shown in accordance with aspects of the present disclosure.

[0014] Figure 2 It is shown Figure 1 A block diagram showing details of components in the example system shown.

[0015] Figure 3 An example of establishing a connection between a printer and a server using the universal cloud printing protocol described herein is shown.

[0016] Figure 4 An example of a server prompting to adjust printer options according to aspects of the present disclosure is shown.

[0017] Figure 5 is a flow chart illustrating an example of a method according to aspects of the present disclosure. DETAILED DESCRIPTION

[0018] The universal cloud printing system and method described herein provides a universal, abstract printing protocol with an improved printer-server interaction model and semantics. In this protocol, the printer exposes its own metadata and constraints. The payload presented by the server can take into account buffer sizes, different formats, printer capabilities, etc. The printer can also provide server-centric status codes, each of which triggers the server to perform a corresponding action. In this regard, the printer can control the server to some extent by sending codes to trigger specific actions.

[0019] The protocol described in this article also provides support for indirect connections. The protocol is independent of any specific transport and encoding method and supports multiple specific implementations. The protocol supports both in-band and non-in-band keep-alive connections. In-band keep-alive connections can be dynamically updated to save data usage. The protocol also provides in-band firmware upgrade capabilities and supports printers that are not connected to the Internet. In addition, the protocol provides server-controlled remote logging capabilities, and the server can request the printer to send arbitrary log messages for detailed diagnostics. Moreover, the protocol allows the server to terminate the connection gracefully, which can reduce the printer's reconnection time if the server needs to disconnect (for example, for an upgrade).

[0020] Figure 1An example system is shown, including a server 110 communicating with a plurality of printers 160-164 via a network 150. The printers 160-164 may be connected to the server 110 via the network 150 by wire or wirelessly. The connection may be direct or indirect, such as via a client computing device (not shown). By way of example only, the printer may be coupled to a tablet computer via a short-range wireless pairing (e.g., Bluetooth) connection, and the tablet computer may be wirelessly connected to the server 110. The printers 160-164 may include a variety of different types of printers, with different features and functions. For example, the printers 160-164 may use paper of different sizes or shapes, have different paper feed methods, print using different formats or fonts, leave different spaces after printing, be equipped with a cutter for facilitating paper tearing, etc. Each printer 160-164 may be located in a different geographic location. For example, each printer 160-164 may be located in a different commercial building, and these different commercial buildings may be located in the same city or in different cities. Although multiple printers 160-164 are shown, it should be understood that any number of printers may be used in a system that communicates with server 110. Likewise, although server 110 is shown as multiple computing devices (e.g., devices in a rack), server 110 may include one or more computing devices located in the same or different locations. For example, server 110 may be multiple servers in a distributed computing environment. A detailed description of servers, networks, and printers is provided in Figure 2 .

[0021] Figure 2 The components of the server 110, printers 160-162, and network 150 are shown in detail. Each server 110 may include one or more processors 220, memory 230, and other components typically found in server computing devices. Each memory 230 of the server 110 may store information accessible by one or more processors 220, including instructions 234 executable by one or more processors 220.

[0022] Memory 230 may also include data 232 that may be retrieved, manipulated, or stored by the processor. Memory may be any non-volatile type capable of storing information accessible by the processor, such as hard disks, memory cards, ROM, RAM, DVD, CD-ROM, writable memory, and read-only memory.

[0023] Instructions 234 may be any set of instructions to be executed directly (e.g., machine code) or indirectly (e.g., scripts) by one or more processors. In this regard, the terms "instructions," "application," "steps," and "program" are used interchangeably herein. Instructions may be stored in an object code format for direct processing by a processor, or in any other computer device language, including a collection of scripts or independent source code modules that are interpreted on demand or compiled in advance. The functions, methods, and routines of the instructions will be explained in more detail below.

[0024] Instructions 234 may be executed by one or more processors 220 to implement a universal cloud printing protocol. According to the protocol, metadata and constraints of the printer are accessible to the server. Such metadata may indicate, for example, buffer sizes, different formats, printer capabilities, etc. In this regard, the server can send print jobs to a variety of different types of printers while adapting to the specific capabilities and constraints of each different printer. In addition, the printer can provide status codes to the server, each of which triggers a response action by the server. In this regard, the printer can control the server to some extent by sending codes to trigger specific actions.

[0025] Data 232 may be retrieved, stored, or modified by one or more processors 220 in accordance with instructions 234. For example, although the subject matter described herein is not limited to any particular data structure, the data may be stored in computer registers, in a relational database as a table with many different fields and records, or in an XML document. The data may also be formatted in any computer device readable format, such as, but not limited to, binary values, ASCII, or Unicode. In addition, the data may include any information sufficient to identify the relevant information, such as numbers, descriptive text, proprietary codes, pointers, references to data stored in other storage (e.g., other network locations), or information used by a function to calculate the relevant data.

[0026] The one or more processors 220 may be any conventional processor, such as a commercially available central processing unit (CPU). Alternatively, the processor may be a dedicated component, such as an application specific integrated circuit (ASIC) or other hardware-based processor. Although not required, one or more of the servers 110 may include dedicated hardware components for performing specific computing processes faster or more efficiently.

[0027] although Figure 2The processor, memory, and other elements of the server 110 are functionally illustrated as being located in the same module, but in reality, the processor, computer, computing device, or memory may include multiple processors, computers, computing devices, or memories, which may or may not be stored in the same physical housing. For example, the memory may be a hard disk or other storage medium located in a housing different from the housing of the server 110. Therefore, references to processors, computers, computing devices, or memory will be understood to include references to a collection of processors, computers, computing devices, or memories that may or may not operate in parallel. For example, the server 110 may include server computing devices that operate as a load balancing server cluster, a distributed system, and the like. In addition, although some of the functions described below are indicated as occurring on a single computing device with a single processor, various aspects of the subject matter described herein may be implemented by multiple computing devices, for example, by communicating information over a network 150.

[0028] Each computing device 110, 160-162 may be located at a different node of the network 150 and may be able to communicate directly or indirectly with other nodes of the network 150. Figure 2 Only a few computing devices are depicted in FIG. 1 , but it should be understood that the system may include a large number of connected computing devices, with each different computing device located at a different node of the network 150.

[0029] The network 150 and intermediate nodes described herein can be interconnected using various protocols and systems, so that the network can be part of the Internet, the World Wide Web, a specific intranet, a wide area network, or a local area network. The network can utilize standard communication protocols such as Ethernet, WiFi, HTTP, protocols described in IEEE 802.88, cellular technology (such as GSM, CDMA, UMTS, EV-DO, WiMAX, LTE, etc.) protocols, which are proprietary technologies of one or more companies, and combinations of the above technologies. Although certain advantages are obtained when information is transmitted or received as described above, other aspects of the subject matter described herein are not limited to any particular information transmission method.

[0030] For example, each server 110 may include a web server that can communicate with a storage system and printers 160-162 via network 150. For example, one or more of server computing devices 110 may utilize network 150 to transmit information to a user on a ticket or paper printed by printer 160 and present the information to the user on a display. In this regard, printers 160-162 may be considered client computing devices and may perform all or part of the functionality described herein.

[0031] According to some examples, each printer can be connected to the network 150 through a client computing device (not shown) configured similarly to the server computing device 110, and having one or more processors, memory, and instructions as described above. These client computing devices may include personal computing devices for use by users and have all the components typically used by personal computing devices, such as a central processing unit (CPU), memory for storing data and instructions (e.g., random access memory (RAM) and internal hard drive), a display (e.g., a display with a screen, a touch screen, a projector, a television, or other device capable of displaying information), and a user input device (e.g., a mouse, keyboard, touch screen, or microphone). In some examples, the client device may include a microphone to capture audio input, such as voice commands. Although the client computing devices may each be a full-sized personal computing device, they may also be mobile devices, such as a mobile phone, a tablet, or any other mobile device.

[0032] According to other examples, printers 160-162 may be directly connected to network 150. In both cases, printers 160-162 may each include one or more processors 272 and memory containing data 273 and instructions 274, similar to server 110.

[0033] Metadata

[0034] Each of the printers 160-162 can provide printer metadata to the server 110. For example, the printers 160-162 each send metadata to the server 110. In this regard, regardless of the printer type, the printed ticket can be correctly rendered while respecting the printer's capabilities and technical limitations. For example, the metadata will indicate which payload formats the printer supports. For example, an ESC / POS printer does not support formats such as PNG or TSPE, and therefore (correctly) considers such payloads invalid. The server may have different rendering logic for each type of payload. Another example is that printers have different levels of support for different complex formats. Metadata can tell the server what the printer supports so that the server can avoid using incorrect content. For example, ESC / POS has an instruction for drawing a QR code, but if the printer does not support this format, the QR code needs to be drawn manually and printed using multiple instructions. As another example, if the metadata from the printer indicates that the printer does not have a physical paper cutter, the server may omit the PAPERCUT instruction and instead instruct to output an additional blank area for manual paper tearing.

[0035] The metadata may be sent, for example, as a payload of a message. According to some examples, the printer may send the metadata in an initial connection request message. For example, Figure 3An example is shown of printer 160 sending a connection request message 330 to server 110. Connection request message 330 includes metadata for the printer. It may also include options and status. According to other examples, metadata may be sent in response to a request from server 110. For example, server 110 may send a remote procedure call (RPC) to one or more or all of printers 160-162 at the same time or at different times, requesting printer metadata.

[0036] Printer metadata may include device information, content formats and limitations, and capabilities. Device information may include model, serial number, and firmware version. Content formats and limitations may include, for example, width and byte size limitations. Byte limitations may depend on transport / encoding and do not necessarily equal physical limitations. It applies to the sum of all pending jobs, not to a single job. Capabilities may include any of a variety of possible features or functions included in printers 160-162.

[0037] In terms of device information, the Universal Cloud Print Protocol captures basic device information to facilitate detailed device management and monitoring. The vendor, model, and hardware version can be used to find stock photos of the printer, for example, to get a better customer experience. If a serial number is present, it is only expected to be unique to a specific vendor and is expected to remain the same even if the printer is factory reset. The firmware version can be used to determine if a specific printer should be upgraded.

[0038] The generic cloud print protocol can represent firmware versions in multiple potential domains for a printer that do not use a single monolithic payload. For example, the available voices might be updated independently of the main firmware.

[0039] The Universal Cloud Print Protocol may be content-agnostic in terms of content formats, but supported content and associated features and limitations may still be explicitly expressed. As new formats are developed, the Universal Cloud Print Protocol may be updated to accommodate the newly developed formats. Content types define the format. In some examples, the Universal Cloud Print Protocol may use Internet Assigned Numbers Authority (IANA) content types. The printer may also specify a maximum size limit, which can be derived from the buffer size of the printer's memory. This limit applies to unencoded content and allows for encoding and message overhead if necessary. If the print job is long, it can be split into separate jobs to meet the size limit.

[0040] Some examples of content formats may include image formats, ESC / POS, TSPL / TSPL2, etc. In image formats, graphic images may be encoded as png, tiff, etc. ESC / POS is a widely used printer command language. ESC / POS is a customizable format and the specific commands supported may vary widely between printers. It includes non-standard or dynamically updateable code pages. Some printers may support dynamically updated character sets through firmware domains. TSPL / TSPL2 is a widely used label language whose format is constantly evolving. If you load new labels to your printer, you may need to update the dimensions accordingly.

[0041] As an example of functionality, some printers 160-162 may be equipped with a cutter so that a long roll of paper is fed into the printer while a print job is being executed. When the print job is completed, a tool within the printer separates the portion of the roll that printed the print job from the rest of the long roll of paper. Other printers without a cutter may require the user to manually tear off the paper at the end of the print job. Such printers may need to eject excess paper at the end of a print job to leave additional blank space so that the user can tear off the paper without accidentally tearing off the portion of the print job that was printed.

[0042] Another example of functionality is that some printers 160-162 may have sound capabilities, such as audio input and / or output capabilities. For example, some printers can accept voice commands. Some printers can provide notifications or other information through audio output, such as tones, beeps, voice notifications, etc. Some printers have sound capabilities and allow predefined sounds to be played for tasks. For example, when placing a new print order, a "new order" voice command may accompany the task. If available, each sound can have additional context to provide a more precise sound, such as which platform the new order is from (such as an app-based food delivery service platform). The collection of sounds and contexts is open-ended. Printers with sound capabilities have separate volume settings, separate from the sound. The list of supported sounds does not include supported contexts. If the provided context is not supported, the printer will fall back to a generic voice message. Supported sounds may be updated via over-the-air updates.

[0043] Although some examples of metadata are provided above, it should be understood that other types of printer metadata may also be included. Server 110 may use metadata provided by printers 160-162 to adjust commands and other communications sent to the printers. For example, for a print job sent to one of printers 160-162, the server may take into account the format, functionality, etc. of the printer when sending the print job.

[0044] Printer Options

[0045] Options are printer settings that can be changed. Server 110 can request printers 160-162 to change options. For example, Figure 4 As shown, server 110 can send a message to any one or more of printers 160-162 instructing the printer to change an option. The printer may also change an option on its own due to direct input from a user. An example of changing an option is related to volume control. For example, if printer 160 supports sound, it may include a volume control function that can be used to adjust the volume of the output sound. For example, server 110 can instruct printer 160 to output sound at a certain percentage of maximum volume. This may be useful if server 110 determines that audio output initiated by server 110 and sent to printer 160 is not being acknowledged or otherwise responded to. For example, if server 110 determines that the audio output is not being heard, server 110 can instruct printer 160 to increase the volume of the output sound. This determination by server 110 may be based on logs or other information provided by printer 160. In response, printer 160 may make the suggested option changes, make option changes according to different specifications, or make no option changes at all. For example, if Figure 4 As shown, server 110 requests printer 160 to adjust its volume to 57%. In response, printer 160 may adjust its volume to 57%, to some other percentage, or make no adjustment. For example, a printer may only be able to adjust the volume with limited granularity if it has five volume levels, 0-20%, 40%, 60%, 80%, 100%. In this regard, the printer may not set the volume to 57% as instructed, but instead round up to 60%. In the example shown, printer 160 adjusts its volume to 60%.

[0046] Printer Status

[0047] Each printer 160-162 can provide its status information to the server 110. The printer status information tells the server 110 what operations the printer is capable of performing and what conditions are required to make the printer operational again if it is not operational. The high-level status reflects the overall condition of the printer, for example, whether it is ready to accept the next print job from the server 110. Examples of high-level status codes may include:

[0048]

[0049] Error codes may indicate a specific problem with your particular printer. Example error codes include:

[0050]

[0051] Warning codes identify conditions that have not yet occurred but may soon go wrong if no action is taken. For example, such warning codes might include:

[0052]

[0053] The general cloud printing protocol proposed in this disclosure defines a printing protocol between a server and a printer over an ordered bidirectional communication channel (such as MQTT). To support a wide range of settings, the channel can optionally provide authentication. The connection can be initiated by the printer 160 and can be gracefully disconnected by the server 110 or the printer 160. Once the connection is successful, the server 110 will quickly and reliably push print tasks in sequence and handle print failures and retries as needed.

[0054] The protocol described in this disclosure also provides indirect connection support. The protocol is independent of any specific transport and encoding, and can support multiple specific implementations. The universal cloud printing protocol is indifferent to transport and encoding. The protocol works with any ordered, bidirectional transport, such as MQTT, Websockets, or GRPC, where messages are encoded in some structured, serializable format, such as JSON, XML, or Protobuf. Therefore, the universal cloud printing protocol supports practical choices for transport and encoding, such as MQTT, GRPC, and so on. When using MQTT, the printer connects directly over MQTT and encodes the message as JSON. When using GRPC, the printer connects over GRPC and encodes the message as Protobuf. This may be particularly useful for printers connected through an intermediate device. Printer authentication can be handled by the transport layer or in-band. For example, in MQTT, authentication can be performed using a username and password.

[0055] When using MQTT as the transport protocol, MQTT can also be used to maintain connections and basic authentication. During the initial connection, the username encoded by the vendor and serial number can uniquely identify the printer and must be matched with the printer metadata in subsequent connection messages. Messages are encoded as JSON and sent on topics, including printer-to-server topics and server-to-printer topics. The printer must subscribe to the server-to-printer topic before sending a connection message. In addition to printing messages, the printer can also send ping requests as needed to maintain the MQTT connection state.

[0056] When using GRPC as the transport protocol, proto3 encoding and bidirectional streaming can be used, as well as in-band keepalives and authentication.

[0057] According to some examples, one or more Universal Cloud Print sessions can be embedded in another protocol. For example, a tablet equipped with multiple Bluetooth printers can use a single GRPC connection and multiplex multiple Universal Cloud Print streams along with other tablet data.

[0058] Since the universal cloud printing protocol is transport and encoding agnostic, the indirect connection can be implemented using any method suitable for the link transport / encoding. A client computing device (such as a tablet) can reuse the universal printing protocol for multiple locally connected printers.

[0059] A connection or session is an ordered, reliable, bidirectional stream of messages. The universal cloud printing protocol defines messages between servers and printers and organizes them into groups. Either the server 110 or the printers 160-162 can initiate a specific message. Each connection can be initiated by a printer 160-162 and completed by a handshake. For example, the printer 160 can send an authentication message "AUTH" to the server 110, followed by a connection message "CONNECT". If the server 110 accepts, it sends an acknowledgment message "ACK" for both messages. If not accepted, the server 110 sends a disconnect message "DISCONNECT" and terminates the connection without further processing of messages. Once the initial handshake is completed, the connection is established and either party can send messages. According to some examples, the printer may opportunistically send messages before receiving an acknowledgment of the connection message, expecting that the connection will be successfully established.

[0060] Each message may contain a sequence of message identifiers, a timestamp, and a single payload organized as a group. Message identifiers are sequential in each direction.

[0061] Control messages are responsible for handling connection and flow control matters, especially connection establishment, activity status, and termination.

[0062] Failure codes are high-level, localizable descriptions of why certain actions were or were not taken. These codes can be used to determine whether a connection request should be rejected or if the connection should be terminated. Examples of such failure codes include:

[0063] Status Code describe Connectivity Temporary connection problem. invalid The match operation is malformed or invalid. internal Internal error. Unavailable Temporary availability issues, such as a server reboot. Not supported The match operation is not supported. Unauthorized The match operation was not authorized, usually an authentication (AUTH) operation.

[0064] review Figure 3, the printer 160 sends a connection request 330 (e.g., a CONNECT message) to the server 110 to establish a new connection. The connection request 330 may include identification information of the printer, as well as initial printer metadata, options, and status. During printer initialization, its status should be the initial or "INIT" state, but the printer may also be connected in a READY or BLOCKED state.

[0065] According to some examples, the connection request 330 may be preceded by an authentication message "AUTH". The AUTH message allows for in-band basic authentication. Basic authentication is used to allow the server 110 to register new printers on demand. The AUTH message may include a vendor and serial number, which should match the device information in a subsequent CONNECT message.

[0066] The server 110 may respond positively or negatively to the connection request 330. A negative response may include a REJECT or DISCONNECT message. A REJECT message indicates that the referenced message was not accepted. A REJECT message may contain a failure code and may be followed by a DISCONNECT message. In some cases, a REJECT message may be used even if a connection has been established, for example, if a message could not be understood.

[0067] The DISCONNECT message indicates immediate termination of the connection. This message may contain a failure code.

[0068] The server 110's positive response to the printer 160's connection request may include an acknowledgement message, or ACK. An ACK message acknowledges that all messages, including the referenced message, have been correctly received, but not necessarily completed if the corresponding action was not immediately performed. In addition to being used to establish a connection, an ACK message can also be used to acknowledge any other type of message.

[0069] During the connection between the server 110 and the printer 160, a variety of other types of messages may be sent. One example is a keep-alive message. If sent by the printer 160, a keep-alive message (KEEPALIVE) indicates the current settings for keeping the printer in active or responsive mode, or preventing the printer from entering sleep or off mode. If sent by the server 110, a keep-alive (KEEPALIVE) indicates a suggested setting that the printer 160 may choose to use or not. A suggested duration of zero may be an instruction to disable keep-alive. The server 110 should comply with any keep-alive settings sent by the printer 160.

[0070] Another example message is a FLUSH message, which triggers an acknowledgment from the receiver. It ensures that the message was processed and that the printer uses it periodically to satisfy keep-alive requirements, but the printer or server can send it at any time. In this respect, the FLUSH message can act as a "ping". Since there is no processing on the server side and an acknowledgment is sent immediately, the FLUSH message can also be used for time synchronization of the printer. The time difference between the FLUSH message and the ACK message is close to the round-trip time, so the server timestamp + round-trip time can be used as the new printer time.

[0071] Whenever the printer metadata or status changes, an UPDATE message may be used to update this information. According to some examples, when updating the status or metadata, the status, metadata, or both may be provided. While in some examples, the complete metadata may be sent when updating, in other examples, only the portion of the metadata that has changed may be sent.

[0072] If the printer settings change after the initial CONNECT message, the printer can send an OPTION message to update one or more printer settings to the server. The message can include all of the printer's options, or only the options that have changed.

[0073] Figure 4 An example is shown in which server 110 sends an OPTION 432 message to printer 160. If sent by server 110, the OPTION message may represent a suggested setting that the printer may choose to use or not use. In the example shown, server 110 suggests that printer 160 adjust its volume to 60%. If printer 160 makes the requested change, the printer may send another OPTION 434 message to server 110 to indicate its new state. According to some examples, printer 160 may make the change, but not necessarily exactly to the specifications suggested by the server. For example, if the server suggests increasing the volume from 20% to 60%, the printer may only increase the volume to 40%.

[0074] The server can send an UPDATE message to instruct the printer to perform a self-controlled firmware upgrade. Self-controlled firmware upgrades allow the printer to control the download process to accommodate the limitations of the printer's firmware buffer size.

[0075] Job messages may be exchanged between the server 110 and the printers 160-162, for example, to instruct the printers 160-162 to perform a print job and to receive job status updates from the printers 160-162 at the server 110. Job messages may include instructions from the server to the printer to perform a print operation. For example, a PRINT message instructs the printer to print a ticket. For large tickets, this may also be autonomous to avoid splitting the print job into multiple tickets. The PRINT message may include a unique job identifier, content, control options, expiration time, etc. The control options may be based on metadata received from the specific printer to which the job is to be sent, so that the PRINT message is customized to accommodate the matching of the print job to the specific capabilities of the printer.

[0076] The printer may use the unique job identifier to detect duplicate messages. For example, if the printer 160 receives multiple print (PRINT) messages with the same unique identifier, it may determine that the messages are duplicates. The unique identifier may also be used to match the printer's response message with the instruction message from the server. For example, when the printer 160 receives the instruction message, it may send an acknowledgment message containing the unique identifier in the instruction message. When the printer 160 completes the instructions contained in the instruction message, it may send a status update that references the unique job identifier to let the server 110 know that the print job is complete. Or, if the printer 160 encounters an error, it may send an error message containing the unique job identifier to the server 110. The content may be a payload for the printer, such as instructions that instruct the printer to print the content of the job. The control options may include metadata for controlling the behavior of the printer job. For example, the control options may include an expiration time for the print job. If the printer still holds the job after that time, it may mark the job as "expired" and complete it. Other example control options include the voice to be used, or delay / hold, such as printing the job only after manual confirmation by the user.

[0077] The expiration time may indicate a time period within which the printer must execute the print job. For example, the expiration time may set a time limit after which the printer should discard the print job.

[0078] According to some examples, a print result message may be sent when a print job has completed or otherwise terminated. For example, a PRINTRESULT message may be an asynchronous response to a PRINT message, sent after the request has been fully processed. The PRINTRESULT message may include a job status to inform the server of what has occurred. The server may then use the job status to determine the next course of action.

[0079] The status of a job can be represented by status codes, where each status code tells the server what action to take next. Example status codes might include:

[0080]

[0081] Keep-alive mechanism

[0082] The generic cloud printing protocol described in this article supports both in-band keepalives and no keepalives. The keepalive parameter enables the server to determine when a connection is no longer valid. The keepalive mechanism does this by sending low-level probe messages to check if the other party is responsive. If the other party does not respond to a certain number of probe messages within a certain time, it is assumed that the connection is broken, and the process using the socket will detect this through an error indication. The in-band keepalive mechanism can be dynamically updated to save data usage - in particular, when nothing is printed at night - so it is adaptive.

[0083] In a typical system, when a connection is established, the keep-alive setting is usually fixed. For example, in MQTT, a heartbeat message (ping request message and response) may be sent at a fixed interval (such as every 20 seconds) as a heartbeat signal. If the server or printer does not receive the message within 30 seconds, it may be considered that the connection is broken. The general cloud printing protocol described in this article allows the printer to change the keep-alive interval, for example, increase the interval when a fast reconnection is not important, and reduce the interval when a fast reconnection is more important. For example, for a printer in a restaurant, a fast reconnection may not be important on nights when the restaurant is closed and there are no print jobs. Therefore, the server may propose to increase the keep-alive interval on such closed nights, for example, to increase the interval to 10 minutes. When the restaurant reopens and receives orders again, the server may initiate the operation of restoring the keep-alive interval to 20 seconds. In this regard, the cloud printing protocol intelligently saves bandwidth by sending fewer ping requests during periods when the printer is expected to be inactive.

[0084] In-band firmware upgrade

[0085] The universal cloud printing protocol described herein supports in-band firmware upgrades. Typically, to upgrade firmware, a uniform resource link (URL) may be sent to a printer to download a file, but the printer may not be physically able to download the file, for example, if access to the URL is blocked. The universal printing protocol described herein allows the printer to perform self-paced downloads over the same connection already established with the server. Therefore, a separate internet connection is not required, so upgrades can be performed more reliably. For example, the protocol uses in-band payloads and, when necessary, splits large payloads into smaller parts so that the printer can decide how fast to read them.

[0086] In-band remote logging

[0087] According to some examples, the server 110 can maintain a log of messages from the printers 160-162. The server can store the printer log messages in a database or record them as part of its own log. In this regard, diagnostic data from the printer can be captured and analyzed for debugging. According to other examples, each printer 160-162 can maintain its own operation log, such as received messages, print tasks, status, etc. The server can request that the printer send any log message. In this regard, the server can perform detailed diagnosis on the printer. For example, if the printer 160 fails, the server 110 can consult the log to determine when the printer 160 began to fail, what operations were being performed when the failure occurred, etc. The server 110 can use this information to further determine the cause of the failure, as well as possible solutions.

[0088] Server disconnected

[0089] The Universal Cloud Print Protocol allows the server to gracefully terminate the connection to any given printer. This can reduce the printer's reconnection time if, for example, the server needs to be upgraded.

[0090] Figure 5 An example method of system operation using a universal cloud printing protocol is shown. Although the operations are described in a particular order, it should be understood that the operations can be performed in a different order or simultaneously. In addition, operations can be added or omitted.

[0091] In step 510, one or more processors (such as a cloud print server) receive printer metadata from a plurality of different types of printers. The printer metadata may include, for example, device information, content and format limitations, capabilities, etc. of the printer. The metadata may be provided when and / or after a connection is established between each given printer and the server. According to some examples, the metadata may be provided periodically, such as every few hours, once a day, every few days, etc. According to other examples, the metadata may be provided when an event occurs to the printer, such as after a firmware upgrade.

[0092] In step 520, the one or more processors generate a print job message for a given printer using the corresponding metadata received from the given printer. For example, the one or more processors may receive an order from a customer that should be printed on a printer at a remote facility that is capable of fulfilling the order. The one or more processors may generate a message containing a payload of printing instructions that are adapted to the content and format limitations, capabilities, etc. of the given printer. For example, if the metadata describes the payload format, content, and capabilities supported by the printer, the server may generate instructions consistent with the supported format, content, and capabilities.

[0093] In step 530, the one or more processors send a print job message to a given printer. In response, the given printer may execute the print job, or attempt to execute the print job.

[0094] In step 540, one or more processors receive status information from a given printer. The status information may be sent automatically by a given printer upon completion of a print job, or when an error occurs during the execution of a print job. For example, the status information may indicate to the one or more processors that the print job was successfully completed. In other examples, it may indicate that the job was successfully completed, but also include a warning, such as an indication that the printer is running low on ink, paper, battery power, etc. In other examples, the status information may indicate that the print job failed before completion, and may include details on why the print job failed. Some examples of failure may include the printer rejecting the print job before attempting to execute the print job.

[0095] In step 550, one or more processors may automatically take responsive actions upon receiving the status information. For example, one or more processors may store a table or other data structure that maps potential status types to corresponding actions. In some examples, the responsive actions may depend on a combination of the status information with other information, such as printer metadata, server conditions, etc. For example, if the status information indicates that the print job failed because a given printer was out of paper, one or more processors may responsively send an alert to the given printer indicating that paper must be replenished and then resend the print job. As another example, if the status information indicates that the print job was successfully completed, one or more processors may responsively send the next print job. While these are just a few examples, it should be understood that a large number of different responsive actions can be performed based on various status information or combinations of status information with other information.

[0096] Although the present invention has been described herein with reference to specific embodiments, it is to be understood that these embodiments are merely illustrative of the principles and applications of the present invention. Therefore, it should be understood that many modifications may be made to the exemplary embodiments, and other arrangements may be conceived without departing from the spirit and scope of the present invention as defined by the appended claims.

Claims

1. A universal printing method in a cloud printing network, comprising: receiving, at one or more processors, printer metadata from a plurality of different types of printers; generating, on the one or more processors, a print job message for a given printer among a plurality of different types of printers, wherein generating includes using printer metadata from the given printer among the plurality of different types of printers; as well as Sending, where one or more processors send the print job message to a given printer among a plurality of different types of printers.

2. The method according to claim 1, characterized in that Further including: receiving, at one or more processors, a status from a given printer among a plurality of different types of printers; as well as A response action is automatically performed in response to the received status.

3. The method according to claim 2, characterized in that The status indicates the status of the print job.

4. The method according to claim 2, characterized in that: The status represents the status of a given printer among a plurality of different types of printers.

5. The method according to claim 1, characterized in that Receiving printer metadata includes receiving a connection message from each printer of a plurality of different types of printers, each connection message including printer metadata for the corresponding printer.

6. The method according to claim 5, characterized in that Further included is establishing, in response to each connect message, respective ordered bidirectional communication channels between the one or more processors and the corresponding printer.

7. The method according to claim 6, characterized in that Further including: A firmware upgrade is initiated for a given printer by one or more processors over a communications channel.

8. The method according to claim 1, characterized in that Further included is receiving information from each printer of the plurality of different types of printers, the information representing options specific to the respective printer.

9. The method according to claim 8, characterized in that The options include sound.

10. The method according to claim 1, characterized in that The printer metadata indicates a content format.

11. A universal cloud printing system, comprising: Memory; as well as one or more processors in communication with the memory, the one or more processors configured to: Receive printer metadata from many different types of printers; generating a print job message for a given printer among a plurality of different types of printers, wherein generating includes using printer metadata from the given printer among the plurality of different types of printers; as well as Sends a print job message to a given printer among a number of different types of printers.

12. The system according to claim 11, characterized in that The one or more processors are further configured to: receiving status from a given printer among a plurality of different types of printers; and A response action is automatically performed in response to receiving the status.

13. The system according to claim 12, characterized in that The status indicates the status of the print job.

14. The system according to claim 12, characterized in that The status represents the status of a given printer among a plurality of different types of printers.

15. The system according to claim 11, characterized in that Receiving printer metadata includes receiving a connection message from each printer of a plurality of different types of printers, each connection message including printer metadata for the corresponding printer.

16. The system according to claim 15, characterized in that The one or more processors are further configured to establish, in response to each connect message, a respective ordered bidirectional communication channel between the one or more processors and the corresponding printer.

17. The system according to claim 16, characterized in that The one or more processors are further configured to initiate a firmware upgrade for a given printer via the communication channel.

18. The system according to claim 11, characterized in that The one or more processors are further configured to receive information from each printer of the plurality of different types of printers, the information representing options specific to the respective printer.

19. The system according to claim 18, characterized in that The options include sound.

20. The system according to claim 11, characterized in that The printer metadata indicates a content format.

Images