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 .
Response to Amendment / Arguments
Regarding claims rejected under 35 USC 112(b):
Applicant's arguments have been fully considered but they are not persuasive.
Applicant argues that the amended claim language “the claims the independent claims now specify how the GPI (containing the security credentials) is provided to server... As the device receives the wake-up message, including the GPI, the claims recite how both the device and the server obtain the key, which is used in place of certificate authentication.” In response, it is noted that the rejection in the 9/24/2025 Office action concerned the lack of clarity regarding “uses a certificate-based protocol” in combination with “used in place of certificate authentication.” It is unclear how to interpret the metes and bounds of the claim so as to understand how to avoid infringement because there is no detail about any particular “certificate-based protocol” and how it is being modified. The amended claim language merely further specifies obtaining the key rather than how the “certificate-based protocol” is changed. For example, if the “certificate-based protocol” requires certificate authentication, then using a key in lieu of certificate authentication would result in non-compliance with the protocol standard and, therefore, the channel would not be using a “certificate-based protocol” but, instead, being using a proprietary protocol that is likely not “certificate-based”. There is no per se “certificate” anywhere in the claim. Presumably, the “certificate-based protocol” requires “certificate authentication” because the subsequent limitation explicitly states the key is “used in place of” certificate authentication. In which case, the secure channel that is established within the claim is not using a “certificate-based” protocol, it would be a protocol that is “similar to some known certificate-based protocol” but differs at least insofar that it does not use certificates and instead uses keys. Ultimately, the limitation in question conflicts with itself and a competitor would not know how to avoid infringement due to the contradiction.
Regarding claims rejected under 35 USC 103:
Applicant’s arguments, in view of the amended claim language, have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made in view of Lehtovirta (US 20170055149 A1) and Enns (US 2012/0209951 A1).
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.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 27 and 31-46 are 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. Each of independent claims 27, 45, and 46 recite “wherein the secure communication channel uses a certificate-based protocol, and the obtained key is used in place of certificate authentication,” which renders the respective claims indefinite because it is not clear how to interpret “used in place of certificate authentication” when protocol is a “certificate-based protocol” that presumably requires or uses certificate authentication. The claims do not specify a modification of a certificate-based protocol (nor any specific protocol), so it is not clear how a protocol having typical certificate-based authentication would function without “certificate authentication” since the broadest reasonable interpretation for “certificate authentication” would include any use of a certificate during authentication (or at minimum, some interaction with a certificate in relation to the authentication). The instant specification generally refers to “no CA or certificate processing” being required, not needing to “exchange certificates with the server 40 or walk the CA chain,” and not needing “to be able to process or store security certificates.” However, this is more specific than the broadly claimed “certificate authentication” and doing these things would render the “protocol” as not being “certificate-based”.
Each of claims 27, 45, and 46 also recite “obtaining generic bootstrapping architecture (GBA) push information (GPI),” “wherein the GPI is obtained by the separate device in response to receiving the API instruction from the server,” and “wherein the GPI is obtained from a network application function (NAF), and wherein the NAF provides the GPI to the server.” These limitations render the respective claims indefinite because it is not clear these steps refer to the same GPI, the same obtaining, and/or the same element doing the obtaining. For instance, it is not clear whether “obtaining generic bootstrapping architecture (GBA) push information (GPI)” refers to the “separate device” obtaining the GPI, or to the server obtaining the GPI. In the case where the first limitation refers to the server obtaining the GPI, then “wherein the GPI is obtained by the separate device” appears to contradict the first limitation. Likewise, “wherein the NAF provides the GPI to the server” appears to contradict “wherein the GPI is obtained by the separate device.” Possible interpretations include obtaining different copies of the GPI and that the GPI is forwarded between the NAF and separate device to the server. However, a person of ordinary skill in the art could not interpret the metes and bounds of the claim so as to understand how to avoid infringement. Ultimately, without knowing which devices are required to do which steps, it is impossible to determine how to avoid infringement.
The dependent claims do not rectify this issue and are therefore likewise rejected.
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.
Claim(s) 27, 31-43 and 45-46 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bone (US 2017/0295143 A1) in view of Bone2 (GB 2518296 A), Lehtovirta (US 20170055149 A1), and Enns (US 2012/0209951 A1).
Regarding claim 27, Bone discloses: A method for communicating between a device (e.g., “managed device” in Bone) and a server (e.g., “device manager” in Bone, the method comprising the steps of:
the server initiating device wake-up;
Refer to at least [0016], [0019], [0028], [0357], and [0611] of Bone with respect to the device manager initiating a device wakeup message for the managed device (e.g., responsive to customer actions, device wakeup trigger conditions).
obtaining generic bootstrapping architecture (GBA) push information (GPI) including security credentials or information used to derive the security credentials;
Refer to at least [0020] and [0611]-[0612] of Bone with respect to GBA push information GPI and keys derived by GBA.
sending a device wake-up message to the device, wherein the device wake-up message includes the GPI;
Refer to at least [0022]-[0023] and [0611]-[0612] of Bone with respect to the wakeup message including the GPI.
authenticating the security credentials within the GPI to obtain a key; and
Refer to at least [0024] and [0613] of Bone with respect to confirming authenticity of the message using the GPI.
establishing a secure communication channel between the device and the server using the obtained key.
Refer to at least the abstract, [0026], [0007], and [0009]-[0014] of Bone with respect to establishing cryptographic material (e.g., a key or keys or a shared secret) to secure a second communication channel using the wakeup message information.
Bone does not specify: wherein the secure communication channel uses a certificate-based protocol, and the obtained key is used in place of certificate authentication; where the server initiates the device wake-up message by issuing an application programming interface (API) instruction to a separate device, wherein the GPI is obtained by the separate device in response to receiving the API instruction from the server; wherein the GPI is obtained from a network application function (NAF), and wherein the NAF provides the GPI to the server. However, Bone in view of Bone2 discloses: wherein the secure communication channel uses a certificate-based protocol (DTLS), and the obtained key is used in place of certificate authentication.
Refer to at least pg. 34, Ll. 24-pg. 35, Ll. 4 of Bone2 stating that “there is provided a method of retrieving security elements required for enabling secure data communication with a device, the communication being between a server and a client associated the device, wherein the security elements are retrieved using a bootstrapping protocol. The device can be an M2M device. The bootstrapping protocol may retrieve the security elements in a secure session. The session may be secured based on a security protocol. The security protocol may be a DTLS protocol. The bootstrapping protocol may be based on GBA. The data communication may be an SMS-based communication. The bootstrapping protocol may be a LWM2M bootstrap protocol.”
Refer to at least pg. 75, Ll. 20-24 of Bone2, which states that its “procedure has the advantages of reduced or no PKI, and no or easier certificate validation. A public key (protected by a key established using GBA) may be sent where the public key is then used to verify broadcast messages or firmware updates, for example.” Further see at least pg. 26, Ll. 30-pg. 27, Ll. 27 of Bone2.
The teachings of Bone and Bone2 both relate to establishing a secure communication channel using GBA, and are considered to be within the same field of endeavor and combinable as such. Further, Bone implements UDP as in [0014].
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Bone to further implement DTLS for the second communication protocol, where the wakeup message provides the security elements, because the substitution of one known element for another would have yielded predictable results to one of ordinary skill in the art at the time (i.e., which security protocol to use for the second communication channel, where DTLS is a known protocol for providing security to UDP). It would also have been obvious to one of ordinary skill in the art to implement no PKI and no certificate validation by using GBA for the reasons discussed in pg. 26, Ll. 30-pg. 27, Ll. 2 of Bone2 (i.e., simpler devices not having support for PKI and certificate handling).
Bone-Bone2 does not disclose: where the server initiates the device wake-up message by issuing an application programming interface (API) instruction to a separate device, wherein the GPI is obtained by the separate device in response to receiving the API instruction from the server; wherein the GPI is obtained from a network application function (NAF), and wherein the NAF provides the GPI to the server. However, Bone-Bone2 in view of Lehtovirta discloses: wherein the GPI is obtained by the separate device in response to receiving the API instruction from the server; wherein the GPI is obtained from a network application function (NAF), and wherein the NAF provides the GPI to the server.
Refer to at least FIG. 17 of Lehtovirta with respect to a relay 30n, BSF 50n, and PKMF 40n for providing GPI to a UE 20n. As per at least [0146] of Lehtovirta, the PKMF “acts as a NAF for the purposes of GBA Push.” The relay forwards the GPI to the UE after being fetched from the BSF and provided by the PKMF (e.g., FIG. 17 and [0371]-[0376] of Lehtovirta).
The teachings of Lehtovirta likewise concern GBA and establishing a secure communication channel, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Bone-Bone2 to further implement a relay for at least the purpose of extending coverage and bridging between private networks.
Bone-Bone2-Lehtovirta does not specify: where the server initiates the device wake-up message by issuing an application programming interface (API) instruction to a separate device. However, Bone-Bone2-Lehtovirta in view of Enns discloses: where the server initiates the device wake-up message by issuing an application programming interface (API) instruction to a separate device.
Refer to at least FIG. 4b and [0102] of Enns, which states that “Head End System's wakeup message uses the mobile operator's API call submitSMS(payload).”
The teachings of Enns likewise concern SMS wakeup messages, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Bone-Bone2-Lehtovirta to further implement an API during the message flow because the particular known technique (APIs) was recognized as part of the ordinary capabilities of one skilled in the art.
Regarding claim 31, it is rejected for substantially the same reasons as claim 27 above (e.g., [0013] and [0611] of Bone).
Regarding claim 32, Bone-Bone2-Lehtovirta-Enns discloses: The method of claim 27, further comprising the step of: in response to receiving the wake-up message, the device changes state before establishing the secure communication channel.
Refer to at least [0007] and [0015]-[0016] of Bone with respect to the managed device being in a dormant state until receiving the wakeup message.
Regarding claim 33, it is rejected for substantially the same reasons as claim 32 above (i.e., the citations concerning the dormant/low power state).
Regarding claim 34, Bone-Bone2-Lehtovirta-Enns discloses: The method of claim 27, wherein the step of authenticating the security credentials within the GPI to obtain the key further comprises the steps of the device authenticating the GPI with a bootstrapping sever function (BSF) and on successful authentication receiving the key from the BSF.
Refer to at least pg. 30, Ll. 18-21 and pg. 44, Ll. 1-26 of Bone2 with respect to a BSF and the BSF authenticating the GPI and providing a response.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Bone-Bone2 to further implement a BSF as part of GBA because the particular known technique was recognized as part of the ordinary capabilities of one skilled in the art.
Regarding claim 35, it is rejected for substantially the same reasons as claim 27 above (i.e., citations concerning the device manager of Bone—e.g., the abstract).
Regarding claim 36, Bone-Bone2-Lehtovirta-Enns discloses: The method of claim 27, wherein the wake-up message is initiated at predetermined intervals and/or on expiry of a previously obtained key.
Refer to at least pg. 38, Ll. 15-21 of Bone2 with respect to acquiring a shared secret using GBA responsive to expiration of an existing secret.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Bone-Bone2 to further implement secret expiration as a wakeup condition for at least the purpose of maintaining security by keeping keys fresh.
Regarding claim 37, it is rejected for substantially the same reasons as claim 27 above (e.g., [0028] and [0613] of Bone).
Regarding claim 38, it is rejected for substantially the same reasons as claims 32-33 and 37 above.
Regarding claim 39, Bone-Bone2-Lehtovirta-Enns discloses: The method of claim 27, wherein the wake-up message includes data indicating a wake-up delay.
Refer to at least [0122] and [0654] of Bone with respect to applying actions immediately or after a period of time.
Regarding claim 40, it is rejected for substantially the same reasons as claim 39 above.
Regarding claim 41, Bone-Bone2-Lehtovirta-Enns discloses: The method of claim 27, wherein the wake-up message includes data indicating a wake-up type of a plurality of wake-up types.
Refer to at least [0007], [0019], and [0357] of Bone with respect to, e.g., a request for firmware or a software update associated with the message.
Regarding claim 42, it is rejected for substantially the same reasons as claim 41 above.
Regarding claim 43, Bone-Bone2-Lehtovirta-Enns discloses: The method of claim 27, wherein the step of establishing the secure communication channel between the device and the server further comprises providing the server with an identifier of the device.
Refer to at least pg. 25, Ll. 19-26 of Bone2 concerning an identifier provided to the server by the client, where the identifier is associated with obtaining the shared secret.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Bone-Bone2 to further implement a device identifier for at least the purpose of improving security by helping to better detect fraud and counterfeiting. Additionally, the particular known technique was recognized as part of the ordinary capabilities of one skilled in the art.
Regarding independent claim 45, it is substantially similar to independent claim 27 above, and is therefore likewise rejected (i.e., the citations and obviousness rationale).
Regarding independent claim 46, it is substantially similar to independent claim 27 above, and is therefore likewise rejected (i.e., the citations and obviousness rationale).
Claim(s) 44 is/are rejected under 35 U.S.C. 103 as being unpatentable over Bone-Bone2-Lehtovirta-Enns as applied to claims 27, 31-43 and 45-46 above, and further in view of Gan (US 2019/0261272 A1).
Regarding claim 44, Bone-Bone2-Lehtovirta-Enns does not disclose: wherein the wake-up message is resent to the device, or a new wake-up message is sent to the device if the device fails to respond within a predetermined time, wherein the message is associated with a timestamp, the method further comprising the step of triggering the wake-up message to be resent or a new wake-up message to be sent to the device if the server does not have a record of the establishment of the secure communication within the predetermined time from the timestamp. However, Bone-Bone2-Lehtovirta-Enns in view of Gan discloses: wherein the wake-up message is resent to the device, or a new wake-up message is sent to the device if the device fails to respond within a predetermined time, wherein the message is associated with a timestamp, the method further comprising the step of triggering the wake-up message to be resent or a new wake-up message to be sent to the device if the server does not have a record of the establishment of the secure communication within the predetermined time from the timestamp.
Refer to at least [0004] and [0086] of Gan with respect to a “wake-up frame” which “may carry wake-up signaling, and the wake-up signaling may include a timestamp… If the wake-up frame is not correctly received by the wake-up receiver, the other device needs to retransmit the wake-up frame to the wake-up receiver.”
The teachings of Gan likewise concern a wakeup message, and are considered to be within the same field of endeavor and combinable as such.
Therefore it would have been obvious to one of ordinary skill in the art before the filing date of Applicant’s invention to modify the teachings of Bone-Bone2-Lehtovirta-Enns to further implement a wake-up signaling including a timestamp, as well as retransmission after a given time for at least the purpose of preventing transmission failure and reducing the number of transmissions (i.e., retransmit after a time).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 VADIM SAVENKOV whose telephone number is (571)270-5751. The examiner can normally be reached 12PM-8PM.
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 L Nickerson can be reached at (469) 295-9235. 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.
/Jeffrey Nickerson/Supervisory Patent Examiner, Art Unit 2432
/V.S/Examiner, Art Unit 2432
Prosecution Insights