DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Reopening of Prosecution After Appeal Brief
2. In view of the appeal brief filed on November 20, 2025, PROSECUTION IS HEREBY REOPENED. A new ground of rejection is set forth below.
To avoid abandonment of the application, appellant must exercise one of the following two options:
(1) file a reply under 37 CFR 1.111 (if this Office action is non-final) or a reply under 37 CFR 1.113 (if this Office action is final); or,
(2) initiate a new appeal by filing a notice of appeal under 37 CFR 41.31 followed by an appeal brief under 37 CFR 41.37. The previously paid notice of appeal fee and appeal brief fee can be applied to the new appeal. If, however, the appeal fees set forth in 37 CFR 41.20 have been increased since they were previously paid, then appellant must pay the difference between the increased fees and the amount previously paid.
A Supervisory Patent Examiner (SPE) has approved of reopening prosecution by signing below:
Response to Argument 3. Applicant’s remarks/arguments filed on November 20, 2025 have been fully considered and are deemed persuasive. The new prior art presented in this Office Action satisfies all of
the argued limitations. Therefore, this Office Action is made Non-Final.
Claim Rejections - 35 USC § 102
4. 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.
5. Claims 1-15 are rejected under 35 U.S.C. 102 (a) (1) as being anticipated by Zarakas et al. US Patent Application Publication No. 2016/0309323 (hereinafter Zarakas).
Regarding claim 1, Zarakas discloses a device (Fig. 1, second device 130) associated with an account, the account being associated with an accessory (Fig. 1, First Device 120) having a public key (see Zarakas par. 0088, a backend system may generate a public/private key pair and may assign that public/private key pair to a particular account. A particular account may be associated with a first device, the device comprising:
“memory” (Fig. 1, Memory 126c); and
one or more processors (Fig. 1, Microprocessor 126a) in communication with the memory and configured to:
“receive, when establishing an initial connection between the device and the accessory, an encrypted message transmitted by the accessory, wherein the encrypted message contains the public key and is encrypted using a private key” (see Zarakas pars. 0088-0095, At block 504, a backend system may generate a public/private key pair and may assign that public/private key pair to a particular account. A particular account may be associated with a first device (accessory). At block 506, the private key in the public/private key pair assigned to a particular account may be programmed into a first device associated with the particular account. A private key may be programmed into the microcontroller, and/or a secure element which may comprise a microprocessor, memory, and/or an applet in the first device. Memory may store at least one private key used to validate and/or create a Bluetooth and/or BLE connection with a second device (device). In block 508, a backend system may then receive a request from the second device for the public key associated with the account the user logged into. A backend system may validate the login credentials. At block 510, in response to receiving and validating the login credentials, the backend system may transmit the public key to the second device. The public key may be transmitted in an encrypted format. The second device may then encrypt a handshake and transmit this encrypted handshake to the first device in order to validate the first device);
“decrypt the encrypted message to obtain the public key” (see Zarakas par. 0094, The first device may attempt to decrypt this encrypted handshake using the private key securely stored in the first device. If the first device is successful at decrypting the handshake, the handshake will be verified and a Bluetooth and/or BLE connection may be created between the first and the second device using the data in the handshake);
“validating the public key” (see Zarakas par. 0097, A second device user may enter login credentials via the second device, which may then be transmitted to a backend system. A backend system may receive and validate the login credentials and, in response, transmit a public key to the second device. The public key may be transmitted in an encrypted format. A second device may receive the public key and may use the public key to encrypt a handshake that may be used to validate the first device and create the Bluetooth and/or BLE connection);
“decrypt the encrypted message to obtain a public key” (see Zarakas par. 0094, The first device may attempt to decrypt this encrypted handshake using the private key securely stored in the first device. If the first device is successful at decrypting the handshake, the handshake will be verified and a Bluetooth and/or BLE connection may be created between the first and the second device using the data in the handshake); and
“establish, after validating the public key, the initial connection between the device and the accessory via short-range wireless pairing” (see Zarakas par. 0013, a first device storing a private key may enter advertising mode to create a Bluetooth/BLE connection. An advertising packet (e.g., advertising PDU) may be transmitted (e.g., in encrypted format). A second device may enter scanning or initiator mode and may receive the advertising packet. A second device may request that a user log into an account associated with the first device (e.g., a customer account, a financial account, an employee account, and/or the like) in order to initiate a Bluetooth/BLE connection. A second device user may enter login credentials via the second device, which may then be transmitted to a backend system. A backend system may receive and validate the login credentials and, in response, transmit a public key to the second device. The public key may be transmitted in an encrypted format. A second device may receive the public key and may use the public key to perform a public/private key handshake in order to validate the first device. The handshake may then be validated by the first device;
Regarding claims 2, 7, and 12, Zarakas discloses the device of claim 1, the non-transitory computer-readable medium of claim 6, the method of claim 11,
wherein the one or more processors are further configured to search for the public key (see Zarakas par. 0012, a second device may include a device able to connect with the first device via a Bluetooth or BLE connection. The second device may include a microprocessor, microcontroller, or other memory programmed to allow a user to log into an account, connect with a backend system to retrieve a public key associated with the account, and validate an advertising PDU using public/private key encryption technology.).
Regarding claims 3, 8, and 13, Zarakas discloses the device of claim 1, the non-transitory computer-readable medium of claim 6, the method of claim 11,
wherein the one or more processors are further configured to providing media to the accessory after establishing the initial connection (see Zarakas par. 0036, Data storage 124 may include random access memory (RAM) and read only memory (ROM), which may be configured to access and store data and information and computer program instructions, such as firmware and/or other applications. Data storage 124 may also include storage media or other suitable type of memory (e.g., such as, for example, RAM, ROM, programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), any type of tangible and non-transitory storage medium), where the files that comprise an operating system, application programs, private keys, and/or data files may be stored.).
Regarding claims 4, 9, and 14, Zarakas discloses the device of claim 1, the non-transitory computer-readable medium of claim 6, the method of claim 11,
wherein the public key is associated with a serial number of the accessory (see Zarakas par. 0004, the device in scanning or initiator mode scans the appropriate channels for advertising packets and, upon detection of a packet, may send out a connection request. An advertising packet, or advertising channel packet data unit (PDU), may include identifiers such as a media access control (MAC) address and/or a universally unique identifier (UUID)).
Regarding claims 5, 10, and 15, Zarakas discloses the device of claim 1, the non-transitory computer-readable medium of claim 6, the method of claim 11,
wherein establishing the initial connection comprises providing confirmation to the accessory that the accessory is associated with the account (see Zarakas Abstract, A second device may request that a user log into an account associated with the first device (e.g., a customer account, a financial account, an employee account, and/or the like) in order to initiate a Bluetooth/BLE connection. A second device user may enter login credentials via the second device, which may then be transmitted to a backend system. A backend system may receive and validate the login credentials and, in response, transmit a public key to the second device. The public key may be transmitted in an encrypted format. A second device may receive the public key and may use the public key to perform a public/private key handshake in order to validate the first device. The handshake may then be validated by the first device and a Bluetooth and/or BLE connection may be created).
Regarding claim 6, Zarakas discloses a non-transitory computer-readable medium storing instructions, the instructions, when executed by one or more processors of a device, cause the one or more processors to:
“receive, when establishing an initial connection between the device and the accessory, an encrypted message transmitted by the accessory, wherein the encrypted message contains the public key and is encrypted using a private key” (see Zarakas pars. 0088-0095, At block 504, a backend system may generate a public/private key pair and may assign that public/private key pair to a particular account. A particular account may be associated with a first device (accessory). At block 506, the private key in the public/private key pair assigned to a particular account may be programmed into a first device associated with the particular account. A private key may be programmed into the microcontroller, and/or a secure element which may comprise a microprocessor, memory, and/or an applet in the first device. Memory may store at least one private key used to validate and/or create a Bluetooth and/or BLE connection with a second device (device). In block 508, a backend system may then receive a request from the second device for the public key associated with the account the user logged into. A backend system may validate the login credentials. At block 510, in response to receiving and validating the login credentials, the backend system may transmit the public key to the second device. The public key may be transmitted in an encrypted format. The second device may then encrypt a handshake and transmit this encrypted handshake to the first device in order to validate the first device);
decrypt the encrypted message to obtain a public key (see Zarakas par. 0094, The first device may attempt to decrypt this encrypted handshake using the private key securely stored in the first device. If the first device is successful at decrypting the handshake, the handshake will be verified and a Bluetooth and/or BLE connection may be created between the first and the second device using the data in the handshake);
“validate the public key” (see Zarakas par. 0097, A second device user may enter login credentials via the second device, which may then be transmitted to a backend system. A backend system may receive and validate the login credentials and, in response, transmit a public key to the second device. The public key may be transmitted in an encrypted format. A second device may receive the public key and may use the public key to encrypt a handshake that may be used to validate the first device and create the Bluetooth and/or BLE connection); and
“establish, after validating the public key, the initial connection between the device and the accessory via short-range wireless pairing” (see Zarakas par. 0013, a first device storing a private key may enter advertising mode to create a Bluetooth/BLE connection. An advertising packet (e.g., advertising PDU) may be transmitted (e.g., in encrypted format). A second device may enter scanning or initiator mode and may receive the advertising packet. A second device may request that a user log into an account associated with the first device (e.g., a customer account, a financial account, an employee account, and/or the like) in order to initiate a Bluetooth/BLE connection. A second device user may enter login credentials via the second device, which may then be transmitted to a backend system. A backend system may receive and validate the login credentials and, in response, transmit a public key to the second device. The public key may be transmitted in an encrypted format. A second device may receive the public key and may use the public key to perform a public/private key handshake in order to validate the first device. The handshake may then be validated by the first device).
Regarding claim 11, Zarakas discloses a method for pairing a device with an accessory, the method comprising:
receiving, by one or more processors of the device, when establishing an initial connection between the device and the accessory, an encrypted message transmitted by the accessory, wherein the encrypted message contains a public key and is encrypted using a private key; decrypt the encrypted message to obtain a public key (see Zarakas pars. 0088-0095, At block 504, a backend system may generate a public/private key pair and may assign that public/private key pair to a particular account. A particular account may be associated with a first device (accessory). At block 506, the private key in the public/private key pair assigned to a particular account may be programmed into a first device associated with the particular account. A private key may be programmed into the microcontroller, and/or a secure element which may comprise a microprocessor, memory, and/or an applet in the first device. Memory may store at least one private key used to validate and/or create a Bluetooth and/or BLE connection with a second device (device). In block 508, a backend system may then receive a request from the second device for the public key associated with the account the user logged into. A backend system may validate the login credentials. At block 510, in response to receiving and validating the login credentials, the backend system may transmit the public key to the second device. The public key may be transmitted in an encrypted format. The second device may then encrypt a handshake and transmit this encrypted handshake to the first device in order to validate the first device);
decrypting, by the one or more processors, the encrypted message to obtain a public key (see Zarakas par. 0094, The first device may attempt to decrypt this encrypted handshake using the private key securely stored in the first device. If the first device is successful at decrypting the handshake, the handshake will be verified and a Bluetooth and/or BLE connection may be created between the first and the second device using the data in the handshake);
“validating, by the one or more processors, the public key” (see Zarakas par. 0097, A second device user may enter login credentials via the second device, which may then be transmitted to a backend system. A backend system may receive and validate the login credentials and, in response, transmit a public key to the second device. The public key may be transmitted in an encrypted format. A second device may receive the public key and may use the public key to encrypt a handshake that may be used to validate the first device and create the Bluetooth and/or BLE connection); and
“establishing, by the one or more processors, after validating the public key, the initial connection between the device and the accessory via short-range wireless pairing” (see Zarakas par. 0013, a first device storing a private key may enter advertising mode to create a Bluetooth/BLE connection. An advertising packet (e.g., advertising PDU) may be transmitted (e.g., in encrypted format). A second device may enter scanning or initiator mode and may receive the advertising packet. A second device may request that a user log into an account associated with the first device (e.g., a customer account, a financial account, an employee account, and/or the like) in order to initiate a Bluetooth/BLE connection. A second device user may enter login credentials via the second device, which may then be transmitted to a backend system. A backend system may receive and validate the login credentials and, in response, transmit a public key to the second device. The public key may be transmitted in an encrypted format. A second device may receive the public key and may use the public key to perform a public/private key handshake in order to validate the first device. The handshake may then be validated by the first device).
Conclusion
6. Any inquiry concerning this communication or earlier communications from the examiner should be directed to SAMUEL AMBAYE whose telephone number is (571)270-7635. The examiner can normally be reached M-F 9:00 AM - 6:00 PM.
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, Jeffrey Pwu can be reached at (571) 272-6798. 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.
/SAMUEL AMBAYE/Examiner, Art Unit 2433
/JEFFREY C PWU/Supervisory Patent Examiner, Art Unit 2433