DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Objections
1. Claim 37 is objected to because of the following informalities: the limitation “a payload of the IPv4 packet; or or an internet protocol version 6” is not clear. Appropriate correction is required.
Claim Rejections - 35 USC § 102
2. 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.
3. Claims 31-47 and 53-60 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Obata (US 2007/0025342).
Regarding claim 31, Obata teaches that applied to a first network device (Fig. 1, 2 and page 1, paragraphs 5). Obata teaches that receiving a first packet from a terminal (pages 4, paragraphs 41 – 43 and Fig. 8, where teaches relay router receives packet from client), and sending a second packet to a second network device (pages 4, paragraphs 41 – 43 and Fig. 8, where teaches the data is forwarded to the application server (second network), or directly to another mobile device if the service flag is on), wherein the second packet is obtained by encapsulating security information in the first packet, and the security information indicates that the second packet is a trusted packet determined by the first network device (Fig. 6, 8, 9 and pages 3, paragraphs 34 – paragraphs 4, paragraphs 45, where teaches the client mobile device transmits UDP packets to the application server through the relay router, and each UDP packet includes header data including a relay key, a user ID (UID), an application ID and a service flag, and the relay router receives the data, and if the relay key is valid, then the router tests the UID and application ID, if any of the relay key, UID or application ID are invalid, then the data packet is disposed, and the relay router tests the downlink relay key (DLRK) from the associated relay context and if expired, calculates a new downlink relay key, and the new DLRK is calculated using a hash function of the relay key and a time factor, and the relay key in the header of the data received from the client is replaced with the downlink relay key).
Regarding claim 32, Obata teaches that the security information comprises first verification information indicating that the second packet is the trusted packet determined by the first network device (Fig. 6, 8, 9 and pages 3, paragraphs 34 – paragraphs 4, paragraphs 45).
Regarding claim 33, Obata teaches that the security information further comprises second verification information comprising one or more of the following: an identifier of a verification algorithm; anti-replay information; an identifier of the first network device; a key ciphertext; an identifier of the second network device; an internal reachable address of a third device; or first indication information, wherein the third device is a downstream device of the second network device, and the first indication information indicates a type of the security information (Fig. 6, 8, 9 and pages 3, paragraphs 34 – paragraphs 4, paragraphs 45).
Regarding claim 34, Obata teaches that the second verification information further comprises second indication information indicating whether the security information comprises one or more of the following: the identifier of the verification algorithm; the anti-replay information; the identifier of the first network device; or the key ciphertext (Fig. 6, 8, 9 and pages 3, paragraphs 34 – paragraphs 4, paragraphs 45).
Regarding claim 35, Obata teaches that the second verification information further comprises the second indication information (pages 4, paragraphs 41 – 43 and Fig. 8), and the second indication information indicates a location or a length of one or more of the following in the second packet: the first verification information, the identifier of the verification algorithm, the anti-replay information, the identifier of the first network device, or the key ciphertext (Fig. 6, 8, 9 and pages 3, paragraphs 34 – paragraphs 4, paragraphs 45).
Regarding claim 36, Obata teaches that the first verification information is in a header or a tail of the second packet (pages 4, paragraphs 41 – 43 and Fig. 8), and the second verification information is in the header or the tail of the second packet (Fig. 6, 8, 9 and pages 3, paragraphs 34 – paragraphs 4, paragraphs 45).
Regarding claim 37, Obata teaches that the second packet is an internet protocol version 4 (IPv4) packet and the second verification information is located between an IPv4 header and a payload of the IPv4 packet, or an internet protocol version 6 (IPv6) packet and the second verification information is located in an extension header of an IPv6 protocol header of the IPv6 packet (Fig. 6, 8, 9 and pages 3, paragraphs 34 – paragraphs 4, paragraphs 45).
Regarding claim 38, Obata teaches that before sending the second packet to the second network device, receiving first configuration information from a network controller (Fig. 1, 3 and pages 3, paragraphs 34 – paragraphs 4, paragraphs 45), wherein the first configuration information comprises one or more of the following: a public address of the third device; the first verification information; the verification algorithm; the identifier of the verification algorithm; the anti-replay information; a first key; the anti-replay information; the identifier of the first network device; the key ciphertext; the identifier of the second network device; the internal reachable address of the third device; the first indication information; or the second indication information (Fig. 6, 8, 9 and pages 3, paragraphs 34 – paragraphs 4, paragraphs 45), wherein the verification algorithm, the anti-replay information, and the first key are used to determine the first verification information (Fig. 6, 8, 9 and pages 3, paragraphs 34 – paragraphs 4, paragraphs 45).
Regarding claim 39, Obata teaches that destination addresses (address translation) of the first packet and the second packet are a public address of the third device (Fig. 6, 8, 9, abstract, and pages 3, paragraphs 34 – paragraphs 4, paragraphs 45), and the public address of the third device points to the third device, but is unreachable to the third device (6, 8, 9 and pages 3, paragraphs 34 – paragraphs 4, paragraphs 45).
Regarding claim 40, Obata teaches that the first network device is any one of a router, a gateway, or a switch; and the second network device is a router (6, 8, 9 and pages 3, paragraphs 34 – paragraphs 4, paragraphs 45).
Regarding claim 41, Obata teaches all the limitation as discussed in claim 31. Furthermore, Obata further teaches that security information is encapsulated in the second packet, and the security information indicates that the second packet is a trusted packet determined by the first network device, and verifying the second packet (Fig. 6, 8, 9 and pages 3, paragraphs 34 – paragraphs 4, paragraphs 45, where teaches the client mobile device transmits UDP packets to the application server through the relay router, and each UDP packet includes header data including a relay key, a user ID (UID), an application ID and a service flag, and the relay router receives the data, and if the relay key is valid, then the router tests the UID and application ID, if any of the relay key, UID or application ID are invalid, then the data packet is disposed, and the relay router tests the downlink relay key (DLRK) from the associated relay context and if expired, calculates a new downlink relay key, and the new DLRK is calculated using a hash function of the relay key and a time factor, and the relay key in the header of the data received from the client is replaced with the downlink relay key).
Regarding claim 42, Obata teaches all the limitation as discussed in claims 32 and 41.
Regarding claim 43, Obata teaches all the limitation as discussed in claims 33 and 41.
Regarding claim 44, Obata teaches all the limitation as discussed in claims 34 and 41.
Regarding claim 45, Obata teaches all the limitation as discussed in claims 35 and 41.
Regarding claim 46, Obata teaches all the limitation as discussed in claims 36 and 41.
Regarding claim 47, Obata teaches all the limitation as discussed in claims 37 and 41.
Regarding claim 53, Obata teaches all the limitation as discussed in claims 40 and 41.
Regarding claim 54, Obata teaches all the limitation as discussed in claims 31 and 41. Furthermore, an apparatus comprising, a processor, a memory with program instructions stored thereon, wherein the instructions, when executed by the processor, enable the apparatus to receive a first packet from a terminal (1, 8, 9 and pages 4, paragraphs 41 – paragraphs 5, paragraphs 50)
Regarding claim 55, Obata teaches all the limitation as discussed in claims 32 and 54.
Regarding claim 56, Obata teaches all the limitation as discussed in claims 33 and 54.
Regarding claim 57, Obata teaches all the limitation as discussed in claims 34 and 54.
Regarding claim 58, Obata teaches all the limitation as discussed in claims 41 and 54.
Regarding claim 59, Obata teaches all the limitation as discussed in claims 32 and 58.
Regarding claim 60, Obata teaches all the limitation as discussed in claims 33 and 58.
Allowable Subject Matter
4. Claims 48 – 52 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The prior art of record fails to disclose the limitation “verifying the second packet comprises determining third verification information based on the second verification information, and verifying the second packet based on the first verification information and the third verification information, and in response to the first verification information being different from the third verification information, discarding, by the second network device, the second packet” as specified the claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
KARIYANAHALLI et al. (US 2018/0302389) discloses System and Method for Traversing a NAT Device with IPSEC AH Authentication.
Information regarding...Patent Application Information Retrieval (PAIR) system... at 866-217-9197 (toll-free)."
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN J LEE whose telephone number is (571)272-7880. The examiner can normally be reached on Mon-Fri (8:00am-5:00pm).
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, Yuwen Pan can be reached on 571-272-7855. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
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 http://pair-direct.uspto.gov. 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.
J.L
February 16, 2026
John J Lee
/JOHN J LEE/
Primary Examiner, Art Unit 2649