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
The amendment filed on 12/12/2025 has been entered. Claims 1, 11 and 21 have been amended. Claims 1-15 and 17-21 are pending and are examined herein.
Response to Amendment
Applicant’s arguments, see Applicant Arguments/Remarks, filed on 12/12/2025, with respect to the rejection of the pending claims under 35 U.S.C. §103 have been fully considered but they are not persuasive.
Applicant argues that Wang does not teach or suggest "a device-side authentication-initiation message containing a unique device identifier of the IoT device and excluding a list of one or more cryptographic security protocols supported by the IoT device," as called for in Applicant's amended Claim 1. (Arg./Rem. page 7)
Examiner agrees that Wang does not teach the limitation, because Examiner relied on Holden to teach this limitation.
Applicant further argues that Wang cannot be modified by Holden or any other reference for teaching the limitation, because doing so would improperly change the principle of operation of Wang, which explicitly requires that the ClientHello 1101 include parameters regarding one or more supported protocols, such as messaging and transport protocols, or combinations thereof, that the client 1110 supports. (Arg./Rem. page 8)
Examiner respectfully disagrees. The modification of Wang does not alter the fundamental operation, but merely substitutes the protocol list input of Wang with identifier-based protocol lookup as taught by Holden. Per MPEP §2143(I)(B): substitution of one known element for another to obtain predictable results is obvious and Per MPEP §2143(I)(C): use of a known technique to improve similar systems is obvious. Accordingly, no impermissible change in principle of operation occurs.
Applicant further argues that Wang can also not be modified by Holden for additional reasons. For example, the type of table 810 described in Holden, which lists application protocol names associated with an identifier of one or more applications, would be wholly unnecessary in Wang because Wang's ClientHello 1101 already includes parameters regarding one or more supported protocols. A person of ordinary skill in the art would not be led to modify the method of Wang to include superfluous features, such as the table 810 of Holden. (Arg./Rem. page 8)
Examiner respectfully disagrees. Wang discloses protocol lists as part of one embodiment. Wang does not teach that omission renders the system inoperable. Prior art is not limited to its preferred embodiments, (MPEP §2121). A person of ordinary skill in the art would recognize that protocol lists may be omitted where protocol selection is performed using device identification as taught by Holden. The modification does not add Holden’s table in addition to Wang’s protocol list instead replaces the protocol list with a known alternative mechanism. The table serves the same function of determining an appropriate protocol. Use of a known alternative is obvious even if it replaces an existing element (MPEP §2144.04). The use of a lookup table reduces ClientHello size, eliminates need for negotiation, improves efficiency for constrained devices. Therefore, the table is not superfluous, but a functionally advantageous alternative.
Therefore, the Examiner is not persuaded by the applicant’s arguments and concluded that the combined teachings of Wang and Holden disclose the claimed limitation.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 1, 11 and 21 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention. Claims 1, 11 and 21 recite “receiving, from an Internet of Things (IoT) device, a device-side authentication-initiation message containing a unique device identifier of the IoT device and excluding a list of one or more cryptographic security protocols supported by the IoT device;” (emphasis added).
Applicant asserts that this limitation is supported by paragraph [0014] of the specification, which discloses: “…not sending lists of cryptographic security protocols back and forth between server and client as part of such handshaking, negotiation, and/or the like,…”.
However, paragraph [0014] does not reasonably convey that the inventor had possession of a system in which: the device-side authentication-initiation message itself excludes a list of supported cryptographic security protocols. Instead, paragraph [0014] generally refers to reducing or avoiding back and forth exchange of protocol lists during a handshake, and does not specifically describe the content of the initial device-side message, nor does it clearly state that such a message omits protocol capability information.
In contrast, paragraphs 0031-0032 of Applicant’s specification explicitly disclose that the device-side authentication-initiation message (i.e., a client-hello message) includes a list of supported cryptographic protocols. [¶ 0031] discloses that the IoT device transmits a client-hello message to initiate communication. [¶ 0032] further explains that the TLS ALPN extension includes a “ProtocolNameList” parameter, which directs the client device to include: “a list of cryptographic security protocols of which the IoT device is capable of communicating, prefers to communicate, and/or the like” (emphasis added).
Thus, the specification affirmatively teaches that the device-side authentication-initiation message includes, rather than excludes, a list of supported cryptographic security protocols.
Further, claim 2 recites: “the device-side authentication-initiation message comprises a client-hello message according to a Transport Layer Security (TLS) Application-Layer Protocol Negotiation (APLN) extension;…”.
It is well-established that, according to RFC 7301 (ALPN), a TLS ClientHello message implementing ALPN includes a list of supported application protocols (i.e., the ProtocolNameList). Accordingly, the specification’s disclosure of ALPN-based ClientHello messages is consistent with inclusion of such protocol lists, and does not support the exclusion recited in claim 1.
Since, the cited portion of the specification [¶ 0014] does not describe the claimed exclusion of protocol lists from the device-side authentication-initiation message; and other portions of the specification [¶ 0031–0032] explicitly disclose inclusion of such protocol lists in the ClientHello message. Thus, claims 1, 11 and 21 fail to comply with the written description requirement.
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.
Claims 1, 3-5, 7, 9-10, 11, 13-14, 17 and 19-21 are rejected under 35 U.S.C. 103 as being unpatentable over US 2018/0007172 (Wang et al.) in view of US 2016/0036949 (Holden et al.).
Regarding Claim 1, Wang teaches a method performed by a computer system executing stored instructions on at least one hardware processor ([Fig 19, 0116-0117] the node 30 may include a processor 32, … the processor 32 may execute computer-executable instructions stored in the memory (e.g., memory 44 and/or memory 46) of the node in order to perform the various required functions of the node), the method comprising: receiving, from an Internet of Things (IoT) device, a device-side authentication-initiation message… ([Fig. 11, ¶ 0078], the IoT entity 1110 is a Transport Layer Security/Datagram Transport Layer Security (TLS/DTLS) client, such as a network application. The IoT entity 1120 is a TLS/DTLS server. The client 1110 begins the dialogue by sending a ClientHello 1101 message to the server 1120. The ClientHello 1101 includes parameters); identify, …a suitable cryptographic security protocol for the IoT device ([¶ 0078], the server 1120 selects appropriate protocols in accordance with which message and transport protocols are supported by both client 1110 and server 1120. Note: the selection includes message and transport protocols (e.g., TLS/DTLS) which is cryptographic or security-relevant protocols in the context of TLS/DTLS); transmitting, to the IoT device, a server-side authentication-initiation message containing an indication of the identified protocol ([¶ 0078], The server 1120 then sends a ServerHello message 1102 to the client 1110 with a parameter indicating the selected messaging and/or transport protocol); and authenticating the IoT device according to the identified protocol ([¶ 0078], Thereafter the client 1110 may begin data transmission using the selected messaging protocol and corresponding transport protocol, which in TLS/DTLS includes authentication).
Wang does not explicitly teach, however, Holden teaches a device-side authentication-initiation message containing a unique device identifier of the IoT device and excluding a list of one or more cryptographic security protocols supported by the IoT device; using the unique device identifier of the IoT device to identify, from a stored power- efficiency reference table, a suitable protocol for the IoT device (emphasis added) ([¶ 0125] …the accessory [i.e., IoT device] can identify itself by sending identification information. The identification information can be used by the mobile computing device to select an appropriate application communication protocol, for example, by referencing table 810. …the mobile computing device can send accessory identifying information to an application store and/or a server through the Internet to identify an application communication protocol compatible with the accessory. … the accessory may not send application protocol information to the mobile computing device, rather the accessory can send accessory identification information that is then used by the mobile computing device to choose the proper application communication protocol).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to modify Wang’s device-side initiation message to include only a unique device identifier (and not send a list of supported protocols) and to determine a suitable cryptographic protocol using a stored reference table as taught by Holden in order to improve protocol selection efficiency and reduce device side complexity.
Regarding Claim 3, Wang does not explicitly teach, however, Holden teaches the method of claim 1, wherein, for each IoT device in a plurality of IoT devices, the power-efficiency reference table comprises a unique device identifier of the corresponding IoT device and at least one suitable cryptographic security protocol for the corresponding IoT device ([¶ 0079], provide accessory information lookup table. The accessory information table can include information about each connected accessory such as accessory type, accessory identifier, and/or the name(s) of one or more application protocols supported by the accessory).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Holden's accessory information table to the teachings of Wang because such incorporation would have an predictable variation of using a reference table to find information quickly and efficiently.
Regarding Claim 4, Wang does not explicitly teach, however, Holden teaches the method of claim 3, wherein, for each IoT device in the plurality of IoT devices, the power-efficiency reference table comprises exactly one suitable cryptographic security protocol for the corresponding IoT device ([¶ 0079], provide accessory information lookup table. The accessory information table can include information about each connected accessory such as accessory type, accessory identifier, and/or the name(s) of one or more application protocols supported by the accessory).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Holden's accessory information table to the teachings of Wang because such incorporation would have an predictable variation of using a reference table to find information quickly and efficiently.
Regarding Claim 5, Wang does not explicitly teach, however, Holden teaches the method of claim 3, wherein, for at least one IoT device in the plurality of IoT devices, the power-efficiency reference table comprises multiple suitable cryptographic security protocols for the corresponding IoT device ([¶ 0079], provide accessory information lookup table. The accessory information table can include information about each connected accessory such as accessory type, accessory identifier, and/or the name(s) of one or more application protocols supported by the accessory).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Holden's accessory information table to the teachings of Wang because such incorporation would have an predictable variation of using a reference table to find information quickly and efficiently.
Regarding Claim 7, Wang does not explicitly teach, however, Holden teaches the method of claim 1, wherein the power-efficiency reference table is indexed at least by unique device identifiers of IoT devices listed in the power-efficiency reference table ([¶ 0079], provide accessory information lookup table. The accessory information table can include information about each connected accessory such as accessory type, accessory identifier, and/or the name(s) of one or more application protocols supported by the accessory. [¶ 0081] An executing application can query accessory information table at any time to determine whether a compatible accessory (i.e., an accessory that supports an application protocol used by the application) is connected).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Holden's accessory information table to the teachings of Wang because such incorporation would have an predictable variation of using a reference table to find information quickly and efficiently.
Regarding Claim 9, Wang teaches the method of claim 1, further comprising engaging in a communication session with the IoT device according to the identified protocol ([¶ 0078], Thereafter the client 1110 may begin data transmission using the selected messaging protocol and corresponding transport protocol).
Regarding Claim 10, Wang teaches the method of claim 3, further comprising: receiving an update message pertaining to a given IoT device in the plurality of IoT devices, the update message comprising a second indication of a second cryptographic security protocol, the second cryptographic security protocol being different than a first cryptographic security protocol of which a first indication is currently listed in the power- efficiency reference table in connection with the given IoT device; and responsively replacing the first indication of the first cryptographic security protocol with the second indication of the second cryptographic security protocol in connection with the given IoT device ([¶¶ 0034-0038], An IoT entity may wish to change the messaging and/or transport protocols it is using for various reasons. Such reasons could include, for instance: the power or computing resources available to the entity; the nature of the connection or network segment over which the communications are made; and/or the nature of the content. For example, a solar-powered apparatus may have enough power during daylight hours to support HTTP. At night, when the device is running on a reserve battery, in may be better to consume less power by using CoAP. Similarly, an IoT entity may prefer to use different messaging protocols as they are fitting for different resource requirements. Such resources have different requirements for messaging protocols to access them efficiently. For example, CoAP may be better for accessing the general sensor readings, HTTP may be better for video streaming, and MQTT may be better for Pub/Sub data. An IoT entity using CoAP messaging may wish to use different transport mechanisms at different times and/or for different purposes. A constrained resource IoT Device supports CoAP over UDP to achieve better energy efficiency, while an IoT Device generates continuous traffic and uses CoAP over TCP to provide better reliability and flow control features. An IoT Device supports CoAP over TCP when it has stable connectivity to Internet, but changes to CoAP over UDP when it physically moves. An IoT entity using CoAP may wish to use different CoAP protocol features based on content-related requirements).
Regarding Claim 11, the claim limitations are identical and/or equivalent in scope to claim 1, therefore, Claim 11 is rejected under the same rationale as Claim 1. Examiner further notes, Wang also teaches a computer system comprising: at least one hardware processor; and one or more non-transitory computer-readable storage media containing instructions (See, Fig 19, ¶¶ 0116-0117]).
Regarding Claims 13, 14, 17, 19 and 20 the claim limitations are identical and/or equivalent in scope to claims 3, 4, 7, 9 and 10, respectively, therefore, Claims 13, 14, 17, 19 and 20 are rejected under the same rationale as claims 3, 4, 7, 9 and 10.
Regarding Claim 21, the claim limitations are identical and/or equivalent in scope to claim 1, therefore, Claim 11 is rejected under the same rationale as Claim 1. Examiner further notes, Wang also teaches one or more non-transitory computer-readable storage media containing instructions that, when executed by at least one hardware processor of a computer system (See, Fig 19, ¶¶ 0116-0117 and 0133]).
Claims 2 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Wang and Holden, and further in view of US 2018/0241730 (Clere et al.).
Regarding Claim 2, Wang teaches the method of claim 1, wherein: the device-side authentication-initiation message comprises a client-hello message according to a Transport Layer Security (TLS) Application-Layer Protocol Negotiation (APLN) extension; and the server-side authentication-initiation message comprises a server-hello message according to the TLS APLN extension ([Fig. 11, ¶ 0078] FIG. 11 illustrates an example of how a PIN dialogue 1100 may be implemented as an extension to the Transport Layer Security/Datagram Transport Layer Security (TLS/DTLS) protocol. In this example, the IoT entity 1110 is a TLS/DTLS client, such as a network application. The IoT entity 1120 is a TLS/DTLS server, such as a IoT device. The client 1110 begins the dialogue by sending a ClientHello 1101 to the server 1120. The server 1120 then sends a ServerHello message 1102 to the client 1110).
While, Wang teaches a TSL/DTLS extension, however, Wang in view of Holden do not teach, but Clere teaches a Transport Layer Security (TLS) Application-Layer Protocol Negotiation (APLN) extension ([¶ 0014], client devices may support certain secure layer extensions of a particular SSL/TLS protocol version that is not supported by a server device. In such cases, the request to establish a secure connection between the devices may be unable to use particular features of the new version of the web browser. For example, during handshaking process, the client device may indicate that it is using a new version of a certain protocol, and/or a particular version of that protocol. For example, the secure layer extensions may include an application-layer protocol negotiation (APLN) extension. The APLN allows the application layer to negotiate which protocol should be performed over a secure connection in a manner which avoids additional round trips between the devices).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Clere's APLN extension into Wang’s TLS/DTLS handshake message in order to use a standardized, widely-supported mechanism for negotiation application layer protocol, because such incorporation would yield predictable results and improve interoperability with existing TLS implementation and performance by eliminating extra round-trips between device (see, Clere, ¶ 0014).
Regarding Claim 12, the claim limitations are identical and/or equivalent in scope to claim 2, therefore, Claim 12 is rejected under the same rationale as Claim 2.
Claims 6, 8, 15 and 18 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Wang and Holden, and further in view of US 2019/0036910 (Choyi et al.).
Regarding Claim 6, Wang in view of Holden do not explicitly teach, however, Choyi teaches the method of claim 5, wherein the multiple suitable cryptographic security protocols in the power-efficiency reference table for at least one IoT device in the plurality of IoT devices are arranged in a priority order for the computer system to use in attempting to authenticate the corresponding IoT device ([¶ 0003] A Service Enablement and Security Configuration (SESC) method is described. This involves identifying the right set of security features, associated attributes and parameters that may be used by an entity within a M2M network in order that secure communications may be established. The steps entail identifying the capability of an entity and the services offered by the entity and making a determination of the security features. [¶¶ 0094-0099], Entity A requests SESC process to be initiated with a Service Enablement Function (SEF). As part of the message, Entity A provides its device type, unique Device ID (DID) or capability or both and also provides a list of services/application the entity provides. the SEF on receiving the request makes a determination of a list of security features/attribute(s) and associated parameter(s) that may be appropriate for Entity A based on its capabilities. Then, based on the type of service/application the Entity A provides, the SEF may select a narrow list of security features and associated attributes and parameters. The SEF may create a priority list of features that may be used by Entity A. Response message from the SEF that includes the security features and associated attribute and parameter along with policies. [¶ 0100], it is pre-configured with the appropriate security attributes and parameters. Table 2 Example list of security requirements. [¶ 0102], The SEF has a complete profile and the capabilities of the Entity. Having knowledge of the capabilities of the Entity, helps the SEF in determining the appropriate security measures that must be implemented in order to protect the workings of the Entity. The SEF maintains a table of the capabilities of the Entity).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Choyi's priority list to the combined teachings of Wang and Helden because such incorporation would have provided Quality of Service (QoS), ensuring security of critical and important data.
Regarding Claim 8, Wang in view of Holden do not explicitly teach, however, Choyi teaches the method of claim 3, wherein, for each IoT device of the plurality of IoT devices, the power-efficiency reference table further comprises a set of one or more power specifications of the corresponding IoT device ([¶ 0093] During this process the SEF determines the appropriate security requirements and features that would suit the services and resources offered or requested by an entity. Security requirements and features may be determined using some inference process or explicitly provided by the entity or configured by an administrator who may be setting up the system. The inference on security requirements may be determined using the information provided by the Entity such as Device Type/Capability and Type of Service/Resource Offered. Device Type/Capability may include: Processing Power; Memory; Power consumption; and/or Wireless Radio technology being used (e.g., bandwidth limitations). Type of Service/Resource Offered may be related to Security Requirements and the security rating, and include: Integrity of Data (e.g., High); Message originator Authentication (e.g., High); Non-repudiation (e.g., High); and/or Confidentiality (e.g., Low)).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to incorporate Choyi's teachings of determining security requirements using the device capability information to the combined teachings of Wang and Helden, because such incorporation would have ensured that security measures do not drain battery life, disrupt device performance.
Regarding Claims 15 and 18, the claim limitations are identical and/or equivalent in scope to claims 5-6 and 8, respectively, therefore, Claims 15 and 18 are rejected under the same rationale as claims 5-6 and 8.
Prior Art of Record
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure. The examiner has additionally cited the following reference on the PTO-892: US 20210409447 (Dutta) teaches [para 0085] a conventional implementation of QUIC uses the Application Layer Protocol Negotiation (ALPN) extension of TLS for negotiation of an application protocol between the endpoints as being relevant because it discuss cryptographic handshake. Thus, cryptographic handshake ALPN extension of TLS is well-known in the art as evidenced by the cited prior art.
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 MOHAMMAD YOUSUF A MIAN whose telephone number is (571)272-9206. The examiner can normally be reached Monday-Friday 9am-5:30pm.
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, ARIO ETIENNE can be reached at 571-272-4001. 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.
/MOHAMMAD YOUSUF A. MIAN/Examiner, Art Unit 2457
/ARIO ETIENNE/Supervisory Patent Examiner, Art Unit 2457