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 .
Double Patenting
Based on the approved terminal disclaimer submitted on 09/02/2025, the obviousness type double patenting rejection has been overcome and the double patenting rejection is withdrawn.
Response to Arguments
Applicant's arguments filed September 02, 2025 have been fully considered but they are not persuasive. In the response the applicant argues as follows:
In rejecting claim 1, the Examiner relies on the Duan reference as disclosing the features relating to the recited step of "associating an IPsec identifier with the first IP packets, said IPsec identifier being set to a value indicating that the first IP packets were received via an IPsec tunnel" with the Examiner equating sequence numbers being added by an end point device which corresponds to the start of a tunnel to the step of recited in claim 1 of "associating an IPsec identifier with the first IP packets, said IPsec identifier being set to a value indicating that the first IP packets were received via an IPsec tunnel".(bold, italics and underlining added for emphasis). First of all the Examiner cited "sequence numbers" are not an IPsec identifier value but rather a set of different sequence numbers which facilitate reordering of packets at the receiving end point in the event they arrive at a different order than the order in which they were transmitted. The multiple different sequence numbers, with each packet in the sequence being given a different sequence number, are clearly not "an IPsec identifier value" that is added to "packets" since each sequence number is added to one packet with the next packet being given a different sequence number. Furthermore, the packets to which the Examiner cited sequence numbers are added by the Examiner cited end point which corresponds to the start of a tunnel. The sequence numbers are not added to packets that were received via an IPsec tunnel.
The examiner respectfully disagrees with the applicant’s argument for several of the following reasons. First, the above features agued by the applicant which is “"an IPsec identifier value is added to packets" is not recited in claim 1. It appears that this feature is somehow recited in claim 3 which was already indicated as allowable subject matter. Claim 1 generally suggests “an IPsec identifier is associated with a first IP packet. And the IPsec identifier is set to a value indicating that the first IP packets were received. Claim 1 does not specifically recite adding the IP identifier value into packets, but associating the IPsec identifier with the first IP packets.
The applicant continues to argue that the Examiner's rejection seems to be based on the Examiner miss- interpreting an "end point" in the Duan reference as necessarily being a tunnel exit point which receives packets via the tunnel but in fact both the start and end of the tunnel correspond to "end points" and the Examiner is confusing the start end point of the tunnel in the Duan reference which inserts packets with sequence numbers into the tunnel with the tunnel exit end point which receives and removes the sequence numbers from the packets communicated via the tunnel in the Examiner cited portion of the Duan reference.
The examiner disagrees with applicant’s arguments. The argument remarks or allegation are based mischaracterization of the cited features in the rejection. For example, the examiner citation is based on ([0029 :IPSec VPN tunnel endpoint, having encryption/deception logic 240 to receive encrypted packets, remove added IP and IPSec headers, and decrypt the packets]) unlike the applicant’s mischaracterization as recited above.
The examiner would like to bring the applicant’s attention to “the IPSec identifier” of claim 1 under BRI considerations. In claim 1, the IPSec identifier value is associated only to the first packet to indicate to the scheduler to give priority to the first packets over additional packets received over non-IPSec tunnel.
[See Application Disclosure: 0044] In various embodiments, the IP layer 210 has two alternative novel markings which can be, and sometimes are, associated with a received IP packet payload, a first marking for IPsec traffic (e.g., IP traffic which was received via an IPsec tunnel) and a second marking for normal IP traffic (e.g., IP traffic which was received and which was not communicated to the base station using an IPsec tunnel). In some embodiments, a new mark label is called “IPSec Identifier” and it can have a value of ‘0’ or ‘1’, e.g., the IPSec Identifier is set=1 when the received IP packet payload was communicated over the backhaul via an IPsec tunnel, and the IPSec Identifier is set=0, when the received IP packet payload was normal traffic that was not communicated via an IPsec tunnel over the backhaul. In various embodiments, the IPSec identifier is set to the appropriate value (1 or 0) in the IP layer 210 processing, and associated with the received IP packet payload].
The examiner notes that, during examination, unclaimed features from the applicant’s disclosure are not brought into the claims unless they are specifically recited or incorporated into the claimed limitations. However, BRI consideration has been given to the claimed limitations, the prior arts of record DUAN reads on the above the recited limitations when BRI is considered.
[See prior art DUAN et al in 0005: In another implementation, a method may include receiving, by a network device, a packet that is to be transmitted over a VPN tunnel, the packet including control information that includes at least QoS priority class of the packet; extracting, by the network device, the priority class of the packet from the control information; generating, by the network device, a sequence value that describes an arrival sequence of the packet relative to other received packets of the same priority class as the packet; generating, by the network device, an Internet Protocol Security (IPsec) header for the packet, the IPsec header including the sequence value and the priority class of the packet; attaching, by the network device, the IPsec header to the packet; and transmitting, by the network device, the packet through the VPN tunnel.]
The examiner further notes that the applicant’s limitation recites “the IPSec identifier value is associated only to the first packet to indicate to the scheduler to give higher priority over other packets. In a similar subject matter and same filed of endeavor, the prior art DUAN reads on the claimed feature by describing an IPsec VPN sequence number in:
[See prior art DUAN et al in 0032-0036: Six exemplary packets of a packet stream, labeled as A, B, C, D, E, and F are shown in FIG. 3. A VPN tunnel 310 may be formed between first IPsec VPN endpoint 320 (which may correspond to network device 127 of network 120-A) and second IPsec VPN endpoint 330 (which may correspond to network device 127 of network 120-B). Further, assume a QoS device, such as router 340, is part of VPN tunnel 310. In other words, router 340 may route packets in VPN tunnel 310 as the packets progress to VPN endpoint 330. Router 340 may process packets differently based on priority classes assigned to the packets. In particular, higher priority packets may be given routing precedence in router 340) and furthermore defining s per-priority class sequence number in ([0038-0042: Consistent with aspects described herein, VPN endpoints may assign and validate sequence numbers for packets on a per-priority class basis. Additionally, the priority class of the packet as it enters the VPN endpoint may be transmitted in the IPsec header of the packet over the VPN tunnel. By storing the priority identifier in the IPsec header, the priority identifier is not modified as the packet traverses the VPN tunnel. In contrast, "normal" priority information stored in the header field of a packet may be a mutable value that may be changed by intervening QoS devices).
Based on at least the above reasons, the applicant’s argument are not persuasive to overcome the prior arts in record and place claims 1-2, 14-15 and 20 in condition for allowance and therefore the rejection of 1-2, 14-15 and 20 under 35 U.S.C. 103 as being unpatentable over DUAN et al. (US 20110078783 A1 --hereinafter—“DUAN”) in view of Ellington, Jr. et al. (US 6708218 B1—hereinafter—Ellington) has been mainlined.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-2, 14-15 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over DUAN et al. (US 20110078783 A1 --hereinafter—“DUAN”) in view of Ellington, Jr. et al. (US 6708218 B1—hereinafter—Ellington).
As per claim 1:
Duan discloses a method of operating a base station comprising:
receiving, at the base station, encrypted IP packet data via an IPsec tunnel with a security server of a communications service provider, said encrypted IP data communicating first IP packets ([0029] When acting as an IPsec VPN tunnel endpoint, hardware portion 230 may include encryption/decryption logic 240. Encryption/decryption logic 240 may, when operating as the beginning of a VPN tunnel, generally act to receive packets, encrypt the packets, and transmit the encrypted packets. Encryption/decryption logic 240 may append a new IP header as well as an IPsec header to the encrypted packet before the encrypted packet is transmitted over VPN tunnel 140. Encryption/decryption logic 240 may, when operating as the end of a VPN tunnel, generally act to receive the encrypted packets, remove the previously added IP header and IPsec header from the packet, and decrypt the packet to obtain the original version of the packet);
associating an IPsec identifier with the first IP packets, said IPsec identifier being set to a value indicating that the first IP packets were received via an IPsec tunnel ([0032] IPsec VPN Sequence Numbers: End points in an IPsec VPN tunnel, such as tunnel 140, may append sequence numbers to packets transmitted through the tunnel. FIG. 3 is a diagram conceptually illustrating the use of sequence numbers for packets in an IPsec VPN tunnel);
receiving, at the base station, additional data including additional IP packets via a communications ([0033] Six exemplary packets of a packet stream, labeled as A, B, C, D, E, and F are shown in FIG. 3. A VPN tunnel 310 may be formed between first IPsec VPN endpoint 320 (which may correspond to network device 127 of network 120-A) and second IPsec VPN endpoint 330 (which may correspond to network device 127 of network 120-B). Further, assume a QoS device, such as router 340, is part of VPN tunnel 310. In other words, router 340 may route packets in VPN tunnel 310 as the packets progress to VPN endpoint 330. Router 340 may process packets differently based on priority classes assigned to the packets. In particular, higher priority packets may be given routing precedence in router 340); and
operating a downlink transmission scheduler to schedule transmissions of first IP packets and said additional data, said scheduler giving a higher priority to said first IP packets with which the IPsec identifier is associated than is given to said additional data ([0034] Packets A-F may be assigned to different priority classes. In the example of FIG. 3, assume that the packets are assigned to two different priority classes, priority class one (indicated by a packet label enclosed within a square) and priority class two (indicated by a packet label enclosed within a circle). Assume further that priority class two has a higher priority than priority class one).
Duan does not explicitly disclose the additional IP packets via the communications link does not use an IPsec tunnel. Ellington, in analogous art however, discloses the additional IP packets via the communications link does not use an IPsec tunnel (Column 3: lines 40-53: The present invention further utilizes the hardware function to determine if a frame to be transmitted is an IP frame requiring IPSec outbound processing, and if it is, places the IPSec frame on a separate transmit queue for subsequent outbound processing. To determine if an IP frame is an IPSec frame, the type field in the Medium Access Control (MAC) header and the protocol field in the IP header are examined at the data link control layer. Once IPSec and non-IPSec traffic are separated into different receive or transmit queues, the processor handles the non-IPSec traffic, while the IPSec traffic is processed in parallel by a hardware IPSec assist component which performs the IPSec functions of encryption, decryption, Security Association (SA) management and key exchange. Column 8: lines 1-10: Specifically, given that the system has receive-queue type awareness and given that IPSec frames require substantially more processing than non-IPSec frames, the system can service the non-IPSec frame on a priority basis, thus preventing blocking, from a processing point of view, of non-IPSec frames by IPSec frames. This reduces the average frame processing time. To determine if the frame is an IPSec frame, the frame must be examined at two points--the type field in the MAC header and the protocol field in the IP header. The type field in the MAC header must be type hexadecimal 0800, i.e., IP. The protocol field in the IP header must be type 50 or 51, i.e., IPSec in either tunnel or transport mode).
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of the IP packets disclosed by DUAN to include the additional IP packets via the communications link does not use an IPsec tunnel. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide preprocessing of incoming data frames using a hardware assist component for IPSec data frames to reduce the average processing time of inbound data traffic having intermixed data frames and furthermore postprocessing of outbound data traffic using a hardware assist component for IPSec data frames to reduce the average processing time of outbound data traffic having intermixed data frames as suggested by Ellington (column 3: line 2-6).
As per claim 14:
Claim 14 is directed to a base station comprising: a receiver; and a processor configured to perform features having substantially similar corresponding limitations of claim 2 and therefore claim 14 is rejected with the same rationale given above to reject claim 2.
As per claim 20:
Claim 20 is directed to a non-transitory computer readable medium including computer executable instructions which when executed by a processor of a base station cause the base station to perform the steps having substantially similar corresponding limitations of claim 1 and therefore claim 20 is rejected with the same rationale given above to reject claim 1.
Claims 2 and 15 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over DUAN et al. (US 20110078783 A1 --hereinafter—“DUAN”) in view of Ellington, Jr. et al. (US 6708218 B1—hereinafter—Ellington) in further view of WANTE US 20150121076 A1.
As per claim 2:
Duan in view of Ellington disclose the method of claim 1, further comprising: storing the first IP packets with which the IPsec identifier is associated in a first downlink transmission queue (Duan [0035] VPN endpoint 320 may associate sequence numbers with each of the packets. For example, VPN endpoint 320 may store a sequence number in IPsec headers appended to each of the packets by VPN endpoint 320. The sequence numbers appended by VPN endpoint 320 are shown as sequence numbers 350. Packet A is given the sequence number one, packet B is given the sequence number two, and so on, through packet F, which is given the sequence number six); and
storing IP packets which were not received via an IPsec tunnel in a second downlink transmission queue, said additional IP packets being stored in said second downlink transmission queue (Duan [0038] Consistent with aspects described herein, VPN endpoints may assign and validate sequence numbers for packets on a per-priority class basis. Additionally, the priority class of the packet as it enters the VPN endpoint may be transmitted in the IPsec header of the packet over the VPN tunnel. By storing the priority identifier in the IPsec header, the priority identifier is not modified as the packet traverses the VPN tunnel. In contrast, "normal" priority information stored in the header field of a packet may be a mutable value that may be changed by intervening QoS devices).
Duan and Ellington do not explicitly disclose recovering the first IP packets from the received encrypted IP packet data prior to associating the IPsec identifier with the first IP packets. WANTE, in analogous art however, discloses recovering the first IP packets from the received encrypted IP packet data prior to associating the IPsec identifier with the first IP packets ([0122] A security policy database (SPD) which stores policies. Another component is the security parameter index (SPI) which, as described, point to security associations. Typically, two SPIs are negotiated between the secure app and the gateway during IKE Phase 2. The SAs are generated by the secure app and the gateway for data that the app wants to encrypt or decrypt. In one embodiment, an SPI is a unique identifier that essentially points to an SA. That is, data going from the gateway to the app (on the mobile device) has one SPI and data going from the app to the gateway has another SPI. Each SPI references an entry in an SPD/SA cache. As is known in the art, an SA includes encryption keys, types, algorithms, and the like. In one embodiment, the IKE process populates the SPD/SA cache with SPIs and SA; it does not distribute SPIs, SAs, or any other data directly to the data path processes. The SPD/SA cache dictates which packets are allowed to go through the gateway and onto the internal enterprise servers. The packets are either decrypted or encrypted using the policy (SA) specified in the SPD/SA database. [0123] The gateway receives a unique data flow of packets and a packet header is queried for an SPI identifier. This SPI value is used, first, to search the IPSec local cache for a policy. If the policy entry in the local cache specifies a policy for decryption or encryption, these policy instructions are used to encrypt or decrypt (i.e., how such crypto operations should be performed). As noted, this information is negotiated and obtained during IKE Phase 2 negotiation with the secured app on the device. The gateway also uses the local cache entry to see if the gateway should let a packet into the tunnel (encrypting the packet) or out of the tunnel (decrypting the packet) based on instructions in the policy/SA. [0131] A process of obtaining security association data for a packet without involving the IKE process in accordance with one embodiment. The gateway receives a unique data flow from a wrapped app on a computing device. The gateway determines whether the data is comprised of IPSec packets. If they are, control goes to step 1308 where the gateway extracts an SPI from the packet. In one embodiment, it extracts this from the packet header at step 1318. At step 1310 a look-up is performed using the SPI for policy in the local IPSec cache. If this results in a hit and the SA is found there, control goes to step 1312 where the gateway performs any necessary crypto operations on the data packets using the SA found in the local cache. [0132] Returning to step 1306, the gateway determines whether the data flow is comprised of IPSec packets. If it is, control goes to step 1308 and the process progresses. If the data packet is not an IPSec packet, control goes to step 1318 where the packet header is hashed into a SPI value. Logic proceeds to step 1310 where a lookup is performed in the local IPSec cache and commences as described above). Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of the IP packets disclosed by Duan and Ellington to include recovering the first IP packets from the received encrypted IP packet data prior to associating the IPsec identifier with the first IP packets. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide a process where IKE does not need to have any inherent knowledge of data paths, IPSec instances or their respective security policy and security association mappings and tunnels as suggested by WANTE ([0008]).
As per claim 15:
Claim 15 is directed to a base station comprising: a receiver; and a processor configured to perform features having substantially similar corresponding limitations of claims 1-2 and therefore claim 15 is rejected with the same rationale given above to reject claim 2.
As per claim 20:
Claim 20 is directed to a non-transitory computer readable medium including computer executable instructions which when executed by a processor of a base station cause the base station to perform the steps having substantially similar corresponding limitations of claim 1 and therefore claim 20 is rejected with the same rationale given above to reject claim 1.
Claims 5, 9-13 and 18 and are rejected under 35 U.S.C. 103 as being unpatentable over DUAN et al. (US 20110078783 A1 --hereinafter—“DUAN”) in view of Ellington, Jr. et al. (US 6708218 B1—hereinafter—Ellington) in further view of WANTE US 20150121076 A1 and in further view of Yin et al. (US 20120087313 A1—hereinafter—Yin).
As per claim 5:
Duan and WANTE in view of Ellington does not explicitly disclose operating the downlink transmission scheduler to control the base station to transmit packets from the first and second downlink transmission queues to one or more UE devices. Yin, in analogous art however, discloses operating the downlink transmission scheduler to control the base station to transmit packets from the first and second downlink transmission queues to one or more UE devices. Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of the invention to modify the claimed limitations of packets disclosed by Duan in view of Ellington to include operating the downlink transmission scheduler to control the base station to transmit packets from the first and second downlink transmission queues to one or more UE devices. This modification would have been obvious because a person having ordinary skill in the art would have been motivated by the desire to provide a paging processing method to improve the quality of service provided to a user equipment as suggested by Yin ([0007-0019]).
As per claim 9:
Duan and WANTE in view of Ellington in further view of Yin disclose wherein said first IP packets communicated via an IP Sec tunnel are user data packets being communicated between a first UE and a second UE, said second UE being in a first cell corresponding to said base station and the first UE being in a second cell corresponding to another base station (Yin [0078] After receiving a downlink data packet and knowing that the downlink tunnel corresponding to the data packet is invalid, the serving gateway buffers the data packet and obtains the service attribute information corresponding to the data packet. The service attribute information may be at least one of the following items: IP address, protocol type, port number, IPSec parameter index, DSCP/TOS, Flow Label, service type, and service feature of the data packet, as detailed hereunder [0156]).
As per claim 10:
Duan and WANTE in view of Ellington in further view of Yin disclose wherein said additional data packets are control packets communicated from a neighbor base station (Yin [0116] the data gateway is a policy enforcement point which implements the function of policy enforcement point in the prior policy control architecture).
As per claim 11:
Duan and WANTE in view of Ellington in further view of Yin disclose wherein said additional data packets are user data packets communicated between a third UE and a fourth UE attached to said base station and which do not traverse an IP sec tunnel (Yin [0092-0093] After the user equipment receives the paging, the user equipment initiates a service request procedure to restore the signaling connection and user plane bearers with the network side and transits to the connected state. After the downlink tunnel is valid, the serving gateway sends the buffered data packet to the user equipment).
As per claim 12:
Duan and WANTE in view of Ellington in further view of Yin disclose wherein associating the first IP packets is performed as an IP layer operation; and wherein said identifying the first IP packets is performed as a MAC layer operation (Ellington Column 8: lines 1-6: given that the system has receive-queue type awareness and given that IPSec frames require substantially more processing than non-IPSec frames, the system can service the non-IPSec frame on a priority basis, thus preventing blocking, from a processing point of view, of non-IPSec frames by IPSec frames. This reduces the average frame processing time. To determine if the frame is an IPSec frame, the frame must be examined at two points--the type field in the MAC header and the protocol field in the IP header).
As per claim 13:
Duan and WANTE in view of Ellington in further view of Yin disclose wherein said storing the identified first packets in the first downlink transmission queue is performed by a MAC layer packet scheduler that schedules the transmission of frames including one or more IP packet portions (Ellington Column 8: lines 1-6: given that the system has receive-queue type awareness and given that IPSec frames require substantially more processing than non-IPSec frames, the system can service the non-IPSec frame on a priority basis, thus preventing blocking, from a processing point of view, of non-IPSec frames by IPSec frames. This reduces the average frame processing time. To determine if the frame is an IPSec frame, the frame must be examined at two points--the type field in the MAC header and the protocol field in the IP header).
As per claim 18:
Claim 18 are directed to a base station comprising: a receiver; and a processor configured to perform features having substantially similar corresponding limitations of claim 5 respectively and therefore claim 18 are rejected with the same rationale given above to reject claim 5 respectively.
Allowable Subject Matter
Claims 3-4, 6-8, 16-17 and 19 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 following is a statement of reasons for the indication of allowable subject matter: The prior arts of record when taken alone or individually do teach or disclose limitation features of claims 3-4, 6-8, 16-17 and 19.
Conclusion
The prior arts made of record and not relied upon are considered pertinent to applicant's disclosure. See the notice of reference cited in form PTO-892 for additional prior arts.
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.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TECHANE GERGISO whose telephone number is (571)272-3784. The examiner can normally be reached 9:30am to 6:30pm.
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, LINGLAN EDWARDS can be reached at (571) 270-5440. 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.
/TECHANE GERGISO/Primary Examiner, Art Unit 2408