DETAILED ACTION
This Action is in response to Application Number 18792968 received on 8/02/2024.
Claims 1-21 are presented for examination.
The effective filing date for this application is 8/02/2024.
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
Claim 1, 9-16 are objected to because of the following informalities:
Claims 1 recites the limitation, “receiving a packet going from to sender to a receiver”, which includes minor typographical errors. For examination purposes, the limitation will be interpreted to recite “receiving a packet going from the sender to the receiver
Claim 9 recites the following three limitations, “a client device configured to:”, “execute a trust establishment process with one or more servers”, and “a packet filter that receives”.
It appears that the elements recited in these limitations were intended to refer to the elements already recited in the preamble.
For examination purposes, the above limitations will be interpreted to recite, “the client device configured to:”, “execute a trust establishment process with the one or more servers”, and “the packet filter receives”, in order to remove any potential antecedent basis issues.
Claims 10-15 each recite the limitation, “The system of claim 9”. For examination purposes, the limitation in each of claims 10-15 will be interpreted to recite, “The packet filtering system of claim 9”, in order to remove any potential antecedent basis issues.
Claim 16 recites the limitation, “receiving a packet going from to sender to a receiver”, which includes a minor typographical error. For examination purposes, the limitation will be interpreted to recite, “receiving a packet going from a sender to a receiver”.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-8 and 16-21 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claims 1 and 16 recite the limitation, “determining that the token matches an expected value, which is a function of (i) a secret associated with the sender, and (ii) a current value of data element that is available to the sender, the data element changing in value over time”, which is found indefinite, as the scope is unclear as to what is required by the recited current value of the data element being “available to the sender”. The limitation merely describes the current value without any functional interrelationship with the rest of the limitations and additionally appears optional as to whether the sender obtains/uses the value. For examination purposes, the limitation, “current value of the data element that is available to the sender” will be interpreted with respect to the specification, [0036], as a value of time, since the specification recites, “Naturally the time changes on both client and packet filter” and also provides examples of known techniques of synchronization of network clocks, showing that the element of time is known to be available to the sender/client.
Claims 2-8 and 17-21 are rejected for the same reasons above by virtue of their dependencies to claims 1 and 16.
Claim Interpretation
Claim 16 recites the limitation, “A non-transitory computer readable medium holding computer program instructions”. The office interprets the use of “holding instructions” in this limitation as equivalent to “storing instructions”, which appears consistent with Applicant’s specification, paragraph [0052], reciting, “Such code may be read from or stored on a non-transitory computer-readable medium”.
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.
Claim(s) 1-2, 8, 16-17 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Pane et al. (US 20230308475).
Regarding claim 1, Pane disclosed a method performed at one or more devices that perform packet filtering on packets sent from a sender to a receiver over one or more networks, the method comprising:
receiving a packet going from to sender to a receiver, the packet as received having a field identifiable in cleartext (Pane, [0009], “receiving, from the client device, an ingress packet at a demultiplexer that corresponds to the VIP address, wherein the ingress packet includes a routing and authentication header, parsing the routing and authentication header to obtain the private IP address, the port number, and the token”; Figure 3, element 315 is a header of the packet that is not encrypted nor obfuscated, and therefore amounts to a field identifiable in cleartext; [0049], “Upon receipt of an ingress packet”; [0051], The packet is directed to a target application server);
examining the packet to locate the field and to extract a token therefrom (Pane, [0049], “Upon receipt of an ingress packet, the demultiplexer 206 checks the routing and authentication header. If the ingress packet is lacking the routing and authentication header or the routing and authentication head[er] is malformed, the demultiplexer 206 discards the ingress packet. If the routing and authentication header is present and not malformed, the demultiplexer 206 parses the routing and authentication layer to extract the private IP address and the port number for the targeted application server 115a, as well as the token”);
validating the token (Pane, [0049], “The demultiplexer 206 performs authentication of the token”), comprising:
determining that the token matches an expected value, which is a function of (i) a secret associated with the sender, and (ii) a current value of data element that is available to the sender, the data element changing in value over time (Pane, [0049], “For example, the demultiplexer 206 may identify the secret key; generate a hash of the client device IP address, the private IP address, and a secret key; and compare the hash to the token to confirm that the values are equal”; The demultiplexor therefore determines that the token provided in the header matches an expected value, in which the token is a function of a secret key which is associated with all elements of the system including the sender; [0040], “The token generator 204 may use a cryptographic hash function that is a cryptographic Message Authentication Code (MAC) where the token is derived from connection information, time (e.g., a timestamp), and platform-defined metadata”; [0045], “the token generator 204 generates a first token and after a predetermined amount of time, generates a second token. The second token uses a different secret key. In some embodiments, generation of the second token invalidates the first token after another predetermined amount of time.”); and,
filtering the packet based at least in part on the validation, the filtering being one of:
upon determining that the token is valid, passing the packet towards the receiver (Pane, [0051], “If the demultiplexer 206 determines that the token is valid, the demultiplexer 206 may identify the targeted application server 115a using the private IP address and the port number and forward the ingress packet to the targeted application server 115a”), and
upon failing to determine that the token is valid, at least one of: blocking the packet and generating an alert (Pane, [0050], “If the demultiplexer 206 determines that the token is invalid, the demultiplexer 206 may drop the ingress packet… demultiplexer 206 may drop future ingress packets from the same client device 101 or automatically block the client device 101 IP address… the demultiplexer 206 sends a notification to the client device 101 that the ingress packet is invalid”).
Claim 16 recites a non-transitory computer readable medium holding computer program instructions for execution on at least one hardware processor, the computer program instructions including instructions that upon execution cause at least one computer to perform steps that are substantially similar to the steps of claim 1.
Pane disclosed embodiments including a non-transitory computer readable medium that includes instructions stored thereon that, when executed by one or more computers, cause the one or more computers to perform the steps, as claimed (Pane, [0008]).
Therefore claim 16 is rejected under the same rationale applied above.
Regarding claims 2 and 17, Pane disclosed the method of claim 1, and medium of claim 16, including wherein the field of the packet comprises a header field associated with any of the following network protocols: an IP protocol, a TCP protocol, a UDP protocol, a QUIC protocol (Pane, [0054], “The ingress packet 305 may include IP+UDP headers 310”).
Regarding claim 8, Pane disclosed the method of claim 1, wherein the token represents a value that has been hashed (Pane, [0006], [0041]).
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 3, 6-7, 9-11, 13, 18, 20-21 are rejected under 35 U.S.C. 103 as being unpatentable over Pane et al. (US 20230308475) in view of Madineni et al. (US 20200244441).
Regarding claim 9, Pane disclosed a packet filtering system comprising a client device, a packet filter, and one or more servers (Pane, Fig. 1, 101, 150, 111, 115);
a client device (Pane, Fig. 1, 101) configured to:
insert a token into a field of a packet, the client device sending the field identifiable in cleartext to the one or more servers (Pane, [0009], “receiving, from the client device, an ingress packet at a demultiplexer that corresponds to the VIP address, wherein the ingress packet includes a routing and authentication header, parsing the routing and authentication header to obtain the private IP address, the port number, and the token”; Figure 3, element 315 is a header of the packet that is not encrypted nor obfuscated, and therefore amounts to a field identifiable in cleartext; [0049], “Upon receipt of an ingress packet”; [0051], The packet is directed to a target application server; See Fig. 3 and [0054] “client 301 generates an ingress packet 305 and transmits the ingress packet 305” which includes “a routing and authentication header 315” which “includes a private IP address for the targeted application server 115, a port number, and a signed token”); and,
a packet filter that receives the packet (Pane, [0009], “receiving, from the client device, an ingress packet at a demultiplexer that corresponds to the VIP address, [0049], “Upon receipt of an ingress packet”),
examines the packet to locate the field and to extract the token therefrom (Pane, [0049], “Upon receipt of an ingress packet, the demultiplexer 206 checks the routing and authentication header. If the ingress packet is lacking the routing and authentication header or the routing and authentication head[er] is malformed, the demultiplexer 206 discards the ingress packet. If the routing and authentication header is present and not malformed, the demultiplexer 206 parses the routing and authentication layer to extract the private IP address and the port number for the targeted application server 115a, as well as the token”), and
determines how to filter the packet based at least in part on the validity of the token (Pane, [0049], “The demultiplexer 206 performs authentication of the token”; [0050], “If the demultiplexer 206 determines that the token is invalid, the demultiplexer 206 may drop the ingress packet… demultiplexer 206 may drop future ingress packets from the same client device 101 or automatically block the client device 101 IP address… the demultiplexer 206 sends a notification to the client device 101 that the ingress packet is invalid”; [0051], “If the demultiplexer 206 determines that the token is valid, the demultiplexer 206 may identify the targeted application server 115a using the private IP address and the port number and forward the ingress packet to the targeted application server 115a”).
While Pane disclosed the client device sending the packet with the token, Pane did not explicitly disclose where the client is configured to execute a trust establishment process with one or more servers, and, upon successful completion of the trust establishment process, receive a secret shared between the client and the one or more servers;
obtain a current value of a data element, the data element changing in value over time; and
generate a token based at least in part on a function of the secret and the current value of the data element.
Madineni disclosed a client configured to execute a trust establishment process with one or more servers (Madineni, [0038] Madineni disclosed authenticating device registering with authenticating server; [0041] Synchronizing with the blockchain 120 requires the authenticating device 102 so satisfy one or more access parameters, such as passwords), and, upon successful completion of the trust establishment process, receive a secret shared between the client and the one or more servers (Madineni, [0038], “shared key 104”; [0081] “Shared secret 632 (e.g., shared key 104 of FIG. 1) can be a secret value privately shared by authenticating device 102 and authenticator server 112”);
obtain a current value of a data element, the data element changing in value over time (Madineni, [0040], “Synchronizing the authenticating device 102 with the blockchain 120 includes at least retrieving a current hash value 122 from the blockchain 120.”; [0019] Madineni disclosed the hash value as a “time-based moving factor”; See also [0018], “The moving factor can be, for example, an increasing counter value or an integer representing a number of time steps between an initial counter time and a current time.”);
generate a token based at least in part on a function of the secret and the current value of the data element (Madineni, [0042], “the authenticating device 102 generates a secure token 110 using the shared key 104 and the current hash value 122”).
One of ordinary skill in the art would have been motivated to combine the teachings of Pane and Madineni as they both relate to the utilization of security measures involving tokens with respect to communication (Madineni, [0039], Pane, [0054]), and as such, they are within similar environments.
Therefore it would have been obvious to one of ordinary skill in the art at the time the invention was filed to incorporate the token generation techniques of Madineni within the teachings of Pane in order to provide for additional measures of improved security that are less susceptible to eavesdropping and/or replay attacks (Madineni, [0018]-[0019]), thereby increasing desirability of use by its customers.
Regarding claim 10, Pane and Madineni disclosed the system of claim 9, wherein the field of the packet with the token comprises a header field associated with any of the following network protocols: an IP protocol, a TCP protocol, a UDP protocol, a QUIC protocol (Pane, [0054], “The ingress packet 305 may include IP+UDP headers 310”). See motivation to combine above.
Regarding claim 11, Pane and Madineni disclosed the system of claim 9, including wherein the client device obtains the current value of the data element from a public source (Madineni, [0084]-[0085] and [0099]-[0102], Madineni disclosed the teachings of the invention implemented across public deployment models, and therefore the authenticating server itself reasonable amounts to a public source).
Regarding claim 13, Pane and Madineni disclosed the system of claim 9, including wherein the trust establishment process comprises at least one of: a sender authentication process, a sender authorization process, a sender challenge (Madineni, [0038] Madineni disclosed authenticating device registering with authenticating server; [0041] Synchronizing with the blockchain 120 requires the authenticating device 102 so satisfy one or more access parameters, such as passwords), and, upon successful completion of the trust establishment process, receive a secret shared between the client and the one or more servers (Madineni, [0038], “shared key 104”; [0081] “Shared secret 632 (e.g., shared key 104 of FIG. 1) can be a secret value privately shared by authenticating device 102 and authenticator server 112”).
Regarding claims 3, 18, Pane disclosed the method of claim 1, and medium of claim 16, but did not explicitly disclose wherein the current value of the data element is publicly available.
In an analogous art, Madineni disclosed wherein the current value of the data element is publicly available (Madineni, [0084]-[0085] and [0099]-[0102], Madineni disclosed the teachings of the invention implemented across public deployment models, and therefore the authenticating server itself reasonable amounts to a public source; [0040], “Synchronizing the authenticating device 102 with the blockchain 120 includes at least retrieving a current hash value 122 from the blockchain 120.”; [0019] Madineni disclosed the hash value as a “time-based moving factor”; See also [0018], “The moving factor can be, for example, an increasing counter value or an integer representing a number of time steps between an initial counter time and a current time”).
One of ordinary skill in the art would have been motivated to combine the teachings of Pane and Madineni as they both relate to the utilization of security measures involving tokens with respect to communication (Madineni, [0039], Pane, [0054]), and as such, they are within similar environments.
Therefore it would have been obvious to one of ordinary skill in the art at the time the invention was filed to incorporate the token generation techniques of Madineni within the teachings of Pane in order to provide for additional measures of improved security that are less susceptible to eavesdropping and/or replay attacks (Madineni, [0018]-[0019]), thereby increasing desirability of use by its customers.
Regarding claims 6 and 20, Pane disclosed the method of claim 1, and medium of claim 16, but did not explicitly disclose, prior to said examination of the packet: upon successful trust establishment between sender and receiver, the one or more devices taking at least one of the following actions: (a) providing the secret to the sender, and (b) instructing the sender to insert the token into the field.
Madineni disclosed prior to said examination of the packet: upon successful trust establishment between sender and receiver, the one or more devices taking at least one of the following actions: (a) providing the secret to the sender, and (b) instructing the sender to insert the token into the field (Madineni, [0038] Madineni disclosed authenticating device registering with authenticating server; [0041] Synchronizing with the blockchain 120 requires the authenticating device 102 so satisfy one or more access parameters, such as passwords; [0038], “shared key 104”; [0081] “Shared secret 632 (e.g., shared key 104 of FIG. 1) can be a secret value privately shared by authenticating device 102 and authenticator server 112”).
One of ordinary skill in the art would have been motivated to combine the teachings of Pane and Madineni as they both relate to the utilization of security measures involving tokens with respect to communication (Madineni, [0039], Pane, [0054]), and as such, they are within similar environments.
Therefore it would have been obvious to one of ordinary skill in the art at the time the invention was filed to incorporate the token generation techniques of Madineni within the teachings of Pane in order to provide for additional measures of improved security that are less susceptible to eavesdropping and/or replay attacks (Madineni, [0018]-[0019]), thereby increasing desirability of use by its customers.
Regarding claims 7 and 21, Pane and Madineni disclosed the method of claim 6, and medium of claim 16, wherein the trust establishment process comprises at least one of: a sender authentication process, a sender authorization process, a sender challenge (Madineni, [0038] Madineni disclosed authenticating device registering with authenticating server; [0041] Synchronizing with the blockchain 120 requires the authenticating device 102 so satisfy one or more access parameters, such as passwords), and, upon successful completion of the trust establishment process, receive a secret shared between the client and the one or more servers (Madineni, [0038], “shared key 104”; [0081] “Shared secret 632 (e.g., shared key 104 of FIG. 1) can be a secret value privately shared by authenticating device 102 and authenticator server 112”).
Claim(s) 4, 12 are rejected under 35 U.S.C. 103 as being unpatentable over Pane et al. (US 20230308475) in view of Madineni et al. (US 20200244441) and further in view of Beck et al. (US 20210067377).
Regarding claim 4, Pane disclosed the method of claim 1, but did not explicitly disclose wherein the current value of the data element is publicly available from a DNS server.
In an analogous art, Beck disclosed wherein the current value of the data element is publicly available from a DNS server (Beck [0015], Beck disclosed a receiver device may retrieve a DNS record to obtain nameserver and public key and use such for validation, in which Beck at [0003] allows for key rotation).
One of ordinary skill in the art would have been motivated to combine the teachings of Beck with Pane as they all relate to security solutions involving the use of public keys, and as such are within similar environments.
Therefore it would have been obvious to one of ordinary skill in the art at the time the invention was filed to incorporate the obtaining of the current value of a data element from a DNS server within the teachings of Pane in order to improve the security, performance and functioning of autonomous networks, service provider network, and the network components and user equipment devices that provide or use their services (Beck, [0016]).
Regarding claim 12, Pane and Madineni disclosed the system of claim 9, but did not explicitly disclose wherein the client device obtains the current value of the data element from a DNS server.
In an analogous art, Beck disclosed wherein the client device obtains the current value of the data element from a DNS server (Beck [0015], Beck disclosed a receiver device may retrieve a DNS record to obtain nameserver and public key and use such for validation, in which Beck at [0003] allows for key rotation).
One of ordinary skill in the art would have been motivated to combine the teachings of Beck with Pane and Madineni as they all relate to security solutions involving the use of public keys, and as such are within similar environments.
Therefore it would have been obvious to one of ordinary skill in the art at the time the invention was filed to incorporate the obtaining of the current value of a data element from a DNS server within the teachings of Pane and Madineni in order to improve the security, performance and functioning of autonomous networks, service provider network, and the network components and user equipment devices that provide or use their services (Beck, [0016]).
Claim(s) 5, 14-15, and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Pane et al. (US 20230308475) in view of Madineni et al. (US 20200244441) and further in view of Balle et al. (US 20220321491).
Regarding claim 14, Pane and Madineni disclosed the system of claim 9, including the packet filter determining to perform said examination of the packet to locate the field and extract the token, and determining how to filter the packet based at least in part on the validity of the token (Pane, [0049], “Upon receipt of an ingress packet, the demultiplexer 206 checks the routing and authentication header. If the ingress packet is lacking the routing and authentication header or the routing and authentication head[er] is malformed, the demultiplexer 206 discards the ingress packet. If the routing and authentication header is present and not malformed, the demultiplexer 206 parses the routing and authentication layer to extract the private IP address and the port number for the targeted application server 115a, as well as the token”; [0049], “The demultiplexer 206 performs authentication of the token”; [0050], “If the demultiplexer 206 determines that the token is invalid, the demultiplexer 206 may drop the ingress packet… demultiplexer 206 may drop future ingress packets from the same client device 101 or automatically block the client device 101 IP address… the demultiplexer 206 sends a notification to the client device 101 that the ingress packet is invalid”; [0051], “If the demultiplexer 206 determines that the token is valid, the demultiplexer 206 may identify the targeted application server 115a using the private IP address and the port number and forward the ingress packet to the targeted application server 115a”).
While Pane in view of Madineni disclosed examining the received packet in the manner as claimed, the combination did not first determining that the packet is associated with a beginning of a transport layer flow between the client and one or more servers, and based at least in part on that determination, the packet filter determines to perform examining of the packet.
In an analogous art, Balle disclosed determining that the packet is associated with a beginning of a transport layer flow between the client and one or more servers, and based at least in part on that determination, the packet filter determines to perform examining of the packet (Balle, [0037], Balle disclosed determining that a received packet utilizes a target protocol such as “TCP” and is associated with a new session, and if so, Balle disclosed parsing the header of the packet).
One of ordinary skill in the art would have been motivated to combine the teachings of Pane and Madineni with Balle in order to provide additional filtering criteria for filtering received packets in order to facilitate the processing of received packets while reducing latency or time to complete such processing (Balle, [0020]).
Regarding claim 15, Pane Madineni and Balle disclosed the system of claim 14, the packet filter configured to filter subsequent packets in the transport layer flow in accord with the determination of the token’s validity, irrespective of whether tokens are present in the subsequent packets in the transport layer flow (Balle, [0037], Balle disclosed determining that a received packet utilizes a target protocol such as “TCP” and is associated with a new session, and if so, Balle disclosed parsing the header of the packet; Fig. 8A, Balle disclosed filtering subsequent packets of the same transport layer flow by skipping the need for parsing the header, as shown by the “No” route from 804; When the session is determined to be not a new session, the parsing of 806 is skipped; Utilizing Balle’s decision to only parse header information for TCP flow packets for new session to determine when to apply the parsing of Pane/Madeineni arrives at the limitation as claimed). See motivation above.
Regarding claims 5 and 19, Pane disclosed the method of claim 1, including performing examination of the packet to locate the field and extract the token and determining of the token’s validity (Pane, [0049], “If the routing and authentication header is present and not malformed, the demultiplexer 206 parses the routing and authentication layer to extract the private IP address and the port number for the targeted application server 115a, as well as the token”; [0049], “The demultiplexer 206 performs authentication of the token”; [0050], “If the demultiplexer 206 determines that the token is invalid, the demultiplexer 206 may drop the ingress packet… demultiplexer 206 may drop future ingress packets from the same client device 101 or automatically block the client device 101 IP address… the demultiplexer 206 sends a notification to the client device 101 that the ingress packet is invalid”; [0051], “If the demultiplexer 206 determines that the token is valid, the demultiplexer 206 may identify the targeted application server 115a using the private IP address and the port number and forward the ingress packet to the targeted application server 115a”).
While Pane disclosed parsing the received packets in the manner as claimed, Pane did not disclose prior to said examination of the packet: determining that the packet is associated with a beginning of a transport layer flow between sender and receiver, and based at least in part on that determination, performing said parsing; and, filtering subsequent packets in the transport layer flow in accord with the determination of the token’s validity, irrespective of whether tokens are present in the subsequent packets in the transport layer flow.
In an analogous art, Balle disclosed prior to said examination of the packet: determining that the packet is associated with a beginning of a transport layer flow between sender and receiver, and based at least in part on that determination, performing said parsing (Balle, [0037], Balle disclosed determining that a received packet utilizes a target protocol such as “TCP” and is associated with a new session, and if so, Balle disclosed parsing the header of the packet).; and
filtering subsequent packets in the transport layer flow in accord with the determination of the token’s validity, irrespective of whether tokens are present in the subsequent packets in the transport layer flow (Balle, [0037], Balle disclosed determining that a received packet utilizes a target protocol such as “TCP” and is associated with a new session, and if so, Balle disclosed parsing the header of the packet; Fig. 8A, Balle disclosed filtering subsequent packets of the same transport layer flow by skipping the need for parsing the header, as shown by the “No” route from 804; When the session is determined to be not a new session, the parsing of 806 is skipped).
One of ordinary skill in the art at the time the invention was filed would have been motivated to combine the teachings of Pane and Balle since both provide techniques for parsing received packets. While Pane disclosed a particular manner of parsing packet headers, Balle provides teachings for determining when to parse. As such, the combination would have been obvious to try.
Therefore it would have been obvious to one of ordinary skill in the art at the time the invention was filed to incorporate the decision-making process of Balle for determining when to parse packet headers, within the teachings of Pane, in order to provide additional filtering criteria for filtering received packets thereby facilitating the processing of received packets while reducing latency or time to complete such processing (Balle, [0020]).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JERRY B DENNISON whose telephone number is (571)272-3910. The examiner can normally be reached M-F 8:30-5:50.
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, Hadi Armouche can be reached on 571-270-3618. 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.
/JERRY B DENNISON/Primary Examiner, Art Unit 2409