Communication Protocol Intermediary for Error Status Reporting

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current communication methods between PCs and network devices, such as printers, fail to provide clear reasons for the inability to generate SNMP response packets, leading to user inconvenience due to the lack of status information in HTTP response packets.

Innovation Solution

A method where a second packet is generated according to a second protocol, including a first packet from a first protocol, and status information is included in a response packet if a response to the first packet is impossible, allowing the sending of this information back to the first apparatus.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If an SNMP response packet is not generated and sent back to the PC, then the device can avoid generating unnecessary data, but the PC cannot identify the reason for the communication failure

Engineering Contradiction:
Improvecommunication failure identificationVSAvoidstatus information
Core Design Contradiction:
ReliabilityVSLoss of information

Solution Approach 1:

The patent introduces an HTTP response packet as an intermediary carrier to transmit status information from the device to the PC. When SNMP response generation fails, the device embeds status information (error codes, messages) within the HTTP response packet body, allowing the PC to receive and interpret the failure reason without requiring a traditional SNMP response packet. This mediator approach resolves the contradiction by providing information transmission through an alternative channel.

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The patent nests status information within the HTTP response packet structure. Specifically, the status information (including error codes and descriptive messages) is embedded as content within the HTTP response body, creating a nested information structure where the HTTP packet contains both protocol-level status and application-level diagnostic information. This nesting enables comprehensive error reporting without requiring separate communication packets.

Inventive Principle:
Principle #7Nested doll (Nesting)

2Ease of operation

If the PC sends an SNMP request packet, then information can be acquired from the device, but the PC cannot determine why the device cannot generate a response

Engineering Contradiction:
Improveuser convenienceVSAvoidcause information
Core Design Contradiction:
Ease of operationVSLoss of information

Solution Approach 1:

The patent implements a feedback mechanism where the device provides detailed status information back to the PC through the HTTP response packet. When an SNMP request is received and cannot be processed, the device generates an HTTP response containing feedback information such as error codes (e.g., 501 Not Implemented, 503 Service Unavailable) and descriptive messages explaining the cause of failure. This feedback enables the PC to understand the specific reason for response generation failure, improving user convenience by eliminating guesswork.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The HTTP response packet serves as an intermediary that carries cause information from the device to the PC. Instead of relying on the absence of an SNMP response to indicate failure, the HTTP packet mediates the communication by explicitly conveying the reason for failure through its body content, making the diagnostic information accessible to the PC and end users.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Reliability

If status information is included in the HTTP response packet, then the PC can identify communication failures, but the protocol complexity increases

Engineering Contradiction:
Improveerror identification capabilityVSAvoidprotocol implementation complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The patent leverages the universality of the HTTP protocol to achieve reliable error identification without increasing protocol complexity. By using the existing HTTP response packet structure (which is already universally supported for web communication), the device can convey status information through standard HTTP mechanisms. The status information is embedded in the HTTP response body using conventional formatting, allowing the same HTTP infrastructure to serve both information delivery and error reporting functions simultaneously.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The patent changes the parameter being transmitted within the HTTP response packet from typical web content to diagnostic status information. Instead of modifying the HTTP protocol structure itself, the invention utilizes existing HTTP parameters (response body content) and repurposes them to carry error codes and status messages. This parameter repurposing approach enables enhanced error identification capability while maintaining protocol simplicity, as no structural changes to HTTP are required.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentUS12068908B2Communication method and control method in information processing apparatus
Publication Date: 2024.08.20 CANON KK
  • US12068908B2 patent drawing
  • US12068908B2 patent drawing
  • US12068908B2 patent drawing

AI summary

A method for communicating between apparatuses, comprises: in a first apparatus, generating a second packet according to a second protocol, the second packet including a first packet according to a first protocol; in the first apparatus, sending the generated second packet to a second apparatus; in the second apparatus, receiving the second packet; in the second apparatus, determining whether a response to the first packet included in the second packet is possible; and in the second apparatus, in a case where it is determined that a response to the first packet is impossible, including status information corresponding to a cause for the impossibility of the response in a response packet corresponding to the second packet and sending the response packet to the first apparatus.