DETAILED ACTION
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/03/2025 has been entered.
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
The instant first office action is in response to communication filed on 12/03/2025.
Claims 1-20 are pending of which claims 1, 10 and 17 are the base independent claims.
Response to Arguments
Applicant’s arguments with respect to claim(s) 1-20 have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
Further, the amended limitations are in fact taught by the previously cited prior art and/or newly cited prior art. For a detailed explanation on how the previously prior art and/or newly cited prior art reads on the claims as amended, please see the rejection below.”
Claim Rejections - 35 USC § 103
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) 1, 3-5 and 8-9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sergeev (US 2020/0252201) and in view of Chowdry et al (US 2004/0162076).
Regarding claim 1, Sergeev’201 discloses a method comprising:
determining, by a first node(see claim 12, see para.0034, processor operatively connected to a memory) of a network(see fig.2, which shows traffic analyzer 201 as first node of a network), a packet size modulation profile(see para.0048, which discusses one or more series of test IP packets as packet size modulation profile(s), see para.0053, which discusses the one or more series of test IP packets are configured (301) in accordance with an expected cipher device so that the size of each original IP packet is uniquely indicative of its place in the sequence of test IP packets in one or more test series, see fig.4a, 401, see fig.3, 301, thus one or more test series as packet size modulation profile(s) since it indicates a sequence of packet sizes) for use in generating identifiable data packets(see abs& see para.0048, which discusses test traffic comprising one or more series of test IP packets configured, see para.0053, which discusses the one or more series of test IP packets are configured (301) in accordance with an expected cipher device so that the size of each original IP packet is uniquely indicative of its place in the sequence of test IP packets in one or more test series, see also para.0059, see fig.4a, sequence of packet with size, thus identifying each original data packet);
generating, by the first node, a first identifiable data packet addressed to a second node(see fig.2 & see para.0048, which discusses the generated one or more series of test IP packets are sent to end point 101 via egress interface 206 configured to timestamp each IP packet responsive to transmitting a first bit therein, see fig.3, 303 & see para.0064, which shows and discusses successively transmits the packets in the generated series to the cipher, see fig.4a, which shows sizes of original test including 1st packet with size1, thus first identifiable data packet addressed to end point 101 as a second node), wherein generating the first identifiable data packet comprises modulating a first packet size of a first data packet based upon the packet size modulation profile(see fig.4a, which shows 1st packet as first identifiable data packet comprises size1 as first packet size of a first data packet based on test IP packets in series, see para.0064);
transmitting, by the first node and over the network, the first identifiable data packet to the second node(see fig.2 & see para.0048, which discusses the generated one or more series of test IP packets are sent to end point 101 via egress interface 206 configured to timestamp each IP packet responsive to transmitting a first bit therein, see fig.3, 303, fig.4a, which shows sizes of original test including 1st packet with size1); and
receiving, by the first node and from the second node, a second identifiable data packet, comprising a second encrypted payload corresponding to a reply to the first identifiable data packet(see fig.3, 305 & see para.0064, which shows and discusses the traffic analyzer as first node receives the encrypted packet(s) as second identifiable data packet and associates each arrived encrypted packet with a corresponding arrival time stamp (305), see fig.2, which shows end point 101 as second node, see fig.4a, which shows size1 ^matches to 1st packet, see para.0065, which discusses for each given received encrypted packet, traffic analyzer 201 (e.g. monitor 205) uses its packet size to identify a size of a matching original IP packet see para.0049 & see para.0050, thus received encrypted packet(s) second identifiable data packet corresponding to a reply to the 1st packet with size1 first identifiable data packet, thus comprising second encrypted payload since each given received encrypted packet), wherein the first identifiable data packet and the second identifiable data packet are identifiable as a send-reply pair of data packets(see fig.3, for each given received encrypted packet with arrival time stamp TSa, using its size to identify the place of a matching original packet in the transmitted series and a respective departure time stamp TSd, therereby identifying (TSd; TSa) pair 306) without using an encryption key(see para.0020, which discusses end point with no need of decrypting packets therefor, see para.0046, which discusses in the case of a single end point with a cipher device, decryption of encrypted packets requires access to cryptographic keys used by the cipher, such access being, typically, unavailable for providers of infrastructure test, see fig.2, which shows endpoint 101 as single end point with cipher/Decipher 105 but traffic Analyzer does not include cipher/Decipher, thus without using an encryption key since cryptographic/encryption key(s) is unavailable at the traffic analyzer to decrypt a received encrypted packet) based upon the first packet size of the first identifiable data packet and a second packet size of the second identifiable data packet(see para.0049, which discusses match between the arrived encrypted test IP packets and the original test IP packets…for each arrived encrypted test IP packet, data structure 209 is configured to maintain data indicative of a pair of timestamps: arrival timestamp corresponding to time of arrival of a given encrypted test IP packet and departure timestamp corresponding to departure time of a matching original test packet, see fig.4a, which shows size(s) of encrypted IP packet(s) matches size(s) of original test IP packet(s), see also see fig.3, 306 & para.0065 , which discusses for each given received encrypted packet, traffic analyzer 201 (e.g. monitor 205) uses its packet size to identify a size of a matching original IP packet and, accordingly, its place in the transmitted series… traffic analyzer 201 matches arrival timestamp (TS.sub.a) of the given encrypted IP packets and departure timestamp (TS.sub.d) of the corresponding original IP packet and, thereby, identifies (306) the pair (TS.sub.d; Ts.sub.a) indicative of delay in delivery for the respective pair of matching IP packets., thus send-reply pair).
As discussed above, although Sergeev’201 discloses generating, by the first node, a first identifiable data packet addressed to a second node(see fig.2 & see para.0048, which discusses the generated one or more series of test IP packets are sent to end point 101 via egress interface 206 configured to timestamp each IP packet responsive to transmitting a first bit therein, see fig.3, 303 & see para.0064, which shows and discusses successively transmits the packets in the generated series to the cipher, see fig.4a, which shows sizes of original test including 1st packet with size1, thus first identifiable data packet addressed to end point 101 as a second node), Sergeev’201 does not explicitly show the use of “a first encrypted payload” as required by present claimed invention. However, including “a first encrypted payload” would have been obvious to one having ordinary skill in the art as evidenced by Chowdry’076.
In particular, in the same field of endeavor, Chowdry’076 teaches the use of a first encrypted payload(see para.0229, which discuses each transmission pair, i.e. send and receive message pair, are encrypted unique encryption keys, see para.0219, thus comprising a first encrypted payload since sending is encrypted and second encrypted payload since receiving message is encrypted).
In view of the above, having the system of Sergeev’201 and then given the well-established teaching of Chowdry’076, it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the system of Sergeev’201 to include “a first encrypted payload” as taught by Chowdry’076, since Chowdry’076 stated in para.0021+ that such a modification would minimize system overhead and increase the number of connections a proxy server may maintain.
Regarding claim 3, Sergeev’201 discloses determining one or more performance metrics of the network(see fig.3, 307, see para.0066, which discusses Traffic analyzer 201 further uses (307) the identified (TS.sub.d; Ts.sub.a) pairs for calculating statistical latency metrics) based upon: identification of the first identifiable data packet(see fig.3, 303 & see fig.4a, which shows based on 1st packet with size1) and the second identifiable data packet as the send-reply pair of data packets(see fig.3, which shows 305 & see fig.4a, which encrypted IP packet as second identifiable data packet matches size of original IP packet, see para.0049-0050);
one or more first timestamps indicative of one or more first times comprising at least one of:
a time at which the first identifiable data packet is transmitted by the first node(see fig.3, which shows each transmitted packet with a departure time stamp 303); or (due to or language, only one of them being considered) one or more times at which the first identifiable data packet is at least one of received, processed, or transmitted by one or more primary nodes of the network; and
one or more second timestamps indicative of one or more second times comprising at least one of:
a time at which the second identifiable data packet is transmitted by the second node(see fig.3, which shows each arrived encrypted packet with a corresponding time stamp 305); or (due to or language, only one of them being considered) one or more times at which the second identifiable data packet is at least one of received, processed, or transmitted by one or more secondary nodes of the network.
Regarding claim 4, Sergeev’201 discloses wherein the one or more performance metrics comprise at least one(due to at least one, only one of them is being considered) of: a latency metric; a jitter metric; a packet loss metric; a packet retransmission metric; an out-of-order (OOO) packet transmission metric; or a bandwidth metric(see fig.3, 307, see para.0066, which discusses Traffic analyzer 201 further uses (307) the identified (TS.sub.d; Ts.sub.a) pairs for calculating statistical latency metrics).
Regarding claim 5, Sergeev’201 discloses the first packet size corresponds to a size of an encrypted payload in the first identifiable data packet(see fig.4a, which shows size(s) of encrypted IP packet(s) matching size of original test IP packet(s)); and
generating the first identifiable data packet comprises:
determining a first set of bytes for delivery to the second node(see fig.3, 303, see para.0010, which discusses successively transmitting the original packets in the generated series to the ciphering end point, see fig.4a-b);
appending one or more additional bytes to the first set of bytes to generate a second set of bytes(see para.0037, which discusses establishing an encrypted connection with constant-size overhead added to data packets, see para.0041, which discusses for ESP transport mode, such overhead consists of ESP header 113-1, ESP Trailer 113-2 and ESP Authenticator 113-3 and is characterized by a constant size Δ.sub.1=36 bytes; for ESP tunnel mode such overhead consists of New IP Header 114-4, ESP Header 114-1, ESP Trailer 114-2 and ESP Authenticator 114-3 and is characterized by a constant size Δ.sub.2=54 bytes (with no NAT-T); for WireGuard® such overhead consists of New IP header 130-1, UDP header 130-2, WireGuard Message header 130-3 and Authentication Tag 130-4 and is characterized by a constant size Δ.sub.3=60 bytes, see para.0064 and fig.4a, thus constant size bytes to the original packet(s)), wherein a quantity of bytes of the one or more additional bytes(see para.0037, which discusses establishing an encrypted connection with constant-size overhead added to data packets, see para.0064, see fig.4a) is based upon the first packet size(see fig.4a, which shows 1st packet with size1) and a quantity of bytes of the first set of bytes(see fig.4a, which shows size+contanst size triangle, see para.0064, which discusses For example, a 1s.sup.t packet can have any size between the minimal size of IP packet and PTAS*k, thereby corresponding to an encrypted packet with a size PTAS*k+Δ. A second original IP packet can have any size more than PTAS*k and less or equal to PTAS*(k+1), thereby corresponding to an encrypted packet with a size PTAS*(k+1)+Δ. An original IP packet with the sequence number i can have any size more than PTAS*(k+i−2) and less or equal to PTAS*(k+i−1), thereby corresponding to an encrypted packet with a size PTAS*(k+i−1)+Δ); and
encrypting the second set of bytes to generate the encrypted payload(see fig.2, which shows receiving, by the traffic analyzer, the encrypted packets, see fig.4a-4b, which shows encrypted IP payload…constant size overhead of encrypted packet, se also fig.1b-c) ).
Regarding claim 8, Sergeev’201 discloses the second packet size of the second identifiable data packet is equal to the first packet size of the first identifiable data packet(see fig.4a, which show 402, see para.0065, which discusses for each given received encrypted packet, traffic analyzer 201 (e.g. monitor 205) uses its packet size to identify a size of a matching original IP packet).
Regarding claim 9, Sergeev’201 discloses the second identifiable data packet (see fig.3, which shows receiving…encrypted packet(s) 305) an echo reply of the first identifiable data packet(see fig.3, which shows transmitting the packet(s) 303 and 305 in series, thus encrypted packet 305 is an echo reply to transmitted original packet 303).
Claim(s) 2 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sergeev (US 2020/0252201), in view of Chowdry et al (US 2004/0162076) and further in view of Xu et al (US 2019/0075586).
Regarding claims 2, as discussed above, although Sergeev’201 discloses generating, by the first node, a first identifiable data packet addressed to a second node(see fig.2 & see para.0048, which discusses the generated one or more series of test IP packets are sent to end point 101 via egress interface 206 configured to timestamp each IP packet responsive to transmitting a first bit therein, see fig.3, 303 & see para.0064, which shows and discusses successively transmits the packets in the generated series to the cipher, see fig.4a, which shows sizes of original test including 1st packet with size1, thus first identifiable data packet addressed to end point 101 as a second node), Sergeev’201 does not explicitly show the use of “the first node comprises a User Equipment (UE)” as required by present claimed invention. However, including “the first node comprises a User Equipment (UE)” would have been obvious to one having ordinary skill in the art as evidenced by Chowdry’076.
In particular, in the same field of endeavor, Chowdry’076 teaches the use of the first node comprises a User Equipment (UE) (see para.0154, which discusses Wireless device 100 may, for example, be a cellular phone, personal digital assistant ("PDA"), or other wireless device adapted to connect to the Internet via cellular facilities 112 maintained by a wireless carrier, thus cellular phone, personal digital assistant ("PDA") as UE).
In view of the above, having the system of Sergeev’201 and then given the well-established teaching of Chowdry’076, it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the system of Sergeev’201 to include “the first node comprises a User Equipment (UE)” as taught by Chowdry’076, since Chowdry’076 stated in para.0021+ that such a modification would minimize system overhead and increase the number of connections a proxy server may maintain.
Although the combined system of Sergeev’201 and Chowdry’076 discloses the first node comprises a User Equipment (UE) (Chowdry’076, see para.0154, which discusses Wireless device 100 may, for example, be a cellular phone, personal digital assistant ("PDA"), or other wireless device adapted to connect to the Internet via cellular facilities 112 maintained by a wireless carrier, thus cellular phone, personal digital assistant ("PDA") as UE), the combined system of Sergeev’201 and Chowdry’076 does not explicitly show the use of “the second node comprises a Multi-Access Edge Computing (MEC) device” as required by present claimed invention. However, including “the second node comprises a Multi-Access Edge Computing (MEC) device” would have been obvious to one having ordinary skill in the art as evidenced by Xu’586.
In particular, in the same field of endeavor, Xu’586 teaches the use of the first node comprises a User Equipment (UE (see fig.1, which shows UE 1); and the second node comprises a Multi-Access Edge Computing (MEC) device(see fig.1, which shows MEC server 5, see abs, which discusses an external node (5) determines a total size of a plurality of data packets to be transmitted in a first communication event of a first radio terminal (1), see para.0014, the total size of data to be transmitted through a downlink (DL) or an uplink (UL) in a single communication event between the application layer of a radio terminal and the MEC application, see para.0053, which discusses the total size of the plurality of data packets may indicate the total size of DL data packets of DL transmission and the total size of UL data packets of UL transmission in one communication event, see para.0005).
In view of the above, having the combined system of Sergeev’201 and Chowdry’076 and then given the well-established teaching of Xu’586, it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the combined system of Sergeev’201 and Chowdry’076 to include “the second node comprises a Multi-Access Edge Computing (MEC) device” as taught by Xu’586, since Xu’586 stated in para.0025+ that such a modification would contribute to an improvement for adapting packet scheduling to communication performed by an application of a radio terminal.
Claim(s) 6-7 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sergeev (US 2020/0252201), in view of Chowdry et al (US 2004/0162076) and in view of Fan et al (US 2011/0013680).
Regarding claim 6, as discussed above, although the combined system of Sergeev’201 and Chowdry’076 discloses header and packet size(Sergeev’201, see fig.1b-c, and fig.4a-b), the combined system of Sergeev’201 and Chowdry’076 does not explicitly show the use of “including, in a header of the first identifiable data packet, an indication of the first packet size” as required by present claimed invention. However, including “including, in a header of the first identifiable data packet, an indication of the first packet size” would have been obvious to one having ordinary skill in the art as evidenced by Fan’680.
In particular, in the same field of endeavor, Fan’680 teaches the use of including, in a header of the first identifiable data packet, an indication of the first packet size(see para.0014, which discusses each encrypted voice packet comprises an encrypted content section and an unencrypted head section, and the unencrypted head section also comprises a source address field, a destination address field, and a packet size field).
In view of the above, having the combined system of Sergeev’201 and Chowdry’076 and then given the well-established teaching of Fan’680, it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the combined system of Sergeev’201 and Chowdry’076 to include “including, in a header of the first identifiable data packet, an indication of the first packet size” as taught by Fan’680, since Fan’680 stated in para.0046+ that such a modification would improve the utilization rate of the limited bandwidth in cable modem.
Regarding claim 7 as discussed above, although the combined system of Sergeev’201 and Chowdry’076 discloses header is neither modified nor encrypted and packet size(see fig.1b-c, and fig.4a-b, see para.0038), the combined system of Sergeev’201 and Chowdry’076 does not explicitly show the use of “the header, comprising the indication of the first packet size, is unencrypted” as required by present claimed invention. However, including “the header, comprising the indication of the first packet size, is unencrypted” would have been obvious to one having ordinary skill in the art as evidenced by Fan’680.
In particular, in the same field of endeavor, Fan’680 teaches the use of the header, comprising the indication of the first packet size, is unencrypted (see para.0014, which discusses each encrypted voice packet comprises an encrypted content section and an unencrypted head section, and the unencrypted head section also comprises a source address field, a destination address field, and a packet size field).
In view of the above, having the combined system of Sergeev’201 and Chowdry’076 and then given the well-established teaching of Fan’680, it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the combined system of Sergeev’201 and Chowdry’076 to include “the header, comprising the indication of the first packet size, is unencrypted” as taught by Fan’680, since Fan’680 stated in para.0046+ that such a modification would improve the utilization rate of the limited bandwidth in cable modem.
Claim(s) 11-12 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sergeev (US 2020/0252201) and in view of Dillon et al (US 2019/0158371).
Regarding claims 11, as discussed above, although Sergeev’201 discloses Control block 203 is configured to manage traffic generator 204 (e.g. to configure rate, size and other parameters of original test packets, etc.) (see para.0050), Sergeev’201 does not explicitly show the use of “modifying one or more parameters of one or more components of the network based upon the one or more performance metrics” as required by present claimed invention. However, including “modifying one or more parameters of one or more components of the network based upon the one or more performance metrics” would have been obvious to one having ordinary skill in the art as evidenced by Dillon’371.
In particular, in the same field of endeavor, Dillon’371 teaches the use of modifying one or more parameters of one or more components of the network based upon the one or more performance metrics (see fig.17, which discusses modifying by decreasing target tx rate or RX rate by percentage based on rate of the latency increase, see para.0069).
In view of the above, having the system of Sergeev’201 and then given the well-established teaching of Dillon’371, it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the system of Sergeev’201 to include “modifying one or more parameters of one or more components of the network based upon the one or more performance metrics” as taught by Dillon’371, since Dillon’371 stated in para.0008+ that such a modification would achieves improved network performance (e.g., latency, jitter, throughput) through ordinary-grade (e.g., consumer-grade) broadband connections over conventional broadband networks, facilitating support of application-level quality of service traffic requirements (e.g., traffic requirements of real-time service applications, such as voice-over-IP (VOIP) services) through such ordinary-grade broadband connections over conventional broadband networks.
Regarding claim 12, Sergeev’201 discloses comparing a performance metric, of the one or more performance metrics, with a performance metric threshold(see para.0050, which discusses Control block 203 can be configured to obtain such data responsive to predefined events (e.g. responsive to an external request in a pull mode, when the calculated latency exceeds a predefined threshold in a push mode, etc, thus comparing since the calculated latency exceeds a predefined threshold).
As discussed above, although Sergeev’201 discloses comparing a performance metric, of the one or more performance metrics, with a performance metric threshold(see para.0050, which discusses Control block 203 can be configured to obtain such data responsive to predefined events (e.g. responsive to an external request in a pull mode, when the calculated latency exceeds a predefined threshold in a push mode, etc, thus comparing since the calculated latency exceeds a predefined threshold), Sergeev’201 does not explicitly show the use of “in response to determining that the performance metric does not meet the performance metric threshold, at least one of: modifying network resources, of the network, allocated for at least one of the first node or the second node; switching a network slice assigned to at least one of the first node or the second node; modifying one or more Quality of Service (QOS) parameters associated with at least one of the first node or the second node; or increasing a priority of traffic of at least one of the first node or the second node” as required by present claimed invention. However, including “in response to determining that the performance metric does not meet the performance metric threshold, at least one of: modifying network resources, of the network, allocated for at least one of the first node or the second node; switching a network slice assigned to at least one of the first node or the second node; modifying one or more Quality of Service (QOS) parameters associated with at least one of the first node or the second node; or increasing a priority of traffic of at least one of the first node or the second node” would have been obvious to one having ordinary skill in the art as evidenced by Dillon’371.
In particular, in the same field of endeavor, Dillon’371 teaches the use of comparing a performance metric, of the one or more performance metrics, with a performance metric threshold(see fig.17, which shows current latency exceed threshold, thus comparing); in response to determining that the performance metric does not meet the performance metric threshold(see fig.17, which shows when the current latency exceed threshold is yes, thus not meeting since it exceeds), at least one(due to at least one, only of them is being considered) of:
modifying network resources, of the network, allocated for at least one of the first node or the second node(see fig.17, which discusses modifying by decreasing target tx rate or RX rate by percentage based on rate of the latency increase, see para.0069);
switching a network slice assigned to at least one of the first node or the second node;
modifying one or more Quality of Service (QOS) parameters associated with at least one of the first node or the second node; or
increasing a priority of traffic of at least one of the first node or the second node.
In view of the above, having the system of Sergeev’201 and then given the well-established teaching of Dillon’371, it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the system of Sergeev’201 to include “in response to determining that the performance metric does not meet the performance metric threshold, at least one of: modifying network resources, of the network, allocated for at least one of the first node or the second node; switching a network slice assigned to at least one of the first node or the second node; modifying one or more Quality of Service (QOS) parameters associated with at least one of the first node or the second node; or increasing a priority of traffic of at least one of the first node or the second node” as taught by Dillon’371, since Dillon’371 stated in para.0008+ that such a modification would achieves improved network performance (e.g., latency, jitter, throughput) through ordinary-grade (e.g., consumer-grade) broadband connections over conventional broadband networks, facilitating support of application-level quality of service traffic requirements (e.g., traffic requirements of real-time service applications, such as voice-over-IP (VOIP) services) through such ordinary-grade broadband connections over conventional broadband networks.
Claim(s) 14 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sergeev (US 2020/0252201) and in view of Hirasawa et al (US 2023/0074703).
Regarding claim 14, Sergeev’201 discloses wherein: determining the one or more first timestamps and the one or more second timestamps(see fig.3, 306-307, see para.0065, which discusses traffic analyzer 201 matches arrival timestamp (TS.sub.a) of the given encrypted IP packets and departure timestamp (TS.sub.d) of the corresponding original IP packet and, thereby, identifies (306) the pair (TS.sub.d; Ts.sub.a) indicative of delay in delivery for the respective pair of matching IP packets) is performed via one or(due to or language, only one of them is being considered) more first probes connected to one or more nodes of the network(see para.0047, which discusses traffic analyzer 201 can be configured as a probe using a mirrored traffic for monitoring egress interface, thus via probe).
Regarding claims 14, as discussed above, although the system of Sergeev’201 discloses timestamp associated with transmitting packets and timestamp associated with receiving encrypted packet between first and second node(see fig.3, 303, 305-306), the system of Sergeev’201 does not explicitly show the use of “the one or more performance metrics comprise a first performance metric associated with a first network segment, of the network, between a third node of the one or more nodes and the second node; and the first performance metric is determined based upon: a first timestamp, of the one or more first timestamps, corresponding to a time at which the first identifiable data packet is at least one of received, processed, or transmitted by the third node; and a second timestamp, of the one or more second timestamps, corresponding to a time at which the second identifiable data packet is at least one of received, processed, or transmitted by the third node” as required by present claimed invention. However, including “the one or more performance metrics comprise a first performance metric associated with a first network segment, of the network, between a third node of the one or more nodes and the second node; and the first performance metric is determined based upon: a first timestamp, of the one or more first timestamps, corresponding to a time at which the first identifiable data packet is at least one of received, processed, or transmitted by the third node; and a second timestamp, of the one or more second timestamps, corresponding to a time at which the second identifiable data packet is at least one of received, processed, or transmitted by the third node” would have been obvious to one having ordinary skill in the art as evidenced by Hirasawa’703.
In particular, in the same field of endeavor, Hirasawa’703 teaches the use of the one or more performance metrics comprise a first performance metric associated with a first network segment, of the network, between a third node of the one or more nodes and the second node(see at least fig.2, see para.0037, which discusses latency time information Y4d for the round-trip in the segment between the second router 2r and the third router 3r is obtained as a specific segment indicated by the arrow Y4, thus first segment between second router and third router); and
the first performance metric is determined(see para.0037, 0051, see fig.2) based upon:
a first timestamp, of the one or more first timestamps, corresponding to a time at which the first identifiable data packet is at least one of received, processed, or transmitted by the third node(see fig..4, which discusses record transmission timestamp as first timestamp in packet when packet is transmitted); and
a second timestamp, of the one or more second timestamps, corresponding to a time at which the second identifiable data packet is at least one of received, processed, or transmitted by the third node(see fig.4, which shows record reception timestamp as second timestamp in packet when packet is received).
In view of the above, having the system of Sergeev’201 and Dillon ‘371 and then given the well-established teaching of Hirasawa’703, it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the system of Sergeev’201 to include “the one or more performance metrics comprise a first performance metric associated with a first network segment, of the network, between a third node of the one or more nodes and the second node; and the first performance metric is determined based upon: a first timestamp, of the one or more first timestamps, corresponding to a time at which the first identifiable data packet is at least one of received, processed, or transmitted by the third node; and a second timestamp, of the one or more second timestamps, corresponding to a time at which the second identifiable data packet is at least one of received, processed, or transmitted by the third node” as taught by Hirasawa’703, since Hirasawa’703 stated in para.0017+ that such a modification would provide an improved system such that a latency in a specific router segment on a communication network can be accurately measured at low equipment costs.
Claim(s) 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sergeev (US 2020/0252201) and further in view of Xu et al (US 2019/0075586).
Regarding claim 15, as discussed above, although Sergeev’201 discloses first node 201 and second node 101(see fig.2), Sergeev’201 does not explicitly show the use of “the first node comprises a User Equipment (UE); and the second node comprises a Multi-Access Edge Computing (MEC) device” as required by present claimed invention. However, including “the first node comprises a User Equipment (UE); and the second node comprises a Multi-Access Edge Computing (MEC) device” would have been obvious to one having ordinary skill in the art as evidenced by Xu’586.
In particular, in the same field of endeavor, Xu’586 teaches the use of the the first node comprises a User Equipment (UE (see fig.1, which shows UE 1); and the second node comprises a Multi-Access Edge Computing (MEC) device(see fig.1, which shows MEC server 5, see abs, which discusses an external node (5) determines a total size of a plurality of data packets to be transmitted in a first communication event of a first radio terminal (1), see para.0014, the total size of data to be transmitted through a downlink (DL) or an uplink (UL) in a single communication event between the application layer of a radio terminal and the MEC application, see para.0053, which discusses the total size of the plurality of data packets may indicate the total size of DL data packets of DL transmission and the total size of UL data packets of UL transmission in one communication event, see para.0005).
In view of the above, having the system of Sergeev’201 and then given the well-established teaching of Xu’586, it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the system of Sergeev’201 to include “the first node comprises a User Equipment (UE); and the second node comprises a Multi-Access Edge Computing (MEC) device” as taught by Xu’586, since Xu’586 stated in para.0025+ that such a modification would contribute to an improvement for adapting packet scheduling to communication performed by an application of a radio terminal.
Claim(s) 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Sergeev (US 2020/0252201) and in view of Fan et al (US 2011/0013680).
Regarding claim 19, as discussed above, although Sergeev’201 header and packet size(see fig.1b-c, and fig.4a-b), Sergeev’201 does not explicitly show the use of “including, in a header of the first identifiable data packet, an indication of the first packet size” as required by present claimed invention. However, including “including, in a header of the first identifiable data packet, an indication of the first packet size” would have been obvious to one having ordinary skill in the art as evidenced by Fan’680.
In particular, in the same field of endeavor, Fan’680 teaches the use of including, in a header of the first identifiable data packet, an indication of the first packet size(see para.0014, which discusses each encrypted voice packet comprises an encrypted content section and an unencrypted head section, and the unencrypted head section also comprises a source address field, a destination address field, and a packet size field).
In view of the above, having the system of Sergeev’201 and then given the well-established teaching of Fan’680, it would have been obvious to one having ordinary skill in the art before the effective filling date of the claimed invention to modify the system of Sergeev’201 to include “including, in a header of the first identifiable data packet, an indication of the first packet size” as taught by Fan’680, since Fan’680 stated in para.0046+ that such a modification would improve the utilization rate of the limited bandwidth in cable modem.
Claim Rejections - 35 USC § 102
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) 10, 13, 16-18 and 20 is/are rejected under 35 U.S.C. 102(a)(1)as being anticipated by Sergeev (US 2020/0252201).
Regarding claim 10, Sergeev’201 discloses a method, comprising:
identifying a first transmission, over a network, of a first identifiable data packet from a first node to a second node(see fig.2 & see para.0048, which discusses the generated one or more series of test IP packets are sent to end point 101 via egress interface 206 configured to timestamp each IP packet responsive to transmitting a first bit therein, see fig.3, 303 & see para.0064, which shows and discusses successively transmits the packets in the generated series to the cipher, see fig.4a, which shows sizes of original test including 1st packet with size1, see para.0002, over packet data network, thus first identifiable data packet addressed to end point 101 as a second node);
identifying a second transmission, over the network, of a second identifiable data packet from the second node to the first node(see fig.3, 305 & see para.0064, which shows and discusses the traffic analyzer as first node receives the encrypted packet(s) as second identifiable data packet and associates each arrived encrypted packet with a corresponding arrival time stamp (305), see fig.2, which shows end point 101 as second node, see fig.4a, which shows size1 ^matches to 1st packet, see para.0065, which discusses for each given received encrypted packet, traffic analyzer 201 (e.g. monitor 205) uses its packet size to identify a size of a matching original IP packet see para.0049 & see para.0050, thus received encrypted packet(s) second identifiable data packet corresponding to a reply to the 1st packet with size1 first identifiable data packet, see para.0002, over packet data network);
determining, without using an encryption key(see para.0020, which discusses end point with no need of decrypting packets therefor, see para.0046, which discusses in the case of a single end point with a cipher device, decryption of encrypted packets requires access to cryptographic keys used by the cipher, such access being, typically, unavailable for providers of infrastructure test, see fig.2, which shows endpoint 101 as single end point with cipher/Decipher 105 but traffic Analyzer does not include cipher/Decipher, thus without using an encryption key since cryptographic/encryption key(s) is unavailable at the traffic analyzer to decrypt a received encrypted packet) and based upon a first packet size indicated by a first header of the first identifiable data packet(see fig.3, the size of each original packet is uniquely indicative of its place in the sequence of test packets 301, transmitting packet(s)…while associating each transmitted packet with a departure time tamp 303 , see 1st packet with size1, see fig.4A, which show 1st packet size 1 original IP payload + IP HDR, see fig.1b & see para.0038) and a second packet size indicated by a second header of the second identifiable data packet(see fig.3, the encrypted packet and associated each arrived encrypted packet with a corresponding arrival time…305, see fig.4A, which show encrypted IP payload + IP HDR (plain or encrypted) with size1 +constant indicative 1s packet , see fig.1b & see para.0038), that the first identifiable data packet and the second identifiable data packet are a send-reply pair of data packets(see fig.3, which shows the size of each encrypted packet uniquely corresponds to the size of the respective original packet 301… for each given received encrypted packet with arrival, using its size to identify the pace of a matching original packet in the transmitted in series and respective departure time, thereby identify (TSd, TSa) pair 306, see para.0064-0065, thereby identify pair, thus send-reply pair);
determining one or(due to or language, only one of them is being considered) more first timestamps associated with the first transmission of the first identifiable data packet(see fig.3& para.0065, discusses traffic analyzer 201 matches arrival timestamp (TS.sub.a) of the given encrypted IP packets and departure timestamp (TS.sub.d) of the corresponding original IP packet and, thereby, identifies (306) the pair (TS.sub.d; Ts.sub.a) indicative of delay in delivery for the respective pair of matching IP packets, thus departure timestamp (TS.sub.d) as first timestamps of the corresponding original IP packet);
determining one or(due to or language, only one of them is being considered) more second timestamps associated with the second transmission of the second identifiable data packet(see fig.3& para.0065, discusses traffic analyzer 201 matches arrival timestamp (TS.sub.a) of the given encrypted IP packets and departure timestamp (TS.sub.d) of the corresponding original IP packet and, thereby, identifies (306) the pair (TS.sub.d; Ts.sub.a) indicative of delay in delivery for the respective pair of matching IP packets, thus arrival timestamp (TS.sub.a) as second timestamp of the given encrypted IP packets); and
determining one or(due to or language, only of them is being considered) more performance metrics(see para.0066, which discusses Traffic analyzer 201 further uses (307) the identified (TS.sub.d; Ts.sub.a) pairs for calculating statistical latency metrics), associated with the send-reply pair of data packets(see fig.3305), based upon the one or more first timestamps and the one or more second timestamps (see para.0066, which discusses trraffic analyzer 201 further uses (307) the identified (TS.sub.d; Ts.sub.a) pairs for calculating statistical latency metrics and for corresponding latency assessment. (TS.sub.d; Ts.sub.a) pairs can be used for latency metrics and/or latency assessment in accordance with, see fig.3, 305-307, based on arrival timestamp (TS.sub.a) as second timestamp of the given encrypted IP packets and departure timestamp (TS.sub.d) as first timestamps of the corresponding original IP packet).
Regarding claim 13, Sergeev’201 discloses wherein: determining that the first identifiable data packet and the second identifiable data packet are a send-reply pair of data packets(see fig.3-4b) comprises:
analyzing a send-reply pair identification data structure(see para.0065, which discusses traffic analyzer 201 (e.g. monitor 205) uses its packet size to identify a size of a matching original IP packet and, accordingly, its place in the transmitted series…for a given encrypted packet with size.sub.e, traffic analyzer 201 can calculate size.sub.o of corresponding original IP packet (size.sub.o=size.sub.e−Δ), wherein the size.sub.o uniquely identifies the place of the corresponding original IP packet in the transmitted sequence, thus traffic analyzer analyze by monitoring packet size of original packet and encrypted packet to identify send-reply pair identification data structure), indicative of a plurality of pairs of packet sizes, based upon the first packet size and the second packet size(see fig.3, the size of each original packet is uniquely indicative of its place in the sequence of the test packets and the size of each encrypted packet uniquely corresponds/match to the size of respective respectively 301 and for each given received encrypted packet with arrival time, using its size to identify the place of a matching original packet in the transmitted series and a respective departure time stamp TSd 301 and 306); and
determining that the first identifiable data packet and the second identifiable data packet are the send-reply pair of data packets(see fig.3, 306-307 & see para.0065, which discusses traffic analyzer 201 matches arrival timestamp (TS.sub.a) of the given encrypted IP packets and departure timestamp (TS.sub.d) of the corresponding original IP packet and, thereby, identifies (306) the pair (TS.sub.d; Ts.sub.a) indicative of delay in delivery for the respective pair of matching IP packets, see fig.4a, 401-402) based upon a determination that the first packet size and the second packet size match a pair of packet sizes of the plurality of pairs of packet sizes(see fig.3, which shows the size of each original packet is uniquely indicative of its place in the sequence of the test packets and the size of each encrypted packet uniquely corresponds/match to the size of respective respectively 301, 306, see claim 1, which discuses using a size of a given encrypted packet with a timestamp TS.sub.a to identify a size of a matching original packet, thus, based determination that the first packet size and the second packet size match a pair of packet sizes of the plurality of pairs of packet sizes, see fig.4a, 401-402).
Regarding claim 16, Sergeev’201 discloses wherein the one or(due to or language, only one of them is being considered) more performance metrics comprise at least one of: a latency metric; a jitter metric; a packet loss metric; a packet retransmission metric; an out-of-order (OOO) packet transmission metric; or a bandwidth metric(see para.0066, which discusses latency metric(s)).
Regarding claim 17, Sergeev’201 discloses a computer comprising:
a processor coupled to memory, the processor configured to execute instructions from the memory to perform operations (see para.0070, which discusses s a computer program being readable by a computer for executing the method of the invention. The invention further contemplates a non-transitory computer-readable memory tangibly embodying a program of instructions executable by the computer for executing the method of the invention, see claim 12, which discuss processor and memory block, see claim 20, see para.0034, processor operatively connected to a memory)comprising:
determining a packet size modulation profile(see para.0048, which discusses one or more series of test IP packets as packet size modulation profile(s), see para.0053, which discusses the one or more series of test IP packets are configured (301) in accordance with an expected cipher device so that the size of each original IP packet is uniquely indicative of its place in the sequence of test IP packets in one or more test series, see fig.4a, 401, see fig.3, 301, thus one or more test series as packet size modulation profile(s) since it indicates a sequence of packet sizes) for use in generating identifiable data packets(see abs& see para.0048, which discusses test traffic comprising one or more series of test IP packets configured, see para.0053, which discusses the one or more series of test IP packets are configured (301) in accordance with an expected cipher device so that the size of each original IP packet is uniquely indicative of its place in the sequence of test IP packets in one or more test series, see also para.0059, see fig.4a, sequence of packet with size, thus identifying each original data packet);
generating, based on upon the packet size modulation size profile, a first identifiable data packet having a first packet size(see fig.2 & see para.0048, which discusses the generated one or more series of test IP packets are sent to end point 101 via egress interface 206 configured to timestamp each IP packet responsive to transmitting a first bit therein, see fig.3, 303 & see para.0064, which shows and discusses successively transmits the packets in the generated series to the cipher, see fig.4a, which shows sizes of original test including 1st packet with size1, thus first identifiable data packet addressed to end point 101 as a second node), wherein the first identifiable data packet is addressed to a node of a network(see fig.2 & see para.0048, which discusses the generated one or more series of test IP packets are sent to end point 101 via egress interface 206 configured to timestamp each IP packet responsive to transmitting a first bit therein) and comprises a first header indicating the first packet size(see fig.4a, which shows 1st packet as first identifiable data packet comprises size1 as first packet size of a first data packet based on test IP packets in series, see para.0064, see fig.4A, which show original IP payload + IP HDR with size 1 indicating 1st packet size 1, see fig.1b & see para.0038);
transmitting, over the network, the first identifiable data packet to the node(see fig.2 & see para.0048, which discusses the generated one or more series of test IP packets are sent to end point 101 via egress interface 206 configured to timestamp each IP packet responsive to transmitting a first bit therein, see fig.3, 303, fig.4a, which shows sizes of original test including 1st packet with size1); and
receiving, from the second node, a second identifiable data packet corresponding to a reply to the first identifiable data packet(see fig.3, 305 & see para.0064, which shows and discusses the traffic analyzer as first node receives the encrypted packet(s) as second identifiable data packet and associates each arrived encrypted packet with a corresponding arrival time stamp (305), see fig.2, which shows end point 101 as second node, see fig.4a, which shows size1 ^matches to 1st packet, see para.0065, which discusses for each given received encrypted packet, traffic analyzer 201 (e.g. monitor 205) uses its packet size to identify a size of a matching original IP packet see para.0049 & see para.0050, thus received encrypted packet(s) second identifiable data packet corresponding to a reply to the 1st packet with size1 first identifiable data packet, thus comprising second encrypted payload since each given received encrypted packet) and comprising a second header indicating a second packet size (see fig.4A, which shows encrypted IP payload +HDR(plain or encrypted) indicated Size 1+constant matches to 1st packet , see fig.1b & see para.0038), wherein the first identifiable data packet(see fig.3, the size of each original packet is uniquely indicative of its place in the sequence of test packets 301, transmitting packet(s)…while associating each transmitted packet with a departure time tamp 303 , see 1st packet with size1, see fig.4A, which show 1st packet size 1 original IP payload + IP HDR, see fig.1b & see para.0038) and the second identifiable data packet, at least one(due to one language, only one of them is being considered) of which comprise an encrypted payload,(see fig.3, the encrypted packet and associated each arrived encrypted packet with a corresponding arrival time…305) are identifiable as a send-reply pair of data packets(see fig.3, which shows the size of each encrypted packet uniquely corresponds to the size of the respective original packet 301… for each given received encrypted packet with arrival, using its size to identify the pace of a matching original packet in the transmitted in series and respective departure time, thereby identify (TSd, TSa) pair 306, see para.0064-0065, thereby identify pair, thus send-reply pair) without using an encryption key(see para.0020, which discusses end point with no need of decrypting packets therefor, see para.0046, which discusses In the case of a single end point with a cipher device, decryption of encrypted packets requires access to cryptographic keys used by the cipher, such access being, typically, unavailable for providers of infrastructure test, see fig.2, which shows endpoint 101 as single end point with cipher/Decipher 105 but traffic Analyzer does not include cipher/Decipher, thus without using an encryption key since cryptographic/encryption key(s) is unavailable at the traffic analyzer to decrypt a received encrypted packet) based upon the first packet size indicated by the first header of the first identifiable data packet(see fig.3, the size of each original packet is uniquely indicative of its place in the sequence of test packets 301, transmitting packet(s)…while associating each transmitted packet with a departure time tamp 303 , see 1st packet with size1, see fig.4A, which show original IP payload + IP HDR size1 indicating 1st packet size 1, see fig.1b & see para.0038) and the second packet size indicated by the second header of the second identifiable data packet(see fig.3, the encrypted packet and associated each arrived encrypted packet with a corresponding arrival time…305, see fig.4A, which shows encrypted IP payload +HDR(plain or encrypted) with Size 1+constant indicates/matches to 1st packet , see fig.1b & see para.0038, see para.0049, which discusses match between the arrived encrypted test IP packets and the original test IP packets…for each arrived encrypted test IP packet, data structure 209 is configured to maintain data indicative of a pair of timestamps: arrival timestamp corresponding to time of arrival of a given encrypted test IP packet and departure timestamp corresponding to departure time of a matching original test packet, see fig.4a, which shows size(s) of encrypted IP packet(s) matches size(s) of original test IP packet(s), see also see fig.3, 306 & para.0065, which discusses for each given received encrypted packet, traffic analyzer 201 (e.g. monitor 205) uses its packet size to identify a size of a matching original IP packet and, accordingly, its place in the transmitted series… traffic analyzer 201 matches arrival timestamp (TS.sub.a) of the given encrypted IP packets and departure timestamp (TS.sub.d) of the corresponding original IP packet and, thereby, identifies (306) the pair (TS.sub.d; Ts.sub.a) indicative of delay in delivery for the respective pair of matching IP packets., thus send-reply pair, see fig.4A, which show each of original IP payload + IP HDR indicating 1st packet size 1 and 2nd packet size, see fig.1b & see para.0038).
Regarding claim 18, Sergeev’201 discloses the first packet size corresponds to a size of an encrypted payload in the first identifiable data packet(see fig.4a, which shows size(s) of encrypted IP packet(s) matching size of original test IP packet(s)); and
generating the first identifiable data packet comprises:
determining a first set of bytes for delivery to the second node(see fig.3, 303, see para.0010, which discusses successively transmitting the original packets in the generated series to the ciphering end point, see fig.4a-b);
appending one or more additional bytes to the first set of bytes to generate a second set of bytes(see para.0037, which discusses establishing an encrypted connection with constant-size overhead added to data packets, see para.0041, which discusses for ESP transport mode, such overhead consists of ESP header 113-1, ESP Trailer 113-2 and ESP Authenticator 113-3 and is characterized by a constant size Δ.sub.1=36 bytes; for ESP tunnel mode such overhead consists of New IP Header 114-4, ESP Header 114-1, ESP Trailer 114-2 and ESP Authenticator 114-3 and is characterized by a constant size Δ.sub.2=54 bytes (with no NAT-T); for WireGuard® such overhead consists of New IP header 130-1, UDP header 130-2, WireGuard Message header 130-3 and Authentication Tag 130-4 and is characterized by a constant size Δ.sub.3=60 bytes, see para.0064 and fig.4a, thus constant size bytes to the original packet(s)), wherein a quantity of bytes of the one or more additional bytes(see para.0037, which discusses establishing an encrypted connection with constant-size overhead added to data packets, see para.0064, see fig.4a) is based upon the first packet size(see fig.4a, which shows 1st packet with size1) and a quantity of bytes of the first set of bytes(see fig.4a, which shows size+contanst size triangle, see para.0064, which discusses For example, a 1s.sup.t packet can have any size between the minimal size of IP packet and PTAS*k, thereby corresponding to an encrypted packet with a size PTAS*k+Δ. A second original IP packet can have any size more than PTAS*k and less or equal to PTAS*(k+1), thereby corresponding to an encrypted packet with a size PTAS*(k+1)+Δ. An original IP packet with the sequence number i can have any size more than PTAS*(k+i−2) and less or equal to PTAS*(k+i−1), thereby corresponding to an encrypted packet with a size PTAS*(k+i−1)+Δ); and
encrypting the second set of bytes to generate the encrypted payload(see fig.2, which shows receiving, by the traffic analyzer, the encrypted packets, see fig.4a-4b, which shows encrypted IP payload…constant size overhead of encrypted packet, se also fig.1b-c).
Regarding claim 20, Sergeev’201 discloses wherein: the first identifiable data packet and the second identifiable data packet(see fig.3, 301 & see fig.4a, which shows 1st identifiable data with size and encrypted 1st packet as second identifiable data packet) are identifiable as a send-reply pair of data packets(see para.0010, which discuses respective pair of matching packets) based upon a pair of packet sizes(see fig.3, which shows pair of packet sizes including original packet(s) and encrypted packet(s)) indicated by a send-reply pair identification data structure(see fig.3, which shows the size of each original packet is uniquely indicative of its place in the sequence of the test packets and the size of each encrypted packet uniquely corresponds/match to the size of respective respectively 301, 306, see claim 1, which discuses using a size of a given encrypted packet with a timestamp TS.sub.a to identify a size of a matching original packet).
determining that the first identifiable data packet and the second identifiable data packet are the send-reply pair of data packets(see fig.3, 306-307 & see para.0065, which discusses traffic analyzer 201 matches arrival timestamp (TS.sub.a) of the given encrypted IP packets and departure timestamp (TS.sub.d) of the corresponding original IP packet and, thereby, identifies (306) the pair (TS.sub.d; Ts.sub.a) indicative of delay in delivery for the respective pair of matching IP packets) based upon a determination that the first packet size and the second packet size match a pair of packet sizes of the plurality of pairs of packet sizes(see fig.3, which shows the size of each original packet is uniquely indicative of its place in the sequence of the test packets and the size of each encrypted packet uniquely corresponds/match to the size of respective respectively 301, 306, see claim 1, which discuses using a size of a given encrypted packet with a timestamp TS.sub.a to identify a size of a matching original packet, thus, based determination that the first packet size and the second packet size match a pair of packet sizes of the plurality of pairs of packet sizes).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Following prior arts are related to the present claimed invention:
Boynton et al (US 20030235308) teaches, see at least fig.2 & see para.0023, the management server 28 decrypts the portion 63A of the transaction 60 encrypted using the point-to-point encryption key 27. Since server 28 does not have encryption key 46, portion 65 is not decrypted. The management server 28 decodes any unencrypted data 61A and the decrypted point-to-point data 63A to determine how to process the synchronization transaction 60A. Part of the processing may include re-encrypting some or all of the decrypted data 63A back into point-to-point encrypted data 63B using encryption key 29. The management server 28 may also modify or add to the unencrypted data 61A to generate new unencrypted data 61B. The unencrypted data 61B and the re-encrypted point-to-point data 63B are combined with the end-to-end encrypted data 65 to generate new synchronization transaction 60B. The transaction 60B is transported to personal client 40 over the connection 25.
Jules et al (US US 9154480) teaches, see at least fig.2 and abs, a first cryptographic device in one embodiment sends challenges to a second cryptographic device comprising a symmetric-key cryptographic module or other key-based cryptographic module that utilizes one or more secret keys. The first cryptographic device receives from the second cryptographic device responses to respective ones of the challenges, and stores information characterizing the responses. In conjunction with an authentication mode of operation, the first cryptographic device sends a selected one of the challenges to the second cryptographic device, receives from the second cryptographic device a response to the selected challenge, and authenticates the second cryptographic device utilizing the response to the selected challenge and the stored information. The first cryptographic device generates the challenges and authenticates the second cryptographic device without having knowledge of the one or more secret keys of the key-based cryptographic module of the second cryptographic device.
Applicant is encouraged to submit a written authorization for Internet communications (PTO/SB/439, http://www.uspto.gov/sites/default/files/documents/sb0439.pdf) in the instant patent application to authorize the examiner to communicate with the applicant via email. The authorization will allow the examiner to better practice compact prosecution. The written authorization can be submitted via one of the following methods only: (1) Central Fax which can be found in the Conclusion section of this Office action; (2) regular postal mail; (3) EFS WEB; or (4) the service window on the Alexandria campus. EFS web is the recommended way to submit the form since this allows the form to be entered into the file wrapper within the same day (system dependent). Written authorization submitted via other methods, such as direct fax to the examiner or email, will not be accepted. See MPEP § 502.03.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to VINNCELAS LOUIS whose telephone number is (571)270-5138. The examiner can normally be reached 8:30-5:00 PM.
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, Michael Thier can be reached on 571-272-2832. 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.
/VINNCELAS LOUIS/Primary Examiner, Art Unit 2474