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 . This office action is in response to the applicant’s response without amendments filed on 02/03/2026. Claims 1-12 are currently pending in the filing of 02/03/2026, claims 1-12 were pending in the previous filing of 09/02/2025 which included amendments.
Response to Applicant’s Amendments / Arguments Regarding 35 U.S.C. § 103
The applicant’s remarks, on pages 7-10 of the response / amendment filed 02/03/2026, the applicant argues that previously cited Bidgoli is not prior art. The examiner has updated the rejection, removing Bidgoli as a reference and has updated the rejection under 35 U.S.C. § 103 using a newly cited reference.
Applicant’s arguments have been considered and have resulted in an updated ground(s) of rejection.
Response to Applicant’s Amendments / Arguments Regarding 35 U.S.C. § 103
The applicant’s remarks, on pages 7-11 of the response / amendment, the applicant argues the features which allegedly distinguish over the previously cited references cited in the 35 U.S.C. § 103 rejections.
Applicant’s arguments have been considered but are moot in view of the new ground(s) of rejection.
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.
Claims 1-12 are rejected under 35 U.S.C. 103 as being unpatentable over US 20090228708 to Trostle (hereinafter Trostle), in view of US 20130170493 to Mattson (hereinafter Mattson), in view of US 20210075829 to Wei (hereinafter Wei).
Regarding claim 1, Trostle teaches,
A packet processing method, applied to a client end device comprising a client, comprising: (fig. 1, client 102. [0003] teaches Tor / Peer to Peer (P2P) routing, and multi-hop routing. Fig. 1 and [0008-13] teach anonymous mix routing of fig. 1.)
in response to a first service packet sent from the client to a server, (fig. 1, 120) (Abstract, Originating address) a destination address of the first service packet being an encrypted server(Abstract and [0032] teaching destination / server address. [0008-14] teaches mapping originating and the different destination addresses)
encrypting the source address and the destination address of the first service packet using a public key of the server according to the encrypted server (Abstract and [0032] teach encrypting the client 102 / originating address and the destination addresses including mix routers and server 104 of fig. 1. [0046-47] teaches asymmetric encryption, and also pseudo-random address is related to the encryption.)
in response to a second service packet sent by the server, decrypting a source address and a destination address of the second service packet using a private key of the client, ([0007] and 126 of fig. 1 teach reversing communication direction of Abstract and [0032] discussed above. Abstract and [0032] teach decrypting destination portion of data. [0007] teaches decryption of the layers of onion. [0047] teaches asymmetric key usage. [0095] teaches tunneling which one of skill in the art understands includes key exchange, using public / private keys.) and replacing the destination address of the second service packet with an address of the client, the destination address of the second service packet being the encrypted client (At the end of the routing of fig. 1, 126 to 122 / server to client, described in at least [0006-7] the destination address is used to send 122 to the client, where Mattson, discussed further below, teaches that the destination identifier is used by intermediaries to route packets, until the packet is sent to the final destination. Decryption of data 144 results in data 124, in [0012], which when reversed is decryption that results in data 122 from server to client.)
Trostle fails to explicitly teach replacing source address and destination address with a segment identifier,
However, Mattson teaches,
(claims 2 & 18 teaches replacing destination address and source address with identifier. [0018] teaches the identifier is a pointer. [0043] teaches VPN tunnels which are encrypted.) (See also Trostle, [0046-47] which teaches the use of pseudo-random source addresses.) a destination address of the first service packet being an (claims 2 & 18, [0018], and [0043], as discussed above.)
(claims 2 & 18, [0018], [0043], as discussed above.)
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to combine the teachings of Trostle, which teaches encryption of source addresses and destination addresses in a data packet using IPv6 addresses (Abstract & [0032]), with Mattson, which also teaches source and destination addresses in a packet using IPv6 addressing ([0004]), and additionally explicitly teaches replacing the source and destination addresses with identifiers that are mapped (claim 3). One of ordinary skill in the art would have been motivated to perform such an addition to provide Trostle with the added ability to obfuscate destination and source addresses with identifiers that are mapped to actual addresses, as taught by Mattson, for the purpose of increasing security by masking addresses using identifiers / indexes.
Trostle and Mattson fail to explicitly teach encrypted segment identifiers that include information regarding encryption,
However, Wei teaches,
… the encrypted client segment identifier and the encrypted server segment identifier indicating that the source address and the destination address of the first service packet are to be encrypted; ([0008] teaches Ethernet frame header may be IP version 4 and that payload includes Address resolution protocol (ARP) in the payload. See also Abstract teaching indicators of a protection protocol and [0004] where Ethernet frame protocol indicates protection protocol. [0084] teaches the Ethernet Frame Header includes destination media access control (DMAC) address and source MAC (SMAC), and that the Ethernet Frame header is protected using ETYPE. [0085] & figs. 10-11 teaches the Original layer 2 frame ethernet frame header (e.g., ETYPE) is protected (e.g., encrypted), where fig. 10 teaches the original Layer-2 frame put into the original VXLAN packet and new VXLAN packet including new VXLAN headers are VXLAN GPE headers of fig. 11 including flags, “next protocol”, and VNI which is a segment identifier.)
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to combine the teachings of Trostle, which teaches encryption of source addresses and destination addresses in a data packet using IPv6 addresses (Abstract & [0032]), with Mattson, which also teaches source and destination addresses in a packet using IPv6 addressing ([0004]), and additionally explicitly teaches replacing the source and destination addresses with identifiers that are mapped (claim 3), with Wei, which also teaches IP source and destination addresses ([0063]), and additionally teaches VNI segmentation routing using VXLAN including protected address and indicators and headers including VNI / segment identifiers, flags, and “next protocol” ([0084-85]). One of ordinary skill in the art would have been motivated to perform such an addition to provide Trostle and Mattson with the added ability to utilize encryption indicators to indicate that protection / encryption is used including protection of addresses, as taught by Wei, for the purpose of increasing security by protecting addresses and indicators including protocols and flags.
Regarding claim 2, Trostle, Mattson, and Wei teach,
The packet processing method according to claim 1, further comprising:
Mattson teaches,
before replacing the source address of the first service packet with the encrypted client segment identifier corresponding to the client, in response to a service authorization request sent from the client to the server, configuring the encrypted client segment identifier, and establishing a mapping relationship between the encrypted client segment identifier and the address of the client; and (Mattson, claim 3 teaches mapping of the IPv6 table of addresses to identifiers.)
sending the service authorization request to the server, and receiving a service authorization response fed back by the server, the service authorization response comprising the encrypted server segment identifier. (Mattson, [0030-32] teaches routing / forwarding tables that are provided to device 110 of fig. 1.)
Regarding claim 3, Trostle, Mattson, and Wei teach,
The packet processing method according to claim 1, further comprising:
establishing a mapping relationship between an encrypted client segment identifier encrypted using the public key of the server and the address of the client, and establishing a mapping relationship between the encrypted server segment identifier encrypted using the public key of the server and the encrypted server segment identifier; (Trostle, Abstract, [0008-13], and [0032] teaches mix routing, as discussed in the rejection of claim 1. Trostle, [0047] teaches asymmetric key usage. [0095] teaches tunneling which one of skill in the art understands includes key exchange, using public / private keys.) (Mattson, claim 3 teaches mapping of the IPv6 table of addresses to identifiers that replace the addresses.)
in response to a third service packet sent from the client to the server, (Trostle, fig. 1, 120 to 124,
Abstract, and [0032] teach encrypting the client 102 / originating address and the destination addresses including mix routers and server 104 of fig. 1. [0047] teaches asymmetric encryption.) replacing a source address of the third service packet with the encrypted client segment identifier encrypted using the public key of the server, and replacing a destination address of the third service packet with the encrypted server segment identifier encrypted using the public key of the server, the destination address of the third service packet being the encrypted server segment identifier; and (Trostle, [0047] and [0095] as discussed above) (Mattson, claims 2 & 18, [0018], and [0043], as discussed above in claim 1, regarding the segment identifier replacing the actual address)
sending the third service packet to the server. (Fig. 1, 120 to 124.)
Regarding claim 4, Trostle, Mattson, and Wei teach,
The packet processing method according to claim 1, wherein the client end device further comprises a client gateway; and (Trostle, [0050] teaches a gateway. Additionally, [0007] teaches NAT 118 is a bridge between client and server.)
the sending an encrypted first service packet to the server comprises:
according to an address of the client gateway, an address of an intermediate node in a link and an address of a server gateway corresponding to the server, generating a tunnel header and a segment routing extension header in an outer layer of the first service packet, and sending the first service packet processed to the server gateway. (Trostle, [0008] teaches encryption of each leg of the transmission, including source and destination addresses, and a mapped destination address. [0095] teaches tunnel encryption, [0003] teaches layered encryption.) (Mattson, teaches the segment routing / identifier)
Regarding claim 5, Trostle teaches,
A packet processing method, applied to a server end device comprising a server, comprising: (fig. 1, server 104 communicating with client 102, where 124 shows data at server, from client.)
in response to a first service packet sent by a client, decrypting a source address and a destination address of the first service packet using a private key of the server, (Abstract, [0012], and [0032] teach the decryption performed before data is given to server.) and replacing the destination address of the first service packet with an address of the server, the source address of the first service packet being an encrypted client (The above recitation is directed to a server receiving the first packet from client, Abstract, [0012], and [0032] teach the decryption performed before data is given to server. See also, [0008-13] and fig. 1 teaching the mix routing.)
(The following recitation is directed to a server sending a second packet to the client)
in response to a second service packet sent from the server to the client, replacing a source address of the second service packet with an encrypted server ([0007] teaches that the process in [0008-13] may be reversed by having the server send data to the client through the mix routing. Abstract and [0032] teaching destination / server address. [0008-14] teaches mapping originating and the different destination addresses.)
encrypting the source address and the destination address of the second service packet using a public key of the client according to the encrypted client ([0007] teaches that the process in [0008-13] may be reversed. Abstract and [0032] teach encrypting the client 102 / originating address and the destination addresses including mix routers and server 104 of fig. 1. [0047] teaches asymmetric encryption.)
Trostle fails to explicitly teach replacing source address and destination address with a segment identifier,
However, Mattson teaches,
… … (claims 2 & 18 teach replacing destination address and source address with identifier. [0018] teaches the identifier is a pointer. [0043] teaches VPN tunnels which are encrypted.) (See also Trostle, [0046-47] which teaches the use of pseudo-random source addresses.)
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to combine the teachings of Trostle, which teaches encryption of source addresses and destination addresses in a data packet using IPv6 addresses (Abstract & [0032]), with Mattson, which also teaches source and destination addresses in a packet using IPv6 addressing ([0004]), and additionally explicitly teaches replacing the source and destination addresses with identifiers that are mapped (claim 3). One of ordinary skill in the art would have been motivated to perform such an addition to provide Trostle with the added ability to obfuscate destination and source addresses with identifiers that are mapped to actual addresses, as taught by Mattson, for the purpose of increasing security by masking addresses using identifiers / indexes.
Trostle and Mattson fail to explicitly teach encrypted segment identifiers that include information regarding encryption,
However, Wei teaches,
… the encrypted client segment identifier and the encrypted server segment identifier indicating that the source address and the destination address of the first service packet are to be encrypted; ([0008] teaches Ethernet frame header may be IP version 4 and that payload includes Address resolution protocol (ARP) in the payload. See also Abstract teaching indicators of a protection protocol and [0004] where Ethernet frame protocol indicates protection protocol. [0084] teaches the Ethernet Frame Header includes destination media access control (DMAC) address and source MAC (SMAC), and that the Ethernet Frame header is protected using ETYPE. [0085] & figs. 10-11 teaches the Original layer 2 frame ethernet frame header (e.g., ETYPE) is protected (e.g., encrypted), where fig. 10 teaches the original Layer-2 frame put into the original VXLAN packet and new VXLAN packet including new VXLAN headers are VXLAN GPE headers of fig. 11 including flags, “next protocol”, and VNI which is a segment identifier.)
Before the effective filing date of the invention, it would have been obvious to one of ordinary skill in the art to combine the teachings of Trostle, which teaches encryption of source addresses and destination addresses in a data packet using IPv6 addresses (Abstract & [0032]), with Mattson, which also teaches source and destination addresses in a packet using IPv6 addressing ([0004]), and additionally explicitly teaches replacing the source and destination addresses with identifiers that are mapped (claim 3), with Wei, which also teaches IP source and destination addresses ([0063]), and additionally teaches VNI segmentation routing using VXLAN including protected address and indicators and headers including VNI / segment identifiers, flags, and “next protocol” ([0084-85]). One of ordinary skill in the art would have been motivated to perform such an addition to provide Trostle and Mattson with the added ability to utilize encryption indicators to indicate that protection / encryption is used including protection of addresses, as taught by Wei, for the purpose of increasing security by protecting addresses and indicators including protocols and flags.
Regarding claim 6, Trostle, Mattson, and Wei teach,
The packet processing method according to claim 5, further comprising:
before decrypting the source address and the destination address of the first service packet using the private key of the server,
in response to a service registration request sent from the server to a service management controller, configuring the encrypted server segment identifier, and establishing a mapping relationship between the encrypted server segment identifier and the address of the server; and
sending the service registration request to the service management controller, and
receiving a service registration response fed back by the service management controller. (Trostle, [0007] see discussion above.)
Claim 6 is rejected using the same basis of arguments used to reject claim 2 above.
Regarding claim 7, Trostle, Mattson, and Wei teach,
The packet processing method according to claim 5, further comprising:
establishing a mapping relationship between an encrypted client segment identifier encrypted using the public key of the client and the encrypted client segment identifier, establishing a mapping relationship between the encrypted server segment identifier encrypted using the public key of the client and the address of the server;
in response to a fourth service packet sent from the server to the client, replacing a source address of the fourth service packet with the encrypted server segment identifier encrypted using the public key of the client, and replacing a destination address of the fourth service packet with the encrypted client segment identifier encrypted using the public key of the client, the destination address of the fourth service packet being the encrypted client segment identifier; and
sending the fourth service packet to the client. (Trostle, [0007] see discussion above.)
Claim 7 is rejected using the same basis of arguments used to reject claim 3 above.
Regarding claim 8, Trostle, Mattson, and Wei teach,
The packet processing method according to claim 5, wherein the service device further comprises a server gateway; and
the sending an encrypted second service packet to the client comprises:
according to an address of the server gateway, an address of an intermediate node in a link and an address of a client gateway corresponding to the client, generating a tunnel header and a segment routing extension header in an outer layer of the second service packet, and sending a second service packet processed to the client gateway. (Trostle, [0007] see discussion above.)
Claim 8 is rejected using the same basis of arguments used to reject claim 4 above.
Regarding claim 9, Trostle, Mattson, and Wei teach,
A client end device, comprising:
at least one processor; and
a memory configured to store at least one computer program;
the at least one computer program, executed by the at least one processor, causes the at least one processor to implement the packet processing method of claim 1. (Trostle, [0005] & [0068])
Regarding claim 10, Trostle, Mattson, and Wei teach,
A server end device, comprising:
at least one processor; and
a memory configured to store at least one computer program;
the at least one computer program, executed by the at least one processor, causes the at least one processor to implement the packet processing method of claim 5. (Trostle, [0005] & [0068])
Regarding claim 11, Trostle, Mattson, and Wei teach,
A computer-readable medium having a computer program stored thereon, the computer program, executed by a processor, causes the processor to implement the packet processing method of claim 1. (Trostle, [0005] & [0068])
Regarding claim 12, Trostle, Mattson, and Wei teach,
A computer-readable medium having a computer program stored thereon, the computer program, executed by a processor, causes the processor to implement the packet processing method of claim 5. (Trostle, [0005] & [0068])
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to BRIAN WILLIAM AVERY whose telephone number is (571)272-3942. The examiner can normally be reached on 9AM-5PM.
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, Farid Homayounmehr can be reached on (571)272-3739.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see https://ppair-my.uspto.gov/pair/PrivatePair. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/B.W.A./
/FARID HOMAYOUNMEHR/Supervisory Patent Examiner, Art Unit 2495