DETAILED ACTION
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 .
The claim set, file on 1/17/2025, is acknowledged and considered.
Claims 1-20 are pending. Claims 1, 15, and 18 are independent.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 3/19/2025, 6/26/2025, 7/30/2025, 10/9/2025 was filed after the mailing date of the Claims on 1/17/2025. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
4. Claims 18-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter. The claim(s) does/do not fall within at least one of the four categories of patent eligible subject matter because:
Specification discloses accessory objects storage element can be implemented using volatile or nonvolatile storage media [para 0509, 0527]. Other parts of the specification discusses computer-readable media [para 0484, 0493, 0546]. However, the computer-readable media from the specification fails to explicitly define as non-transitory computer-readable media or that computer-readable media to exclude transitory signals. Thus, the “computer-readable storage medium” of claims 18-20, encompasses signals per se.
Specification
5. The disclosure is objected to because of the following informalities:
The specification includes grammatical and other typos that should be addressed. Some examples of the miscellaneous typos are incomplete words or have numbers attached to the term, i.e. secu, processor25,combination30 [para 222]. Applicant is suggested to go through the specification and make the necessary corrections.
Appropriate correction is required.
Allowable Subject Matter
6. Claim 5 is 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.
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.
7. Claim(s) 1-4 and 6-20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bai, et al. [US 20140079217] in view of Maski [US 20150139044].
As per claim 1: Bai, et al. teaches a method of performing a pair add process, comprising:
establishing, by a first controller device, a shared secret and a session key with an accessory device; [Bai: para 0007; The vehicle (i.e. first controller) uses its secure OnStar cellular communication link to verify the mobile device (i.e. accessory device) with the OnStar server, which generates a session key. The session key serves as a shared secret, such that the vehicle can issue a secrecy challenge to the mobile device. See also para 0039]
receiving, by the first controller device, a first key from a second controller device; [Bai: para 0033; The device (i.e. second controller) first generates an ephemeral pair of private/public keys (EPvD,EPuD). The device creates a message m2 which is a concatenation of the device's ephemeral public key EPuD. The device creates a signature SG2 using its static private key SPvD on the message m2, and sends the message m2 concatenated with the signature SG2 to the OnStar server. Another example on para 0040]
generating, by the first controller device, a data block that includes the first key and an indication that the data block corresponds to a request to add a pairing; [Bai: para 0021-0022; The pairing request includes a message, where a device verification message consists of a string n and a signature SG. The string n is composed of a concatenation of four items received in the pairing request message. The string n is a unique string which identifies the two entities which wish to be paired, along with a counter number and timestamp. The signature SG is generated by a signature generation algorithm using the private key of the vehicle on the string n. Thus, the data block with the key and the indication corresponds to the request may be referring to the message with signature SG generated by the private key of the vehicle on the string n, associated with the pairing request]
transmitting, by the first controller device, a request to begin the pair add process, the request including the data block; [Bai: para 0022; The device verification message consists of a string n and a signature SG. The string n is composed of a concatenation of four items; the device address of the vehicle, ADDR_V, which is known to the vehicle; the device address of the mobile device, ADDR_D, which was received in the pairing request message]
receiving, from the accessory device, a response to the request, the response including a second key; [Bai: para 0041; the device generates an ephemeral pair of private/public keys and creates a message m2 consisting of the ephemeral public key of the device. The device signs the message m2 with its own static private key, creating a signature SG2, and sends to the OnStar server the message m2 concatenated with the signature SG2]
determining, by the first controller device, whether the response indicates success of the pair add process; and [Bai: para 0046; notify the primary device of the guest device's request and to allow the primary device to grant (or deny) the request]
in accordance with a determination that the response indicates success of the pair add process: [Bai: para 0046; to allow the primary device to grant (or deny) the request]
**transmitting, by the first controller device, a notification to the second controller device, the notification indicating the success of the pair add process. [**rejected under the secondary reference, discussion below]
Bai teaches to notify the primary device of the guest device's request and to allow the primary device to grant (or deny) the request [Bai: para 0046]. However, Bai does not clearly teach “transmitting, by the first controller device, a notification to the second controller device, the notification indicating the success of the pair add process”.
Maski discusses the present disclosure provides a method, computer-readable storage device, and an apparatus for enabling a mobile endpoint device to be a hub for a conference call. The method connects to the conference call, broadcasts a signal to at least one slave mobile endpoint devices to join the conference call over a personal area network, receives a pairing request from the at least one slave mobile endpoint device over the personal area network, accepts the pairing request and connects the at least one slave mobile endpoint device to the conference call via the master mobile endpoint device over the personal area network, wherein both the master mobile endpoint device and the at least one slave mobile endpoint device have two-way communications with the conference call and conference call controls [Maski: para 0003]. Art discloses the slave mobile endpoint device may initiate the pairing by sending a pairing request to the master mobile endpoint device. There includes an audible tone to provide a notification to a user of the slave mobile endpoint device confirming that the pairing request was sent successfully and that the master mobile endpoint device has received the pairing request [Maski: para 0048-0049]. As such, one would be motivated for “transmitting, by the first controller device, a notification to the second controller device, the notification indicating the success of the pair add process”, would be to determine if the pairing request is accepted and to confirm the pairing request.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Maski with Bai to teach "claim" for the reason to determine the pairing request is accepted by confirming that the pairing request was sent successfully [Maski: para 0049].
Claim 2: Bai: para 0007, 0028; discussing the method of claim 1, further comprising performing, by the controller device, a pair setup process with the accessory device prior to establishing the shared secret and the session key.
Claim 3: Bai: para 0019, 0021; discussing the method of claim 1, further comprising establishing the controller device as an administrator of the accessory device prior to establishing the shared secret and the session key.
Claim 4: Bai: para 0026 in view of Maski: para 0025 [suggesting “during a previous pair add process”, under the same pretext and motivation as in claim 1]; discussing the method of claim 3, wherein the controller device was established as an administrator during a previous pair add process.
Claim 5: Objected
Claim 6: Bai: claim 10; discussing the method of claim 1, wherein the data block further includes permissions information indicating permissions to be granted to the second controller device.
Claim 7: Bai: 0046, claim 10; discussing the method of claim 6, wherein the permissions information further indicates that the second controller device is to be designated as an administrator of the accessory device.
Claim 8: Bai: para 0029; discussing the method of claim 1, wherein the data block further includes a controller identifier of the second controller device.
Claim 9: Bai: para 0025; discussing the method of claim 1, wherein the request is encrypted using the session key.
Claim 10: Bai: para 0046; discussing the method of claim 1, wherein the request includes a state indicator for identifying the request.
Claim 11: Bai: para 0039; discussing the method of claim 1, wherein the first key comprises a long-term public key of the second controller device.
Claim 12: Bai: para 0039; discussing the method of claim 1, wherein the second key comprises a long-term public key of the accessory device.
Claim 13: Bai: para 0033; discussing the method of claim 1, wherein the notification includes an identifier of the accessory device and the second key.
Claim 14: Bai: para 0035; discussing the method of claim 12, wherein the second controller device is configured to perform a pair verify process with the accessory device using the second key.
As per claim 15: Bai, et al. teaches a first controller device configured to perform a pair add process, comprising:
a communication interface to communicate with an accessory device; and [Bai: para 0015]
a processing subsystem coupled to the communication interface [Bai: para 0017], the processing subsystem configured to:
establish a shared secret and a session key with an accessory device; [Bai: para 0007; The vehicle (i.e. first controller) uses its secure OnStar cellular communication link to verify the mobile device (i.e. accessory device) with the OnStar server, which generates a session key. The session key serves as a shared secret, such that the vehicle can issue a secrecy challenge to the mobile device. See also para 0039]
receiving a first key from a second controller device; [Bai: para 0033; The device (i.e. second controller) first generates an ephemeral pair of private/public keys (EPvD,EPuD). The device creates a message m2 which is a concatenation of the device's ephemeral public key EPuD. The device creates a signature SG2 using its static private key SPvD on the message m2, and sends the message m2 concatenated with the signature SG2 to the OnStar server. Another example on para 0040]
generating a data block that includes the first key and an indication that the data block corresponds to a request to add a pairing; [Bai: para 0021-0022; The pairing request includes a message, where a device verification message consists of a string n and a signature SG. The string n is composed of a concatenation of four items received in the pairing request message. The string n is a unique string which identifies the two entities which wish to be paired, along with a counter number and timestamp. The signature SG is generated by a signature generation algorithm using the private key of the vehicle on the string n. Thus, the data block with the key and the indication corresponds to the request may be referring to the message with signature SG generated by the private key of the vehicle on the string n, associated with the pairing request]
transmit a request to begin the pair add process, the request including the data block; [Bai: para 0022; The device verification message consists of a string n and a signature SG. The string n is composed of a concatenation of four items; the device address of the vehicle, ADDR_V, which is known to the vehicle; the device address of the mobile device, ADDR_D, which was received in the pairing request message]
receive, from the accessory device, a response to the request, the response including a second key; [Bai: para 0041; the device generates an ephemeral pair of private/public keys and creates a message m2 consisting of the ephemeral public key of the device. The device signs the message m2 with its own static private key, creating a signature SG2, and sends to the OnStar server the message m2 concatenated with the signature SG2]
determine whether the response indicates success of the pair add process; and [Bai: para 0046; notify the primary device of the guest device's request and to allow the primary device to grant (or deny) the request]
in accordance with a determination that the response indicates success of the pair add process: [Bai: para 0046; to allow the primary device to grant (or deny) the request]
**transmit a notification to the second controller device, the notification indicating the success of the pair add process. [**rejected under the secondary reference, discussion below]
Bai teaches to notify the primary device of the guest device's request and to allow the primary device to grant (or deny) the request [Bai: para 0046]. However, Bai does not clearly teach “transmit a notification to the second controller device, the notification indicating the success of the pair add process”.
Maski discusses the present disclosure provides a method, computer-readable storage device, and an apparatus for enabling a mobile endpoint device to be a hub for a conference call. The method connects to the conference call, broadcasts a signal to at least one slave mobile endpoint devices to join the conference call over a personal area network, receives a pairing request from the at least one slave mobile endpoint device over the personal area network, accepts the pairing request and connects the at least one slave mobile endpoint device to the conference call via the master mobile endpoint device over the personal area network, wherein both the master mobile endpoint device and the at least one slave mobile endpoint device have two-way communications with the conference call and conference call controls [Maski: para 0003]. Art discloses the slave mobile endpoint device may initiate the pairing by sending a pairing request to the master mobile endpoint device. There includes an audible tone to provide a notification to a user of the slave mobile endpoint device confirming that the pairing request was sent successfully and that the master mobile endpoint device has received the pairing request [Maski: para 0048-0049]. As such, one would be motivated for “transmit a notification to the second controller device, the notification indicating the success of the pair add process”, would be to determine if the pairing request is accepted and to confirm the pairing request.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Maski with Bai to teach “transmit a notification to the second controller device, the notification indicating the success of the pair add process” for the reason to determine the pairing request is accepted by confirming that the pairing request was sent successfully [Maski: para 0049].
Claim 16: Bai: para 0007, 0028; discussing the first controller device of claim 15, wherein the shared secret and the session key are established based at least in part on a pair setup process between the first controller device and the accessory device.
Claim 17: Bai: para 0046, claim 10; discussing the first controller device of claim 15, wherein the data block further includes permissions information indicating permissions to be granted to the second controller device.
As per claim 18: Bai, et al. teaches a computer-readable storage medium, storing computer-executable instructions that, when executed by a processor of a first controller device configured to perform a pair add process, configure the processor to perform operations comprising:
establishing a shared secret and a session key with an accessory device; [Bai: para 0007; The vehicle (i.e. first controller) uses its secure OnStar cellular communication link to verify the mobile device (i.e. accessory device) with the OnStar server, which generates a session key. The session key serves as a shared secret, such that the vehicle can issue a secrecy challenge to the mobile device. See also para 0039]
receiving a first key from a second controller device; [Bai: para 0033; The device (i.e. second controller) first generates an ephemeral pair of private/public keys (EPvD,EPuD). The device creates a message m2 which is a concatenation of the device's ephemeral public key EPuD. The device creates a signature SG2 using its static private key SPvD on the message m2, and sends the message m2 concatenated with the signature SG2 to the OnStar server. Another example on para 0040]
generating a data block that includes the first key and an indication that the data block corresponds to a request to add a pairing; [Bai: para 0021-0022; The pairing request includes a message, where a device verification message consists of a string n and a signature SG. The string n is composed of a concatenation of four items received in the pairing request message. The string n is a unique string which identifies the two entities which wish to be paired, along with a counter number and timestamp. The signature SG is generated by a signature generation algorithm using the private key of the vehicle on the string n. Thus, the data block with the key and the indication corresponds to the request may be referring to the message with signature SG generated by the private key of the vehicle on the string n, associated with the pairing request]
transmitting a request to begin the pair add process, the request including the data block; [Bai: para 0022; The device verification message consists of a string n and a signature SG. The string n is composed of a concatenation of four items; the device address of the vehicle, ADDR_V, which is known to the vehicle; the device address of the mobile device, ADDR_D, which was received in the pairing request message]
receiving, from the accessory device, a response to the request, the response including a second key; [Bai: para 0041; the device generates an ephemeral pair of private/public keys and creates a message m2 consisting of the ephemeral public key of the device. The device signs the message m2 with its own static private key, creating a signature SG2, and sends to the OnStar server the message m2 concatenated with the signature SG2]
determining whether the response indicates success of the pair add process; and [Bai: para 0046; notify the primary device of the guest device's request and to allow the primary device to grant (or deny) the request]
in accordance with a determination that the response indicates success of the pair add process: [Bai: para 0046; to allow the primary device to grant (or deny) the request]
**transmitting a notification to the second controller device, the notification indicating the success of the pair add process. [**rejected under the secondary reference, discussion below]
Bai teaches to notify the primary device of the guest device's request and to allow the primary device to grant (or deny) the request [Bai: para 0046]. However, Bai does not clearly teach “transmitting a notification to the second controller device, the notification indicating the success of the pair add process”.
Maski discusses the present disclosure provides a method, computer-readable storage device, and an apparatus for enabling a mobile endpoint device to be a hub for a conference call. The method connects to the conference call, broadcasts a signal to at least one slave mobile endpoint devices to join the conference call over a personal area network, receives a pairing request from the at least one slave mobile endpoint device over the personal area network, accepts the pairing request and connects the at least one slave mobile endpoint device to the conference call via the master mobile endpoint device over the personal area network, wherein both the master mobile endpoint device and the at least one slave mobile endpoint device have two-way communications with the conference call and conference call controls [Maski: para 0003]. Art discloses the slave mobile endpoint device may initiate the pairing by sending a pairing request to the master mobile endpoint device. There includes an audible tone to provide a notification to a user of the slave mobile endpoint device confirming that the pairing request was sent successfully and that the master mobile endpoint device has received the pairing request [Maski: para 0048-0049]. As such, one would be motivated for “transmitting a notification to the second controller device, the notification indicating the success of the pair add process”, would be to determine if the pairing request is accepted and to confirm the pairing request.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine Maski with Bai to teach “transmitting a notification to the second controller device, the notification indicating the success of the pair add process” for the reason to determine the pairing request is accepted by confirming that the pairing request was sent successfully [Maski: para 0049].
Claim 19: Bai: 0046, claim 10; discussing the computer-readable storage medium of claim 18, wherein the data block further includes permissions information indicating permissions to be granted to the second controller device.
Claim 20: Bai: para 0039; discussing the computer-readable storage medium of claim 16, wherein the first key comprises a long-term public key of the second controller device, and wherein the second key comprises a long-term public key of the accessory device.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Leynna Truvan whose telephone number is (571)272-3851. The examiner can normally be reached Monday-Friday 9:00AM-5:00PM, EST.
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, Amir Mehrmanesh can be reached at 571-270-3351. 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.
Leynna Truvan
Examiner
Art Unit 2435
/L.TT/Examiner, Art Unit 2435
/EDWARD ZEE/Primary Examiner, Art Unit 2435
Prosecution Insights