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 .
Claim Objections
A series of singular dependent claims is permissible in which a dependent claim refers to a preceding claim which, in turn, refers to another preceding claim.
A claim which depends from a dependent claim should not be separated by any claim which does not also depend from said dependent claim. It should be kept in mind that a dependent claim may refer to any preceding independent claim. In general, applicant's sequence will not be changed. See MPEP § 608.01(n).
Claim 8 should be renumbered since it depends on claim 2, but is found after claims 5-7, which do not depend on claim 2.
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.
Claim 3 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.
Claim 3 recites the limitation "… verifying the server certificate …". There is insufficient antecedent basis for this limitation in the claim. It is uncertain whether “the server certificate” is referring to the “received server certificate” or another server certificate.
Further, claim 3 recites the limitation of “without verifying the server certificate again via the second network stack” is unclear, since there is no mention of the server certificate being verified via the “second network stack.” Claim 3 states that the “first network stack” is verifying the “received server certificate,” so it is unclear as to what the “again” recitation is referring to with regards to the “second network stack.” The main reason for the indefiniteness is that the “again” in regards to the second network stack is unclear since the second network stack does not check the certificate in the first place. The examiner will interpret the “again” recitation to mean the system will simply not do a certificate check with the second network stack.
Claim Rejections - 35 USC § 102
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 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.
Claims 1-2, 7-13, 16-17, 20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Sood (EP-3541010-A1).
Regarding claim 1, Sood teaches A device, comprising: first and second processors; (Fig. 2 shows a network interface controller with cores and processors and a processor 210. Processor 210 is interpreted as the first processor, while the processing components inside the network interface controller 250 are interpreted as the second processor).
a network interface; and (Fig. 2 shows a physical interface 251 interpreted as the network interface, the interface component of the network interface controller is interpreted as the network interface.)
memory having program instructions stored therein that are executable by the first and second processors to cause the device to perform operations including: (Paragraph 7 "Embodiments of the invention may be implemented in hardware, firmware, software, or any combination thereof. Embodiments of the invention may also be implemented as instructions stored on a machine-readable medium, which may be read and executed by one or more processors. A machine-readable medium may include any mechanism for storing information in a form readable by a machine (e.g., a computing device). For example, a machine-readable medium may include read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; and others.")
establishing, via a first network stack executing on the first processor, a first connection with an external computing system; and (Paragraph 35, "At 406, the processor 210 establishes a TLS secured session with the remote client and at 408 provides the TLS secured session core 350 with TLS authentication data such as negotiated keys so that the TLS secured session core 350 may maintain the TLS secured connection without the aid of the processor 210. At 410, the computing device 110 and processor 210 may be placed into a low power sleep state." Fig. 4 shows a processor establishing a TLS session with a remote client. The processor 210 is interpreted to use a first network protocol stack to establish a connection with an external computing system.)
providing information about the first connection to a second network stack executing on the second processor; and (Paragraph 17, "The Internet Protocol Suite includes a set of layered or stacked communications protocols to handle certain aspects of networking communications over the Internet or similar networks. In particular, the Internet Protocol Suite typically includes link layer protocols, Internet layer protocols, transport layer protocols, and application layer protocols. As such, the network interface controller 250 in one embodiment may include a link layer core 252, an Internet layer core 253, a transport layer core 254, an application layer core 255, an communications processor 258 to respectively process link layer protocol packets, Internet layer protocol packets, transport layer protocol packets, application layer protocol packets, security credentials and other networking protocol data without waking the processor 210." Paragraph 12, "The computing device 100 may further include a mass storage device 240, a wired and/or wireless network interface controller 250" Fig. 2 shows a network interface controller with a communications processor inside of it. The wireless network interface controller show in fig. 4 is interpreted as the network interface with the second processor. Fig. 4 shows the processor 210 giving TLS authentication data to the WNIC at 408. Paragraph 35, "At 406, the processor 210 establishes a TLS secured session with the remote client and at 408 provides the TLS secured session core 350 with TLS authentication data such as negotiated keys so that the TLS secured session core 350 may maintain the TLS secured connection without the aid of the processor 210. At 410, the computing device 110 and processor 210 may be placed into a low power sleep state." Paragraph 22, "Further, the Internet layer core 253 and the TCP layer core 254 may implement the TCP/IP layer core 330 and the application layer core 255 may implement the TLS secured session core 350. Moreover, a communication processor 250 may implement the intrusion/virus checking core 370, and the management engine 270 may implement the service application discovery core 380." The processing components inside the network interface are interpreted as the second processor with a second network stack since it is to process packets without waking the first processor 210. The TLS authentication data given by the processor 210 is interpreted as the information about the first connection. The TLS secured session core, since in fig. 2 the application layer core 255 is an element of the network interface controller 250, is interpreted to be a functionality of the second processor.)
using the provided information to establish, via the second network stack, a second connection with the external computing system. (Paragraph 36, "At 416, the TLS secured session core 350 may resume the TLS secured connection with the remote client using the TLS authentication data previously provided by the processor 210." Paragraph 31, "As noted above, the network interface controller 250 may include an application layer core 255. As shown in FIG. 3, the application layer core 255 may include a Transport Layer Security (TLS) secured session core 330 to establish and maintain TLS secured sessions between computing devices 110, 120. In one embodiment, the TLS secured session core 330 may establish, re-establish and maintain TLS secured sessions while the computing device 110, 120 is in a sleep state. The TLS secured session core 330 may execute TLS sub-protocols such as, for example, a simple TLS handshake, a client-authorization TLS handshake, and a resumed TLS handshake as specified in RFC (Request For Comment) 5246. " The TLS session core/authentication data given by the first processor is interpreted to be used by the second processor to establish a TLS connection/second connection with the external computing system.).
Regarding claim 2, Sood teaches the device of claim 1. Sood further teaches wherein establishing the first connection includes: performing an authentication exchange with the external computing system; and (Fig. 4 shows a TLS session establishment with a remote client. Paragraph 35, "At 406, the processor 210 establishes a TLS secured session with the remote client and at 408 provides the TLS secured session core 350 with TLS authentication data such as negotiated keys so that the TLS secured session core 350 may maintain the TLS secured connection without the aid of the processor 210. At 410, the computing device 110 and processor 210 may be placed into a low power sleep state." The TLS session establishment is interpreted as an authentication exchange in establishing the first connection.).
receiving a credential for the second network stack to establish the second connection with the external computing system, wherein the credential is included in the provided information. (Paragraph 35, "At 406, the processor 210 establishes a TLS secured session with the remote client and at 408 provides the TLS secured session core 350 with TLS authentication data such as negotiated keys so that the TLS secured session core 350 may maintain the TLS secured connection without the aid of the processor 210. At 410, the computing device 110 and processor 210 may be placed into a low power sleep state." Paragraph 36, " At 416, the TLS secured session core 350 may resume the TLS secured connection with the remote client using the TLS authentication data previously provided by the processor 210." The TLS authentication data given to the WNIC in fig. 4 is interpreted as having credentials for the second network stack to establish a second connection with the external computing system. The TLS authentication data derived from the initial TLS session establishment is interpreted as the processor receiving credentials for the second network stack, the WNIC system, to establish the second connection with the external computing system, where the authentication data is included in the provided information.).
Regarding claim 7, Sood teaches the device of claim 1. Sood further teaches wherein the second processor is an efficiency processor having a reduced power consumption relative to the first processor. (claim 6, "The computer-readable medium of any of claims 1-5, wherein the network interface controller uses less power in a wake state than the host processor in a wake state.")
Regarding claim 8, Sood teaches the device of claim 2. Sood further teaches wherein the operations include: the first processor entering a reduced power state in which operation of the first network stack is suspended; and (Paragraph 35, " At 406, the processor 210 establishes a TLS secured session with the remote client and at 408 provides the TLS secured session core 350 with TLS authentication data such as negotiated keys so that the TLS secured session core 350 may maintain the TLS secured connection without the aid of the processor 210. At 410, the computing device 110 and processor 210 may be placed into a low power sleep state." Paragraph 16, "The network interface controller 250 provides an interface between the computing device 100 and a network such as network 100 of FIG. 1 . In one embodiment, the network interface controller 250 provides an interface to networks that utilize the Internet Protocol Suite of networking protocols. Moreover, as described in more detail below, the network interface controller 250 is capable of responding to various types of networking protocol packets without involving the processor 210, thus permitting the processor 210 and other components of the computing device 110 to remain in a sleep state or other low power state while still processing such networking protocol packets. To this end, the network interface controller 250 may include a physical interface 251 that includes circuitry to send and receive networking signals to and from the network 100 and may include various networking cores 252, 253, 254, 255 to process packets of various aspects of the networking protocols of the Internet Protocol Suite." The processor 210 being put into a low power sleep state is interpreted as low power state, the first network stack is interpreted as suspended because the network controller does not involve the main processor in the network communication processing, instead handling it by itself, this resulting in the interpretation that operation of the first network stack is suspended.).
the second processor communicating, via the second network stack, with the external computing system while the first processor is in the reduced power state. (Paragraph 16, "The network interface controller 250 provides an interface between the computing device 100 and a network such as network 100 of FIG. 1 . In one embodiment, the network interface controller 250 provides an interface to networks that utilize the Internet Protocol Suite of networking protocols. Moreover, as described in more detail below, the network interface controller 250 is capable of responding to various types of networking protocol packets without involving the processor 210, thus permitting the processor 210 and other components of the computing device 110 to remain in a sleep state or other low power state while still processing such networking protocol packets. To this end, the network interface controller 250 may include a physical interface 251 that includes circuitry to send and receive networking signals to and from the network 100 and may include various networking cores 252, 253, 254, 255 to process packets of various aspects of the networking protocols of the Internet Protocol Suite." Fig. 4 shows the WNIC in communication with the remote client while the platform is in a low power sleep state. The second network stack being interpreted as the network functionality managed by the processing components of the network interface controller, which is interpreted as the second processor, thus having this second network stack communicating with the external computing system while the first processor is in the reduced power state.).
Regarding claim 9, Sood teaches the device of claim 1. Sood further teaches wherein the operations include:
the second processor implementing, via the second network stack, a network proxy for the first processor, wherein implementing the network proxy includes: (Paragraph 29, "Other incoming network packets may be selectively processed by the processor 210 and/or other entities of the computing device 110 … the network interface controller 250 may include one or more filters 340 that define rules for processing incoming packets. In general, the filters 340 define a plurality of rules that specify criteria for identifying incoming packets of interest and that specify how such packets of interest are to be processed by the computing device 110. In one embodiment, the user or administrator of the computing device 110 may configure the filters 340 in the network interface controller 250. In particular, the user may specify packets of interest by Link Layer Protocol frames (e.g. Group Key Updates, Disassociations, etc.) IP address, TCP or UDP port number, HTTP Tags, application packet contents, TLS security matches, etc. The user may further specify whether a given rule of the filters 340 is to wake up one or more entities of the computing device 110 such as the processor 210, management engine 270, etc." The processing components inside the network interface controller are interpreted to perform network proxy functions since they will determine whether or not to send certain data to the main processor 210.).
analyzing network traffic routed to the second network stack to determine whether the analyzed network traffic requests a function that is not included in a subset of functions supported by the second network stack; and (Paragraph 29, "Other incoming network packets may be selectively processed by the processor 210 and/or other entities of the computing device 110 such as, for example, the communications processor 258, the management engine 270, networking cores 252, 253, 254, 255, etc. To this end, the network interface controller 250 may include one or more filters 340 that define rules for processing incoming packets. In general, the filters 340 define a plurality of rules that specify criteria for identifying incoming packets of interest and that specify how such packets of interest are to be processed by the computing device 110. In one embodiment, the user or administrator of the computing device 110 may configure the filters 340 in the network interface controller 250. In particular, the user may specify packets of interest by Link Layer Protocol frames (e.g. Group Key Updates, Disassociations, etc.) IP address, TCP or UDP port number, HTTP Tags, application packet contents, TLS security matches, etc. The user may further specify whether a given rule of the filters 340 is to wake up one or more entities of the computing device 110 such as the processor 210, management engine 270, etc." The processing components of the network interface controller are interpreted to analyze network traffic, with the filtering of network traffic is interpreted as analyzing. The determining of whether or not the analyzed traffic requests a function not included in a subset of functions supported by the second network stack is interpreted as the rules/criteria for identifying incoming packets of interest having the rule to be selectively processed by processor 210. The functions/packets of interest are not supported by the network interface controller's processing component's network stack since they are user configured rules for handling specific packet types.).
based on the requested function, the second processor providing the analyzed network traffic to the first network stack. (Paragraph 29, "Other incoming network packets may be selectively processed by the processor 210 and/or other entities of the computing device 110 such as, for example, the communications processor 258, the management engine 270, networking cores 252, 253, 254, 255, etc. To this end, the network interface controller 250 may include one or more filters 340 that define rules for processing incoming packets. In general, the filters 340 define a plurality of rules that specify criteria for identifying incoming packets of interest and that specify how such packets of interest are to be processed by the computing device 110. In one embodiment, the user or administrator of the computing device 110 may configure the filters 340 in the network interface controller 250. In particular, the user may specify packets of interest by Link Layer Protocol frames (e.g. Group Key Updates, Disassociations, etc.) IP address, TCP or UDP port number, HTTP Tags, application packet contents, TLS security matches, etc. The user may further specify whether a given rule of the filters 340 is to wake up one or more entities of the computing device 110 such as the processor 210, management engine 270, etc." Fig. 3 shows a filtration system for sending a analyzing and sending network traffic to the processor. The requested function is interpreted as the packet types of interest, where the network packets being selectively processed by processor 210 after waking up the processor based on filter rules is interpreted as providing the analyzed network traffic to the first network stack.).
Regarding claim 10, Sood teaches the device of claim 9. Sood further teaches wherein the analyzed network traffic includes a push notification requesting a function of an application executing on the first processor (Paragraph 36, "Assuming the request passes the various filters and checks of the networking cores 310, 320, 330, 350, 360, 370, and 380, the network interface controller 250 may wake the processor 210 at 440. The processor 210 at 450 may respond to the HTTPS request and future HTTPS requests via the network interface controller 250." The network traffic is analyzed with the filters. The push notification is interpreted as the HTTP request that requires the first processor to wake up. The application is interpreted as the HTTP handling software running on the processor.).
Regarding claim 11, Sood teaches A method, comprising: establishing, by a first processor executing a first network stack of a device, a communication session with a remote computing system via a network interface of the device, wherein the establishing includes receiving a credential for resuming the communication session; (Paragraph 35, "At 406, the processor 210 establishes a TLS secured session with the remote client and at 408 provides the TLS secured session core 350 with TLS authentication data such as negotiated keys so that the TLS secured session core 350 may maintain the TLS secured connection without the aid of the processor 210. At 410, the computing device 110 and processor 210 may be placed into a low power sleep state." Fig. 4 shows a processor establishing a TLS session with a remote client. Fig. 4 shows the processor 210 giving TLS authentication data to the WNIC at 408. Paragraph 35, "At 406, the processor 210 establishes a TLS secured session with the remote client and at 408 provides the TLS secured session core 350 with TLS authentication data such as negotiated keys so that the TLS secured session core 350 may maintain the TLS secured connection without the aid of the processor 210. At 410, the computing device 110 and processor 210 may be placed into a low power sleep state." Fig. 4 shows a TLS resumption 416 after receiving the authentication data. The processor 210 is interpreted to use a first network stack to establish a connection with an external computing system. The TLS authentication data is interpreted as a credential for resuming the communication session, since the WNIC after receiving it performs TLS session resumption with the remote client.)
providing, by the first processor, the credential to a second network stack executing on a second processor of the device; and (Paragraph 17, "The Internet Protocol Suite includes a set of layered or stacked communications protocols to handle certain aspects of networking communications over the Internet or similar networks. In particular, the Internet Protocol Suite typically includes link layer protocols, Internet layer protocols, transport layer protocols, and application layer protocols. As such, the network interface controller 250 in one embodiment may include a link layer core 252, an Internet layer core 253, a transport layer core 254, an application layer core 255, an communications processor 258 to respectively process link layer protocol packets, Internet layer protocol packets, transport layer protocol packets, application layer protocol packets, security credentials and other networking protocol data without waking the processor 210." Paragraph 12, "The computing device 100 may further include a mass storage device 240, a wired and/or wireless network interface controller 250" Fig. 2 shows a network interface controller with a communications processor inside of it. The wireless network interface controller show in fig. 4 is interpreted as the network interface with the second processor. Fig. 4 shows the processor 210 giving TLS authentication data to the WNIC at 408. Paragraph 35, "At 406, the processor 210 establishes a TLS secured session with the remote client and at 408 provides the TLS secured session core 350 with TLS authentication data such as negotiated keys so that the TLS secured session core 350 may maintain the TLS secured connection without the aid of the processor 210. At 410, the computing device 110 and processor 210 may be placed into a low power sleep state." Paragraph 22, "Further, the Internet layer core 253 and the TCP layer core 254 may implement the TCP/IP layer core 330 and the application layer core 255 may implement the TLS secured session core 350. Moreover, a communication processor 250 may implement the intrusion/virus checking core 370, and the management engine 270 may implement the service application discovery core 380." The processing components inside the network interface are interpreted as the second processor with a second network stack since it is to process packets without waking the first processor 210. The TLS authentication data given by the processor 210 is interpreted as the information about the first connection. The TLS secured session core, since in fig. 2 the application layer core 255 is an element of the network interface controller 250, is interpreted to be a functionality of the second processor.).
resuming, by the second processor via the second network stack, the communication session with the remote computing system. (Paragraph 36, "At 416, the TLS secured session core 350 may resume the TLS secured connection with the remote client using the TLS authentication data previously provided by the processor 210." Paragraph 31, "As noted above, the network interface controller 250 may include an application layer core 255. As shown in FIG. 3, the application layer core 255 may include a Transport Layer Security (TLS) secured session core 330 to establish and maintain TLS secured sessions between computing devices 110, 120. In one embodiment, the TLS secured session core 330 may establish, re-establish and maintain TLS secured sessions while the computing device 110, 120 is in a sleep state. The TLS secured session core 330 may execute TLS sub-protocols such as, for example, a simple TLS handshake, a client-authorization TLS handshake, and a resumed TLS handshake as specified in RFC (Request For Comment) 5246. " Fig.4 shows the WNIC performing TLS session resumption with the remote computing system. The TLS session core/authentication data given by the first processor is interpreted to be used by the second processor to establish a TLS connection/second connection with the external computing system.).
Regarding claim 12, Sood teaches the method of claim 11. Sood further teaches wherein the second processor is an efficiency processor having a reduced power consumption relative to the first processor; and (claim 6, "The computer-readable medium of any of claims 1-5, wherein the network interface controller uses less power in a wake state than the host processor in a wake state." The network interface controller's processing components is interpreted as the second processor, the first processor interpreted as the host processor.).
wherein the second processor is configured to keep alive the communication session while the first processor is in a reduced power state in which operation of the first network stack is suspended. (Paragraph 35, " At 406, the processor 210 establishes a TLS secured session with the remote client and at 408 provides the TLS secured session core 350 with TLS authentication data such as negotiated keys so that the TLS secured session core 350 may maintain the TLS secured connection without the aid of the processor 210. At 410, the computing device 110 and processor 210 may be placed into a low power sleep state." Paragraph 16, "The network interface controller 250 provides an interface between the computing device 100 and a network such as network 100 of FIG. 1 . In one embodiment, the network interface controller 250 provides an interface to networks that utilize the Internet Protocol Suite of networking protocols. Moreover, as described in more detail below, the network interface controller 250 is capable of responding to various types of networking protocol packets without involving the processor 210, thus permitting the processor 210 and other components of the computing device 110 to remain in a sleep state or other low power state while still processing such networking protocol packets. To this end, the network interface controller 250 may include a physical interface 251 that includes circuitry to send and receive networking signals to and from the network 100 and may include various networking cores 252, 253, 254, 255 to process packets of various aspects of the networking protocols of the Internet Protocol Suite." Paragraph 16, "The network interface controller 250 provides an interface between the computing device 100 and a network such as network 100 of FIG. 1 . In one embodiment, the network interface controller 250 provides an interface to networks that utilize the Internet Protocol Suite of networking protocols. Moreover, as described in more detail below, the network interface controller 250 is capable of responding to various types of networking protocol packets without involving the processor 210, thus permitting the processor 210 and other components of the computing device 110 to remain in a sleep state or other low power state while still processing such networking protocol packets. To this end, the network interface controller 250 may include a physical interface 251 that includes circuitry to send and receive networking signals to and from the network 100 and may include various networking cores 252, 253, 254, 255 to process packets of various aspects of the networking protocols of the Internet Protocol Suite." Fig. 4 shows the WNIC in communication with the remote client while the platform is in a low power sleep state. The processor 210 being put into a low power sleep state is interpreted as low power state, the first network stack is interpreted as suspended because the network controller does not involve the main processor in the network communication processing, instead handling it by itself, this resulting in the interpretation that operation of the first network stack is suspended. The second network stack being interpreted as the network functionality managed by the processing components of the network interface controller, which is interpreted as the second processor, thus having this second network stack communicating with the external computing system while the first processor is in the reduced power state.).
Regarding claim 13, Sood teaches the method of claim 11. Sood further teaches the method further comprising: prior to the resuming, instructing, by the first processor via the first network stack, the network interface to steer network traffic associated with the resumed communication session to the second network stack. (Paragraph 35, " At 406, the processor 210 establishes a TLS secured session with the remote client and at 408 provides the TLS secured session core 350 with TLS authentication data such as negotiated keys so that the TLS secured session core 350 may maintain the TLS secured connection without the aid of the processor 210." Fig. 4 shows the processor giving authentication data to the WNIC for handling the communication session, with the WNIC performing a TLS session resumption after. This is interpreted as prior to the session resumption, the first processor, by giving authentication data to the WNIC's TLS secured session core, is instructing the network interface to steer network traffic associated with the resumed communication session to the second network stack, since the processor gave the WNIC, which controls the network interface, the information to perform the session management, to which the WNIC does after receiving the data. It is interpreted as steering since the information is now being processed by the processing components of the WNIC.)
Regarding claim 16, Sood teaches A non-transitory computer readable medium having program instructions stored therein that are executable by a device to perform operations, comprising: (Paragraph 7 "Embodiments of the invention may be implemented in hardware, firmware, software, or any combination thereof. Embodiments of the invention may also be implemented as instructions stored on a machine-readable medium, which may be read and executed by one or more processors. A machine-readable medium may include any mechanism for storing information in a form readable by a machine (e.g., a computing device). For example, a machine-readable medium may include read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; and others.")
establishing a connection with an external computing system via a first network stack executing on a first processor of the device, wherein the establishing includes: (Fig. 4 shows a processor establishing a TLS session with a remote device).
receiving a credential in response to an authentication handshake; and (Paragraph 35, "At 406, the processor 210 establishes a TLS secured session with the remote client and at 408 provides the TLS secured session core 350 with TLS authentication data such as negotiated keys so that the TLS secured session core 350 may maintain the TLS secured connection without the aid of the processor 210. At 410, the computing device 110 and processor 210 may be placed into a low power sleep state." Fig. 4 shows a processor establishing a TLS session with a remote client. Fig. 4 shows the processor 210 giving TLS authentication data to the WNIC at 408. Paragraph 35, "At 406, the processor 210 establishes a TLS secured session with the remote client and at 408 provides the TLS secured session core 350 with TLS authentication data such as negotiated keys so that the TLS secured session core 350 may maintain the TLS secured connection without the aid of the processor 210. At 410, the computing device 110 and processor 210 may be placed into a low power sleep state." Fig. 4 shows a TLS resumption 416 after receiving the authentication data. The processor 210 is interpreted to use a first network stack to establish a connection with an external computing system. The TLS authentication data is interpreted as a credential for resuming the communication session in response to an authentication handshake, since the WNIC after receiving it performs TLS session resumption with the remote client.)
using the credential to keep alive the connection via a second network stack executing on a second processor of the device. (Paragraph 36, "At 416, the TLS secured session core 350 may resume the TLS secured connection with the remote client using the TLS authentication data previously provided by the processor 210." Paragraph 31, "As noted above, the network interface controller 250 may include an application layer core 255. As shown in FIG. 3, the application layer core 255 may include a Transport Layer Security (TLS) secured session core 330 to establish and maintain TLS secured sessions between computing devices 110, 120. In one embodiment, the TLS secured session core 330 may establish, re-establish and maintain TLS secured sessions while the computing device 110, 120 is in a sleep state. The TLS secured session core 330 may execute TLS sub-protocols such as, for example, a simple TLS handshake, a client-authorization TLS handshake, and a resumed TLS handshake as specified in RFC (Request For Comment) 5246. " Fig.4 shows the WNIC performing TLS session resumption with the remote computing system. The TLS session core/authentication data given by the first processor is interpreted to be used by the second processor to resume a TLS connection/second connection with the external computing system, resumption keeping it alive.).
Regarding claim 17, Sood teaches the computer readable medium of claim 16. Sood further teaches wherein keeping the connection alive includes: persisting, by the second processor via the second network stack, the connection while the first processor is in a reduced power state in which operation of the first network stack is suspended. (Paragraph 35, " At 406, the processor 210 establishes a TLS secured session with the remote client and at 408 provides the TLS secured session core 350 with TLS authentication data such as negotiated keys so that the TLS secured session core 350 may maintain the TLS secured connection without the aid of the processor 210. At 410, the computing device 110 and processor 210 may be placed into a low power sleep state." Paragraph 16, "The network interface controller 250 provides an interface between the computing device 100 and a network such as network 100 of FIG. 1 . In one embodiment, the network interface controller 250 provides an interface to networks that utilize the Internet Protocol Suite of networking protocols. Moreover, as described in more detail below, the network interface controller 250 is capable of responding to various types of networking protocol packets without involving the processor 210, thus permitting the processor 210 and other components of the computing device 110 to remain in a sleep state or other low power state while still processing such networking protocol packets. To this end, the network interface controller 250 may include a physical interface 251 that includes circuitry to send and receive networking signals to and from the network 100 and may include various networking cores 252, 253, 254, 255 to process packets of various aspects of the networking protocols of the Internet Protocol Suite." Paragraph 16, "The network interface controller 250 provides an interface between the computing device 100 and a network such as network 100 of FIG. 1 . In one embodiment, the network interface controller 250 provides an interface to networks that utilize the Internet Protocol Suite of networking protocols. Moreover, as described in more detail below, the network interface controller 250 is capable of responding to various types of networking protocol packets without involving the processor 210, thus permitting the processor 210 and other components of the computing device 110 to remain in a sleep state or other low power state while still processing such networking protocol packets. To this end, the network interface controller 250 may include a physical interface 251 that includes circuitry to send and receive networking signals to and from the network 100 and may include various networking cores 252, 253, 254, 255 to process packets of various aspects of the networking protocols of the Internet Protocol Suite." Fig. 4 shows the WNIC in communication with the remote client while the platform is in a low power sleep state. The processor 210 being put into a low power sleep state is interpreted as low power state, the first network stack is interpreted as suspended because the network controller does not involve the main processor in the network communication processing, instead handling it by itself, this resulting in the interpretation that operation of the first network stack is suspended. The second network stack being interpreted as the network functionality managed by the processing components of the network interface controller, which is interpreted as the second processor, thus having this second network stack communicating with the external computing system while the first processor is in the reduced power state. The connection is interpreted as persisted since packets from the remote device are being processed).
Regarding claim 20, Sood teaches the computer readable medium of claim 16, wherein keeping the connection alive includes: implementing, via the second network stack, a network proxy that receives network traffic destined for the first network stack. (Paragraph 29, "Other incoming network packets may be selectively processed by the processor 210 and/or other entities of the computing device 110 … the network interface controller 250 may include one or more filters 340 that define rules for processing incoming packets. In general, the filters 340 define a plurality of rules that specify criteria for identifying incoming packets of interest and that specify how such packets of interest are to be processed by the computing device 110. In one embodiment, the user or administrator of the computing device 110 may configure the filters 340 in the network interface controller 250. In particular, the user may specify packets of interest by Link Layer Protocol frames (e.g. Group Key Updates, Disassociations, etc.) IP address, TCP or UDP port number, HTTP Tags, application packet contents, TLS security matches, etc. The user may further specify whether a given rule of the filters 340 is to wake up one or more entities of the computing device 110 such as the processor 210, management engine 270, etc." The processing components inside the network interface controller are interpreted to perform network proxy functions since they will determine whether or not to send certain data to the main processor 210. It is interpreted as destined for the first network stack since the processor is the one meant to handle the specific data traffic.).
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.
Claims 3-6, 14-15 are rejected under 35 U.S.C. 103 as being unpatentable over Sood (EP-3541010-A1) in view of IETF (“The Transport Layer Security (TLS) Protocol Version 1.3,” August 2018).
Regarding claim 3, Sood teaches the device of claim 2. Sood further teaches wherein the authentication exchange includes:
[establishing] … via the first network stack, … [a TLS session] … [with] the external computing system (Fig. 4 shows a TLS session establishment between the processor, whose networking functionality is interpreted as a first network stack, where it communicates with the remote client, or external computing system.)
wherein establishing the second connection includes the second processor communicating with the external computing system … [performing TLS session resumption] … via the second network stack. (Fig. 4 shows TLS session resumption performed between the remote client and WNIC. The establishing a second connection is interpreted as resuming the TLS session by using the WNIC/secondary processor).
However, Sood does not explicitly teach verifying, via the … network stack, a received server certificate attesting to a public key of the external computing system, wherein establishing the second connection includes … communicating with the external computing system without verifying the server certificate again …
IETF teaches verifying, via the … network stack, a received server certificate attesting to a public key of the external computing system, wherein establishing the second connection includes … communicating with the external computing system without verifying the server certificate again … (Figure 3 shows a client and server communication. The client has a step where it performs a certificate verification of the Server's. The second connection is the subsequent handshake shown in figure 3, where message flow for resumption does not have a certificate verification step. Page 13, "CertificateVerify: A signature over the entire handshake using the private key corresponding to the public key in the Certificate message. This message is omitted if the endpoint is not authenticating via a certificate." The certificate is interpreted as attesting to a public key of the external computing system.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Sood’s reduced power network processing system with IETF by enhancing Sood’s TLS implementation of sessions to be updated to version 1.3, where the server certificate is obtained by the client, where the client then initiates session resumption without server certificate check, as taught by IETF. The motivation is to use the latest version of TLS, since it is the most secure available version, and make it easier to resume a communication session without performing many authentication checks.
Regarding claim 4, Sood teaches the device of claim 2. Sood further teaches wherein the authentication exchange includes:
providing, via the first network stack, … [session establishment information]…, wherein establishing the second connection includes the second processor communicating with the external computing system … [using authentication data from the session established via the first network stack]. (Fig. 4 shows a session established between the processor and the remote client, where there is a TLS session established. Fig. 4 shows the WNIC performing TLS resumption with the remote client. Paragraph 36, "At 416, the TLS secured session core 350 may resume the TLS secured connection with the remote client using the TLS authentication data previously provided by the processor 210." Paragraph 31, "As noted above, the network interface controller 250 may include an application layer core 255. As shown in FIG. 3 , the application layer core 255 may include a Transport Layer Security (TLS) secured session core 330 to establish and maintain TLS secured sessions between computing devices 110, 120. In one embodiment, the TLS secured session core 330 may establish, re-establish and maintain TLS secured sessions while the computing device 110, 120 is in a sleep state. The TLS secured session core 330 may execute TLS sub-protocols such as, for example, a simple TLS handshake, a client-authorization TLS handshake, and a resumed TLS handshake as specified in RFC (Request For Comment) 5246." The second connection has the WNIC communicating with the remote client using authentication data received from the processor.)
However, Sood does not explicitly teach providing, via the first network stack, a client certificate attesting to a public key of the device, wherein establishing the second connection includes… communicating with the external computing system without providing the client certificate again.
IETF teaches providing, via the first network stack, a client certificate attesting to a public key of the device, wherein establishing the second connection includes… communicating with the external computing system without providing the client certificate again. (Figure 3 shows the Server performing certificate verification of the client's certificate. Page 13, "CertificateVerify: A signature over the entire handshake using the private key corresponding to the public key in the Certificate message. This message is omitted if the endpoint is not authenticating via a certificate." The second connection is interpreted as the subsequent handshake between the two devices. The certificate is interpreted to attest to a public key. The client certificate is interpreted to be provided via the first network stack of the client device to the server to then verify.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Sood’s reduced power network processing system with IETF by enhancing Sood’s TLS implementation of sessions to be updated to version 1.3, where the client certificate is obtained by the server, where the server then permits continuing a TLS session without doing another client certificate check, as taught by IETF. The motivation is to use the latest version of TLS, since it is the most secure available version, and make it easier to resume a communication session without performing many authentication checks.
Regarding claim 5, Sood teaches the device of claim 1. Sood further teaches wherein establishing the second connection includes: deriving, via the second network stack, … [authentication data] … included in a credential in the provided information; and (Paragraph 40, "At 406, the processor 210 establishes a TLS secured session with the remote client and at 408 provides the TLS secured session core 350 with TLS authentication data such as negotiated keys so that the TLS secured session core 350 may maintain the TLS secured connection without the aid of the processor 210." The second network stack received authentication data that it will be using to maintain the TLS connection.)
securing, via the second network stack, the second connection with the external computing system using the derived … [authentication information]. (Paragraph 31, "As noted above, the network interface controller 250 may include an application layer core 255. As shown in FIG. 3 , the application layer core 255 may include a Transport Layer Security (TLS) secured session core 330 to establish and maintain TLS secured sessions between computing devices 110, 120. In one embodiment, the TLS secured session core 330 may establish, re-establish and maintain TLS secured sessions while the computing device 110, 120 is in a sleep state. The TLS secured session core 330 may execute TLS sub-protocols such as, for example, a simple TLS handshake, a client-authorization TLS handshake, and a resumed TLS handshake as specified in RFC (Request For Comment) 5246." Paragraph 36, "At 416, the TLS secured session core 350 may resume the TLS secured connection with the remote client using the TLS authentication data previously provided by the processor 210. " The TLS session resumption using authentication data is interpreted as securing the second connection using derived authentication information.).
However, Sood does not explicitly teach … a cryptographic key from key material included in a credential … and securing, via the … network stack, the second connection with the external computing system using the derived cryptographic key.
IETF teaches … a cryptographic key from key material included in a credential … (Page 15, "Figure 3 shows a pair of handshakes in which the first handshake establishes a PSK and the second handshake uses it" The cryptographic key is interpreted as the pre-shared-key (PSK), where it is shown to be used in the subsequent handshake.).
securing, via the … network stack, the second connection with the external computing system using the derived cryptographic key (Figure 3 shows a PSK being used in securing the TLS connection in a subsequent handshake.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Sood’s reduced power network processing system with IETF by enhancing Sood’s TLS implementation of sessions to be updated to version 1.3, with using a PSK to resume a session rather than restarting the TLS authentication process again, as taught by IETF. The motivation is to use the latest version of TLS, since it is the most secure available version, and save time by resuming a session rather than restarting the authentication processing for a new session.
Regarding claim 6, Sood in view of IETF teaches the device of claim 5. Sood further teaches wherein the credential is a transport layer security (TLS) session resumption token including … [authentication data]. (Paragraph 31, "As noted above, the network interface controller 250 may include an application layer core 255. As shown in FIG. 3 , the application layer core 255 may include a Transport Layer Security (TLS) secured session core 330 to establish and maintain TLS secured sessions between computing devices 110, 120. In one embodiment, the TLS secured session core 330 may establish, re-establish and maintain TLS secured sessions while the computing device 110, 120 is in a sleep state. The TLS secured session core 330 may execute TLS sub-protocols such as, for example, a simple TLS handshake, a client-authorization TLS handshake, and a resumed TLS handshake as specified in RFC (Request For Comment) 5246." Paragraph 36, "At 416, the TLS secured session core 350 may resume the TLS secured connection with the remote client using the TLS authentication data previously provided by the processor 210. " Fig. 4 shows the WNIC performing session resumption with the remote device. The authentication data given by the processor to the WNIC is interpreted as a TLS resumption token since it allows the WNIC to resume the TLS session.)
However, Sood does not explicitly teach the transport layer security (TLS) session resumption [information] including a pre-shared key (PSK).
IETF teaches … transport layer security (TLS) session resumption [information] including a pre-shared key (PSK). (Page 15, "Figure 3 shows a pair of handshakes in which the first handshake establishes a PSK and the second handshake uses it" Figure 3 shows that in the subsequent handshake, the second connection, that the pre-shared-key is used to establish the TLS resumption connection.).
The motivation to combine Sood with IETF is the same as in claim 5.
Regarding claim 14, Sood teaches the method of claim 11. Sood further teaches wherein the establishing includes receiving [authentication credentials] in response to a single authentication handshake; and (Paragraph 35, "At 406, the processor 210 establishes a TLS secured session with the remote client and at 408 provides the TLS secured session core 350 with TLS authentication data such as negotiated keys so that the TLS secured session core 350 may maintain the TLS secured connection without the aid of the processor 210. At 410, the computing device 110 and processor 210 may be placed into a low power sleep state." Fig. 4 shows a processor establishing a TLS session with a remote client. The processor 210 is interpreted to use a first network protocol stack to establish a TLS connection authentication handshake with an external computing system. The authentication credentials are interpreted to come from the TLS session establishment.).
wherein the resuming includes [using at least part of the authentication credentials] for resuming the communication session. (Paragraph 36, "At 416, the TLS secured session core 350 may resume the TLS secured connection with the remote client using the TLS authentication data previously provided by the processor 210." Paragraph 31, "As noted above, the network interface controller 250 may include an application layer core 255. As shown in FIG. 3, the application layer core 255 may include a Transport Layer Security (TLS) secured session core 330 to establish and maintain TLS secured sessions between computing devices 110, 120. In one embodiment, the TLS secured session core 330 may establish, re-establish and maintain TLS secured sessions while the computing device 110, 120 is in a sleep state. The TLS secured session core 330 may execute TLS sub-protocols such as, for example, a simple TLS handshake, a client-authorization TLS handshake, and a resumed TLS handshake as specified in RFC (Request For Comment) 5246. " The TLS session core/authentication data given by the first processor is interpreted to be used by the second processor to resume a TLS connection/second connection with the external computing system.)
However, Sood does not explicitly teach … receiving a plurality of credentials in response to a single authentication handshake; and … selecting one of the credentials for resuming …
IETF teaches wherein the establishing includes receiving a plurality of credentials in response to a single authentication handshake; and (Page 15, "Figure 3 shows a pair of handshakes in which the first handshake establishes a PSK and the second handshake uses it" Figure 3 shows the Client device performing certificate verification and establishing a PSK it is to later use. The certificate and PSK are interpreted as a plurality of credentials.).
wherein the resuming includes selecting one of the credentials for resuming the communication session. (Page 15, "Figure 3 shows a pair of handshakes in which the first handshake establishes a PSK and the second handshake uses it" The TLS resumption handshake is interpreted as resuming the communication session by selecting the PSK, as shown in Figure 3.)
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Sood’s reduced power network processing system with IETF by enhancing Sood’s TLS implementation of sessions to be updated to version 1.3, with using a PSK to resume a session rather than restarting the TLS authentication process again, as taught by IETF. The motivation is to use the latest version of TLS, since it is the most secure available version, and save time by resuming a session rather than restarting the authentication processing for a new session.
Regarding claim 15, Sood teaches the method of claim 11. Sood further teaches wherein the credential is a transport layer security (TLS) new session ticket including … [authentication data]; and (Paragraph 31, "As noted above, the network interface controller 250 may include an application layer core 255. As shown in FIG. 3 , the application layer core 255 may include a Transport Layer Security (TLS) secured session core 330 to establish and maintain TLS secured sessions between computing devices 110, 120. In one embodiment, the TLS secured session core 330 may establish, re-establish and maintain TLS secured sessions while the computing device 110, 120 is in a sleep state. The TLS secured session core 330 may execute TLS sub-protocols such as, for example, a simple TLS handshake, a client-authorization TLS handshake, and a resumed TLS handshake as specified in RFC (Request For Comment) 5246." Paragraph 36, "At 416, the TLS secured session core 350 may resume the TLS secured connection with the remote client using the TLS authentication data previously provided by the processor 210. " Fig. 4 shows the WNIC performing session resumption with the remote device. The authentication data given by the processor to the WNIC is interpreted as a TLS new session ticket since it allows the WNIC to resume the TLS session.)
However, Sood does not explicitly teach the credential … including a pre-shared key (PSK) and wherein the resuming includes performing a TLS handshake using the PSK.
IETF teaches wherein the credential is … transport layer security (TLS) … [data] … including a pre-shared key (PSK). (Page 15, "Figure 3 shows a pair of handshakes in which the first handshake establishes a PSK and the second handshake uses it," the PSK is interpreted to be TLS credential data.).
wherein the resuming includes performing a TLS handshake using the PSK. (Page 15, "Figure 3 shows a pair of handshakes in which the first handshake establishes a PSK and the second handshake uses it" Figure 3 shows that in the subsequent handshake, the second connection, that the pre-shared-key is used to establish the TLS resumption connection.).
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Sood’s reduced power network processing system with IETF by enhancing Sood’s TLS implementation of sessions to be updated to version 1.3, with using a PSK to resume a session rather than restarting the TLS authentication process again, as taught by IETF. The motivation is to use the latest version of TLS, since it is the most secure available version, and save time by resuming a session rather than restarting the authentication processing for a new session.
Claims 18 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Sood (EP-3541010-A1) in view of StanleyArvey, ("TCP Keep-Alive: Technical Insights & Understanding," April 8, 2023).
Regarding claim 18, Sood teaches the computer readable medium of claim 16. Sood further teaches wherein keeping the connection alive includes:
communicating, via the second network stack, with the external computing system … (Fig. 4 shows a TCP three way handshake established between the second processor/second network stack and the remote client/external computing system.)
However, Sood does not explicitly teach communicating, … with … [an] … external computing system at a regular cadence to persist the connection.
StanleyArvey teaches communicating, … with … [an] … external computing system at a regular cadence to persist the connection. (Page 2, "TCP keep-alive is a mechanism that enables two devices to maintain an open connection even when there is no data transmission. It sends periodic messages (keep-alive packets)between the devices to ensure that the connection remains active. If either device fails to receive a keep-alive packet, it will assume that the other device is no longer available, and the connection will be terminated.").
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to modify Sood’s reduced power network processing system with StanleyArvey by enhancing Sood’s TCP system to include keepalive messages to persist a connection between two devices, where the keepalives failing indicates the connection is no longer alive, as taught by StanleyArvey. The motivation is to provide the system a way to check the status of a connection even if traffic is not being sent, that way allowing a connection to close if the device on the other end is unavailable for communications.
Regarding claim 19, Sood in view of StanleyArvey teaches the computer readable medium of claim 18. Sood further teaches wherein the external computing system implements a push notification service, and wherein the communicating includes: receiving, via the second network stack, one or more push notifications over the persisted connection. (Paragraph 36, "Assuming the request passes the various filters and checks of the networking cores 310, 320, 330, 350, 360, 370, and 380, the network interface controller 250 may wake the processor 210 at 440. The processor 210 at 450 may respond to the HTTPS request and future HTTPS requests via the network interface controller 250." The network traffic is analyzed with the filters. The push notification is interpreted as the HTTP request that requires the first processor to wake up. The application is interpreted as the HTTP handling software running on the processor.).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to MUHAMMAD H RASUL whose telephone number is (571)272-4613. The examiner can normally be reached Monday - Friday 6:30 A.M.- 5:00 P.M. E.D.T..
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Rupal Dharia can be reached at 571-272-3880. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/M.H.R./Examiner, Art Unit 2492 /RUPAL DHARIA/Supervisory Patent Examiner, Art Unit 2492
Prosecution Insights