DETAILED ACTION
This communication is in response to Applicant’s amendment filed on September 05, 2025. 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. Examiner acknowledges Applicant’s amendment and remarks. However, the rejection under 35 USC § 103 is maintained. The rejection is stated below.
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 .
Response to Arguments
Applicant's arguments with respect to 35 U.S.C. § 103 rejection have been fully considered but they are not persuasive.
Applicants argues that the cited references do not disclose any command code indicating to the host device to transfer a command without decoding it, as recited in the claimed limitation.
In Response:
Examiner respectfully disagrees with Applicant’s assertion. The disclosure explicitly define the command code as data represents the type of operation to be executed by the command or the transmitted frame (Command 400 comprises a sequence of data comprising, strictly in the following order: - a command code field 401 (Cmd Code) comprising a data, called command code hereafter, that represents the type of operations executed by the command 400; - a length data field 402 (Len) comprising a data that represents the length of the sequence of command 400, meaning the number of bytes composing command 400; - a payload field 403 (Payload) comprising a data, called hereafter payload, that represents data used to execute the command 400; and - a verification data field 404 (CRC) comprising a verification data of the command 400. Spec, para [0123])( Data comprised in the command code field 401 only indicates the type, or the category, of command 400, or in other words the type of operations that are executed when the command 400 is implemented. Spec, para [0125]).
Given the broadest reasonable interpretation for the claimed limitation. The primary reference teaches command code that indicate the type of information and operation provided to be executed (Sub-IE field 530 can contain one or more sub-IEs 540. As shown, sub-IE 540 provides a type identifier field 542 that indicates the type of information provided in the sub-element. Examples of types of information that can be provided include an opcode identifying an operation associated with IE 520 (e.g., searching for accessories to pair, negotiating a key, authenticating a shared secret, sending an encrypted message such as wireless network credentials); an address of a target device; a session identifier; a sequence number; a cryptographic key; a random nonce; an authenticator or digital signature; encrypted data; device capability and/or configuration information; device name (manufacturer and/or model name); network credentials (which can be encrypted, e.g., as described below). Examples of uses for various information types are described below. Bradley, para [0069]).
Bradley teaches pairing procedure between two devices by establishing shared secret which implies that any transmitted data via the controller will not be decoded until it reaches the recipient who has the shared secret key to decrypt the encrypted message (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]).
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) 1-21 and 24-28 are rejected under 35 U.S.C. 103 as being unpatentable over Bradley US 2012/0054493 A1 (hereinafter “Bradley”) in view of Bhamidipati et al. US 2013/0311694 A1 (hereinafter “Bhamidipati”)
As per claim 1, Bradley teaches an authentication method, in view of a pairing, of a peripheral device to a companion device via a host device (The two devices can establish a shared secret and/or verify that the other has the same shared secret. Bradley, para [0007])( Processor 202, which can be implemented as one or more integrated circuits (e.g., a conventional microprocessor or microcontroller), can control the operation of controller 200. In various embodiments, processor 202 can execute a variety of programs in response to program code and can maintain multiple concurrently executing programs or processes. At any given time, some or all of the program code to be executed can be resident in processor 202 and/or in storage media such as storage medium 208. Bradley, para [0044]), the method comprising:
initiating a pairing session (one device (the "controller") can broadcast an initial probe to announce that it is searching for devices with which it can pair. Bradley, para [0007]); 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, the first command code indicating to the host device to transfer the first command without decoding it (Probes are generally sent in cleartext (although in some embodiments described below, an encrypted message can be embedded in a cleartext probe request or probe response). Bradley, para [0042])( Sub-IE field 530 can contain one or more sub-IEs 540. As shown, sub-IE 540 provides a type identifier field 542 that indicates the type of information provided in the sub-element. Examples of types of information that can be provided include an opcode identifying an operation associated with IE 520 (e.g., searching for accessories to pair, negotiating a key, authenticating a shared secret, sending an encrypted message such as wireless network credentials); an address of a target device; a session identifier; a sequence number; a cryptographic key; a random nonce; an authenticator or digital signature; encrypted data; device capability and/or configuration information; device name (manufacturer and/or model name); network credentials (which can be encrypted, e.g., as described below). Examples of uses for various information types are described below. Bradley, para [0069]).
Bradley does not explicitly teach a host device separate from the companion and the peripheral device, even though the processor of Bradley’s controller device can be interpreted to be the host device in the pairing process.
However, Bhamidipati teaches a host device organizing the process of pairing between peripheral and companion device. (See Bhamidipati Fig. 4 & Fig. 5 and related paragraphs.)
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 Bradley and Bhamidipati to explicitly mention the host device. One would be motivated to do so, for the clarity of the pairing process between two devices.
As per claim 2, Bradley and Bhamidipati teach the method according to claim 1, 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]).
As per claim 3, Bradley and Bhamidipati teach the method according to claim 1, wherein the first encrypted payload comprises an encrypted second command code (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]).
As per claim 4, Bradley and Bhamidipati teach the method according to claim 3, wherein the first encrypted payload further comprises an encrypted first parameter associated with the second command code (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] See Fig. 5 and related paragraphs).
As per claim 5, Bradley and Bhamidipati teach the method according to claim 4, further comprising 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]).
As per claim 6, Bradley and Bhamidipati teach the method according to claim 3, 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 (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]).
As per claim 7, Bradley and Bhamidipati teach the method according to claim 3, 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 (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]).
As per claim 8, Bradley and Bhamidipati teach the method according to claim 7, further comprising the companion device or the peripheral device generating a first response after the operation is executed (the accessory can receive the probe request containing the controller's public key CPUB. The accessory can generate its own private key ("APRIV") and public key ("APUB") at block 828. In one embodiment, the accessory can generate 32 bytes of cryptographically strong random data, convert the data to a private key APRIV using a cryptographic algorithm such as Curve25519, and compute a public key APUB from APRIV. Other techniques for generating a public-private key pair can be substituted; in general, compatible techniques should be used at blocks 822 and 828. At block 830, the accessory can send its public key APUB to the controller using a probe response. Bradley, para [0097]).
As per claim 9, Bradley and Bhamidipati teach the method according to claim 8, wherein the first response comprises a first response command (the accessory can receive the probe request containing the controller's public key CPUB. The accessory can generate its own private key ("APRIV") and public key ("APUB") at block 828. In one embodiment, the accessory can generate 32 bytes of cryptographically strong random data, convert the data to a private key APRIV using a cryptographic algorithm such as Curve25519, and compute a public key APUB from APRIV. Other techniques for generating a public-private key pair can be substituted; in general, compatible techniques should be used at blocks 822 and 828. At block 830, the accessory can send its public key APUB to the controller using a probe response. Bradley, para [0097]).
As per claim 10, Bradley and Bhamidipati teach the method according to claim 9, wherein the first response further comprises a second parameter (the accessory can receive the probe request containing the controller's public key CPUB. The accessory can generate its own private key ("APRIV") and public key ("APUB") at block 828. In one embodiment, the accessory can generate 32 bytes of cryptographically strong random data, convert the data to a private key APRIV using a cryptographic algorithm such as Curve25519, and compute a public key APUB from APRIV. Other techniques for generating a public-private key pair can be substituted; in general, compatible techniques should be used at blocks 822 and 828. At block 830, the accessory can send its public key APUB to the controller using a probe response. Bradley, para [0097]).
As per claim 11, Bradley and Bhamidipati teach the method according to claim 8, further comprising encrypting the first response (the controller can receive the probe response and extract APUB. At this stage, the controller and the accessory are each in possession of both public keys APUB and CPUB. Bradley, para [0098]).
As per claim 12, Bradley and Bhamidipati teach the method according to claim 8, wherein the companion device or the peripheral device decrypts the first encrypted payload using a pairing session key and wherein the first response is encrypted with the pairing session key by the companion device or the peripheral device (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])( Examples of types of information that can be provided include an opcode identifying an operation associated with IE 520 (e.g., searching for accessories to pair, negotiating a key, authenticating a shared secret, sending an encrypted message such as wireless network credentials); an address of a target device; a session identifier; a sequence number; a cryptographic key; a random nonce; an authenticator or digital signature; encrypted data; device capability and/or configuration information; device name (manufacturer and/or model name); network credentials (which can be encrypted, e.g., as described below). Examples of uses for various information types are described below. Bradley, para [0069]).
As per claim 13, Bradley and Bhamidipati teach the method according to claim 8, further comprising generating a second encrypted command by one of the companion device or the peripheral device, the second encrypted command comprising, in the following order: the first command code; a second encrypted payload; an encrypted version of the first response; and a second verification code of the encryption of the second 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]).
As per claim 14, Bradley and Bhamidipati teach the method according to claim 13. Bradley does not explicitly teach further comprising the one of the companion device or the peripheral device sending the second encrypted command to the other of the peripheral device or the companion device, via the host device.
However, Bhamidipati teaches the one of the companion device or the peripheral device sending the second encrypted command to the other of the peripheral device or the companion device, via the host device (The processing circuit may be adapted to pair with a peripheral, and establish a docking session with a dockee. The processing circuit may receive, via the communication interface, a peripheral direct connect request from the dockee to directly pair with the peripheral. Further, the processing circuit may transmit, via the communication interface, a peripheral direct connect response to the dockee, where the peripheral direct connect response includes information to enable the dockee to directly pair with the peripheral. Bhamidipati, para [0010])( the dockee 430 may receive a peripheral direct connect response from the docking host 420. For example, the processor 432 may receive the peripheral direct connect response via the communication interface 434. The peripheral direct connect response includes information to enable the dockee 430 to establish a direct communication link (e.g., communication link 446) with the peripheral 410. In some examples, the peripheral direct connect response may be formatted like the peripheral direct connect response described above and depicted in FIG. 15. Bhamidipati, para [0133])
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 Bradley and Bhamidipati to explicitly mention the host device. One would be motivated to do so, for the clarity of the pairing process between two devices via a host device.
As per claim 15, Bradley and Bhamidipati teach 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 (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]).
As per claim 16, Bradley and Bhamidipati teach the method according to claim 15, wherein the companion device or the peripheral device decrypts the first encrypted payload using a pairing session key (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]).
As per claim 17, Bradley and Bhamidipati teach the method according to claim 1, further comprising executing an identification session before initiating the pairing session (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]).
As per claim 18, Bradley and Bhamidipati teach the method according to claim 17, wherein, during the identification session, the companion device decides that the pairing session is needed (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]).
As per claim 19, Bradley and Bhamidipati teach the method according to claim 18, 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 (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]).
As per claim 20, Bradley and Bhamidipati teach the method according to claim 19, 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]).
As per claim 21, Bradley and Bhamidipati teach the method according to claim 1, 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 a 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]).
As per claim 27, Bradley and Bhamidipati teach the method according to claim 1, 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 (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]).
Claims 24-26 and 28 have limitations similar to those treated in the above rejection, and are met by the references as discussed above, and are rejected for the same reasons (of anticipation\ and rationales) as used above.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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