DETAILED ACTION
This communication is in response to App. No. 18/350/518 after the pre-brief appeal conference that was held on March 10, 2026. Claims 27 and 28 have been added new, claims 22 and 23 have been canceled, and claims 20, 21, 25 and 26 have been amended. Claims 1-21 and 24-28 are pending and are directed towards AUTHENTICATION METHOD FOR USE IN PAIRING A PERIPHERAL DEVICE TO A COMPANION DEVICE VIA A HOST DEVICE.
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
Claims 1-21 and 24-28 rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1, 24, 25 and 26 recite the limitation “the first command code indicating to the host device to transfer the first command without decoding it” which is vague not clear. it is not understood whether the pronoun “it” refers to first command? Which is not encrypted initially to be decoded, or is it referring to the first encrypted payload.
Claim 26 recites the limitation “… are capable of implementing” which is indefinite, as the limitation is not positively claimed using the phrase “capable of”
Claim 28 recites the limitation “wherein the host device does not attempt to…” which is indefinite, as the limitation is not positively claimed using the phrase “attempt to”
Claims 2-21 and 27 are rejected by dependency.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claim(s) 1, 3-4, 15-18 and 24-28 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Hancock US 2009/0100349 A1 (hereinafter “Hancock”)
As per claims 1, 24, 25 and 26, Hancock teaches an authentication method, in view of a pairing, of a peripheral device to a companion device via a host device (allow the relay service to authenticate and accept connections from terminal clients and terminal shadow clients. Hancock, para [0039), the method comprising:
initiating a pairing session (establishing a first connection between a terminal client and a relay service, wherein the terminal client is engaged in an interactive session with a terminal service, creating a second connection between a shadow client and the relay service, and relaying data and commands between the terminal client and the shadow client through the relay service. Hancock, para [0012]); and
in response to the initiating, receiving a first command by the host device, wherein the first command comprises a first command code and a first encrypted payload to be exchanged between the peripheral device and the companion device via the host device (state change indicated by terminal client 408 produces a "command" message to be sent to relay service. For the purposes of this description, command messages, including command data, are messages and communications passed between terminal relay agent 410, relay service 418, and terminal shadow client 420. Also for the purposes of this description and as used in the examples, the term payload data applies to encapsulated data that includes the original and optimized protocols of terminal service 412. In certain embodiments, messages between terminal relay agent 410, relay service 418 and terminal shadow client 420 take the form of a command message construct. Accordingly, payload data can be sent in the form of a command, typically identified as a "PAYLOAD_DATA" command and accompanied by a data stream which provided as the payload including the terminal service protocol for relaying. Hancock, para [0056]) the first command code indicating to the host device to transfer the first command without decoding it (Certain embodiments provide for separate encryption of payload data and command data. In these embodiments, a user of the terminal client 408 user and a user of the terminal shadow client 420 can trust each other without trusting the relay service 418 to decrypt payload data. Hancock, para [0057])( relay service 418 sees the command message protocol passing through it to negotiate the third session key, it does have a copy or otherwise know the resultant third symmetric key. The use of a third symmetric key enables terminal relay agent 410 and terminal shadow client 420 to use the third symmetric key to encrypt and decrypt payload data and relay service 418 can thus decrypt command data without being able to decrypt the payload data which is a component of PAYLOAD_DATA command messages. Hancock, para [0059]) (payload data encryption through a relay service 418 may be negotiated using cryptographic keys not known by relay service 418. Such payload encryption may be established automatically through the shadow client shell or may be predetermined by user selection, configuration and/or application requirements. Logging services, discussed below, may also operate with payload data encrypted via keys unknown to the relay service. That is, the relay may log encrypted control and payload data that cannot be encrypted or decrypted by the relay service. The relay service and other components may nevertheless log and authenticate (enabling non-repudiation of data) the encrypted payload data. Hancock, para [0060])
As per claim 3, Hancock teaches the method according to claim 1, wherein the first encrypted payload comprises an encrypted second command code (The interactive session can be encrypted using first encryption keys while the first and second connections may be encrypted using different encryption keys. In some of these embodiments, the terminal client decrypts the data and commands relayed from the shadow client and re-encrypts certain of the data and commands using the first encryption keys. Hancock, para [0012]).
As per claim 4, Hancock teaches the method according to claim 3, wherein the first encrypted payload further comprises an encrypted first parameter associated with the second command code (The interactive session can be encrypted using first encryption keys while the first and second connections may be encrypted using different encryption keys. In some of these embodiments, the terminal client decrypts the data and commands relayed from the shadow client and re-encrypts certain of the data and commands using the first encryption keys. Hancock, para [0012]).
As per claim 15, Hancock teaches the method according to claim 1, further comprising the companion device or the peripheral device decrypting the first encrypted payload when the companion device or the peripheral device receives the first command (negotiate the third session key, it does have a copy or otherwise know the resultant third symmetric key. The use of a third symmetric key enables terminal relay agent 410 and terminal shadow client 420 to use the third symmetric key to encrypt and decrypt payload data and relay service 418 can thus decrypt command data without being able to decrypt the payload data which is a component of PAYLOAD_DATA command messages. Hancock, para [0059]).
As per claim 16, Hancock teaches the method according to claim 15, wherein the companion device or the peripheral device decrypts the first encrypted payload using a pairing session key (a process for establishing a secure channel is described. At step 1000, terminal relay agent 410 establishes a communication channel 422 to relay service 418 and a symmetric session key is established according to the cryptographic techniques and protocols adopted. This symmetric session key is maintained private to terminal relay agent 410 and relay service 418. Relay service 418 maintains the communication channel 422 while waiting at step 1002 for a terminal shadow client 420 to establish a session. Hancock, para [0058]).
As per claim 17, Hancock teaches the method according to claim 1, further comprising executing an identification session before initiating the pairing session (a logical process for defining a session that may be established between two or more users of terminal client 408 and terminal shadow client 420. Hancock, para [0039]).
As per claim 18, Hancock teaches the method according to claim 17, wherein, during the identification session, the companion device decides that the pairing session is needed (When a session has been defined, a user of the terminal client 408 may connect the terminal client to the relay service 418. The terminal relay agent 410 behavior embedded in the terminal client 408 can be used to establish this connection 422 and FIG. 6 includes a flow diagram showing the terminal client 408 connecting to a session with the relay service 418. Hancock, para [0040]).
As per claims 27 and 28, Hancock teaches the method according to claims 1 and 25, further comprising exchanging the first encrypted payload between the peripheral device and the companion device via the host device, wherein the host device does not decrypt the first encrypted payload in response to the indication in the first command code (Certain embodiments provide for separate encryption of payload data and command data. In these embodiments, a user of the terminal client 408 user and a user of the terminal shadow client 420 can trust each other without trusting the relay service 418 to decrypt payload data. Hancock, para [0057])( relay service 418 sees the command message protocol passing through it to negotiate the third session key, it does have a copy or otherwise know the resultant third symmetric key. The use of a third symmetric key enables terminal relay agent 410 and terminal shadow client 420 to use the third symmetric key to encrypt and decrypt payload data and relay service 418 can thus decrypt command data without being able to decrypt the payload data which is a component of PAYLOAD_DATA command messages. Hancock, para [0059]) (payload data encryption through a relay service 418 may be negotiated using cryptographic keys not known by relay service 418. Such payload encryption may be established automatically through the shadow client shell or may be predetermined by user selection, configuration and/or application requirements. Logging services, discussed below, may also operate with payload data encrypted via keys unknown to the relay service. That is, the relay may log encrypted control and payload data that cannot be encrypted or decrypted by the relay service. The relay service and other components may nevertheless log and authenticate (enabling non-repudiation of data) the encrypted payload data. Hancock, para [0060])
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 2, 5-7 and 19-21 are rejected under 35 U.S.C. 103 as being unpatentable over Hancock US 2009/0100349 A1 (hereinafter “Hancock”) in view of Bradley US 2012/0054493 A1 (hereinafter “Bradley”)
As per claim 2, Hancock teaches the method according to claim 1. Hancock does not explicitly teach wherein the first command comprises a first verification code of the encryption of the first encrypted payload.
However, Bradley teaches wherein the first command comprises a first verification code of the encryption of the first encrypted payload (Checksum field 512 can include error detection and/or error correction codes, such as a 32-bit cyclic redundancy check. Bradley, para [0067])( The two devices can establish a shared secret and/or verify that the other has the same shared secret. In some embodiments, the shared secret can be established and/or verified by exchanging further probes. In other embodiments, all the information needed to establish the shared secret can be provided in the initial exchange of probes, and the shared secret can be verified through another mechanism, such as user confirmation. Bradely, para [0032]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to modify the teaching of Hancock in view of Bradely. One would be motivated to do so, to verify the transmitted encrypted payload.
As per claim 5, Hancock teaches the method according to claim 4. Hancock does not explicitly teach the method further comprising the companion device or the peripheral device verifying that the first parameter is adequate after the encrypted first parameter is decrypted.
However, Bradley teaches the companion device or the peripheral device verifying that the first parameter is adequate after the encrypted first parameter is decrypted (the accessory can generate additional encryption and authentication keys based on the shared secret. At block 614, the accessory can communicate securely with the controller using the additional keys. For example, the accessory can use the keys to encrypt a message, then send the encrypted message in an information element (or other data item) within a probe. Similarly, the accessory can receive a probe that contains an encrypted message from the controller and can use the keys to decrypt and authenticate the message. Bradley, para [0078]) (the encrypted message can be sent with authentication data, allowing the recipient to verify the message's origin and integrity. Bradley, para [0010]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to modify the system of Hancock in view of Bradely. One would be motivated to do so, to verify the transmitted encrypted payload.
As per claim 6, Hancock teaches the method according to claim 3. Hancock does not teach the method further comprising the companion device or the peripheral device verifying that the second command code is adequate after the encrypted second command code is decrypted.
However, Bradley teaches the companion device or the peripheral device verifying that the second command code is adequate after the encrypted second command code is decrypted (the encrypted message can be sent with authentication data, allowing the recipient to verify the message's origin and integrity. Bradley, para [0010]) (The two devices can establish a shared secret and/or verify that the other has the same shared secret. In some embodiments, the shared secret can be established and/or verified by exchanging further probes. In other embodiments, all the information needed to establish the shared secret can be provided in the initial exchange of probes, and the shared secret can be verified through another mechanism, such as user confirmation. Each device can then use the shared secret to generate additional encryption and authentication keys. These latter keys can be used to secure (e.g., encrypt and/or authenticate) message content that can be transmitted between the devices using additional probe requests and probe responses. For example, the secured (e.g., encrypted) message content can be included in an information element within an IEEE 802.11 probe request or probe response frame. Bradley, para [0032]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to modify the system of Hancock in view of Bradely. One would be motivated to do so, to verify the transmitted encrypted command and payload.
As per claim 7, Hancock teaches the method according to claim 3. Hancock does not explicitly teach the method further comprising the companion device or the peripheral device executing an operation associated with the second command code after the encrypted second command code is decrypted.
However, Bradley teaches the companion device or the peripheral device executing an operation associated with the second command code after the encrypted second command code is decrypted (the controller can send the public key CPUB to the accessory using a probe request. Public key CPUB can be included as an information element or other data item. The public key can be sent as cleartext. The controller can also include other information within one or more information elements in the probe request, such as a unique session ID that can thereafter be included in all probe requests and probe responses associated with the pairing session. Use of a session ID can assist the controller and the accessory in determining the state of the pairing link (e.g., whether key negotiation is in progress or completed) and processing received probe requests and probe responses accordingly. In some embodiments, the other information can also include a unique sequence identifier (unique within the session) that allows probe responses to be matched to specific probe requests. Bradley, para [0096]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to modify the system of Hancock in view of Bradely. One would be motivated to do so, to enhance the security of the system by executing operations and verifying the transmitted encrypted command and payload.
As per claim 19, Hancock teaches the method according to claim 18. Hancock does not explicitly teach the method further comprising the companion device sending a second encrypted response to the host device in response to the companion device deciding that the pairing session is needed.
However, Bradley teaches the companion device sending a second encrypted response to the host device in response to the companion device deciding that the pairing session is needed (the controller can send a probe request containing a session ID to the accessory. As noted above, the session ID is assigned by the controller and is specific to a pairing with a particular accessory…the accessory uses Secure Remote Password ("SRP," documented at http://srp.standford.edu/) to generate public key APUB. At block 908, the accessory can generate a random salt, e.g., compliant with SRP. At block 910, the accessory can send a probe response containing the public key APUB and the random salt to the controller. This probe response, and all subsequent probe requests or probe responses, can also include the session ID that was provided by the controller at block 902. Bradley, para [0107-0108]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to modify the system of Hancock in view of Bradely. One would be motivated to do so, to enhance the security of the system by pairing with the right device.
As per claim 20, Hancock and Bradley teach the method according to claim 19. Hancock does not explicitly teach wherein the second encrypted response comprises, in the following order: a second response code indicating to the host device that the authentication method continues; a first status data indicating the pairing session has been initiated; a third encrypted payload comprising a third encrypted command; and a third verification code of the encryption of the third encrypted payload.
However, Bradley teaches wherein the second encrypted response comprises, in the following order: a second response code indicating to the host device that the authentication method continues; a first status data indicating the pairing session has been initiated; a third encrypted payload comprising a third encrypted command; and a third verification code of the encryption of the third encrypted payload (Probe frame structure 500 includes a number of fields; in some embodiments, some or all of these fields can correspond to the frame structure prescribed by IEEE 802.11 standards. For example, frame control field 502 can provide general information about the frame such as protocol version, type of frame (e.g., identifying it as a probe request or probe response frame), and other information usable by a receiving device to interpret a received wireless signal stream…Length field 544 can be used to indicate the length of sub-IE 540. Payload field 546 can contain the information identified by type identifier field 542. Bradley, para [0066-0072]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to modify the system of Hancock in view of Bradely. One would be motivated to do so, to enhance the security of the system by pairing with the right device.
As per claim 21, Hancock teaches the method according to claim 1. Hancock does not explicitly teach wherein the peripheral device is a circuit for an ink cartridge, the companion device is a circuit for a printer, and the host device is a circuit for the printer.
However, Bradley teaches wherein the peripheral device is a circuit for an ink cartridge (Printing elements 310 can include various electronic and/or mechanical components such as paper feeders, ink jet apparatus, laser printing apparatus, and the like. Bradley, para [0056], the companion device is a circuit for a printer (accessories 110 (e.g., a printer). Bradley, para [0035]), the host device is a circuit for the printer (an accessory with a limited user interface (e.g., a WiFi-enabled printer) can establish a pairing with a controller (e.g., a WiFi-enabled personal computer) and can obtain, via the pairing, the credentials for a wireless network to which the controller is currently joined. Bradley, para [0033]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to modify the system of Hancock in view of Bradely. One would be motivated to do so, to enhance the security of the system by securely pairing between printer and ink cartridge circuitry.
Allowable Subject Matter
Claim 8 objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims. Claims 9-14 objected by dependency.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KHALID M ALMAGHAYREH whose telephone number is (571)272-0179. The examiner can normally be reached Monday - Thursday 8AM-5PM EST & Friday variable.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, RUPAL DHARIA can be reached at (571)272-3880. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
Respectfully Submitted
/KHALID M ALMAGHAYREH/Primary Examiner, Art Unit 2492
Prosecution Insights