DETAILED ACTION
Notice of Pre-AIA or AIA Status
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
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.
3. 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.
4. Claims 1, 2, 4, 7-13 and 15-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Dhanabalan et al. (US 2020/0186507 A1, hereinafter “Dhanabalan”).
Regarding claim 1, Dhanabalan teaches a communications method, the method comprising: segmenting, at a first node, at least a first packet corresponding to a first communications session (figs. 5A-5C, ¶ [0058], ¶ [0099], ¶ [0100], ¶ [0102], the metadata of the header information 545 of the packet 540 may be associated with the application running on the client 102. The metadata associated with the application running on the client 120 for which the packet 540 is generated may include, for example, an indicator specifying that the packet 540 is application-specific, an account identifier for the client 102 (e.g., a user profile, email address, or screenname), an application identifier (e.g., a name of the application), a profile of the application (e.g., version number of the application), and a timestamp corresponding to generation of the packet 540. ¶ [0103], ¶ [0106], The connection information may include the connection tuple and/or the session information for a previously established connection. ¶ [0121]) into at least a first packet portion and a second packet portion, said first packet including a first packet header and a first packet payload (figs. 5B, 6, ¶ [0100], Each packet 540 received by the packet analyzer 505 may include header information 545 and a payload 550. ¶ [0106], ¶ [0108], ¶ [0110]), said first packet portion including at least a portion of said first packet header and a first portion of the first packet payload (¶ [0117], The communication tunnel 530a-n with the defined level of security greater than or equal to the threshold level of security may be for delivering the header information 545 (and/or an identifier or digest) of the packet 540 (e.g., encrypted tunnel 530c). ¶ [0120], With the partitioning of the header information 545 from the payload 550, the communication engine 520a may generate an identifier for the payload 550. In some embodiments, the identifier for the payload 550 may include a digest of the payload 550. To generate the digest, the communication engine 520a may apply a hash algorithm to at least a portion of the payload 550. The communication engine 520a may insert, concatenate, append, or otherwise add the identifier for the payload 550 (e.g., the digest of the payload 550) to the header information 545. In communicating the header information 545, the communication engine 520a may apply the cryptographic algorithm, mechanism and/or function defined for the selected communication tunnel 530a-n to the header information 545 and the identifier for the payload 550), said second packet portion including at least a second portion of said first packet payload (figs. 5A-5C, ¶ [0115], the selected at least one communication tunnel 530a-n may correspond to at least one communication tunnel 530a-n that is unencrypted and/or unsecured. In some embodiments, the tunnel selector 515 may select the unencrypted tunnel for payload data 530b); communicating, in encrypted form, the first packet portion from the first node to a second node; and communicating, in unencrypted form, the second packet portion from the first node to the second node (figs. 5A-5C, ¶ [0115], the selected at least one communication tunnel 530a-n may correspond to at least one communication tunnel 530a-n that is unencrypted and/or unsecured. In some embodiments, the tunnel selector 515 may select the unencrypted tunnel for payload data 530b and the encrypted tunnel 530a or the encrypted tunnel for header information 530c, ¶ [0119], the communication engine 520a may split or partition the header information 545 and the payload 550 of the packet 540. ¶ [0120], ¶ [0117], ¶ [0096]).
Regarding claim 12, Dhanabalan teaches a communications system comprising:
a first node, said first node including: memory; and a first processor, said first processor controlling the first node (fig. 1C, ¶ [0052], ¶ [0053]) to perform the following operations:
segmenting, at the first node, at least a first packet corresponding to a first communications session (figs. 5A-5C, ¶ [0058], ¶ [0099], ¶ [0100], ¶ [0102], the metadata of the header information 545 of the packet 540 may be associated with the application running on the client 102. The metadata associated with the application running on the client 120 for which the packet 540 is generated may include, for example, an indicator specifying that the packet 540 is application-specific, an account identifier for the client 102 (e.g., a user profile, email address, or screenname), an application identifier (e.g., a name of the application), a profile of the application (e.g., version number of the application), and a timestamp corresponding to generation of the packet 540. ¶ [0103], ¶ [0106], The connection information may include the connection tuple and/or the session information for a previously established connection. ¶ [0121]) into at least a first packet portion and
a second packet portion, said first packet including a first packet header
and a first packet payload (figs. 5B, 6, ¶ [0100], Each packet 540 received by the packet analyzer 505 may include header information 545 and a payload 550. ¶ [0106], ¶ [0108], ¶ [0110]), said first packet portion including at least a portion of said first packet header (figs. 5B, 6, ¶ [0100], Each packet 540 received by the packet analyzer 505 may include header information 545 and a payload 550. ¶ [0106], ¶ [0108], ¶ [0110], ¶ [0115], the tunnel selector 515 may select the encrypted tunnel 530a or the encrypted tunnel for header information 530c), said second packet portion including at least a portion of said first packet payload (figs. 5A-5C, ¶ [0115], the selected at least one communication tunnel 530a-n may correspond to at least one communication tunnel 530a-n that is unencrypted and/or unsecured. In some embodiments, the tunnel selector 515 may select the unencrypted tunnel for payload data 530b); communicating, in encrypted form, the first packet portion from
the first node to a second node; communicating, in unencrypted form, the second packet portion from the first node to the second node (figs. 5A-5C, ¶ [0115], the selected at least one communication tunnel 530a-n may correspond to at least one communication tunnel 530a-n that is unencrypted and/or unsecured. In some embodiments, the tunnel selector 515 may select the unencrypted tunnel for payload data 530b and the encrypted tunnel 530a or the encrypted tunnel for header information 530c, ¶ [0119], the communication engine 520a may split or partition the header information 545 and the payload 550 of the packet 540. ¶ [0120], ¶ [0117], ¶ [0096]).
Regarding claim 20, Dhanabalan teaches a non-transitory computer readable medium including a first set of computer executable instructions which when executed by a processor of a first node cause the first node (fig. 1C, ¶ [0140]) to perform the steps of: segmenting, at the first node, at least a first packet corresponding to a first
communications session (figs. 5A-5C, ¶ [0058], ¶ [0099], ¶ [0100], ¶ [0102], the metadata of the header information 545 of the packet 540 may be associated with the application running on the client 102. The metadata associated with the application running on the client 120 for which the packet 540 is generated may include, for example, an indicator specifying that the packet 540 is application-specific, an account identifier for the client 102 (e.g., a user profile, email address, or screenname), an application identifier (e.g., a name of the application), a profile of the application (e.g., version number of the application), and a timestamp corresponding to generation of the packet 540. ¶ [0103], ¶ [0106], The connection information may include the connection tuple and/or the session information for a previously established connection. ¶ [0121]) into at least a first packet portion and a second packet portion, said first packet including a first packet header and a first packet payload (figs. 5B, 6, ¶ [0100], Each packet 540 received by the packet analyzer 505 may include header information 545 and a payload 550. ¶ [0106], ¶ [0108], ¶ [0110]), said first packet portion including at least a portion of said first packet header (figs. 5B, 6, ¶ [0100], Each packet 540 received by the packet analyzer 505 may include header information 545 and a payload 550. ¶ [0106], ¶ [0108], ¶ [0110], ¶ [0115], the tunnel selector 515 may select the encrypted tunnel 530a or the encrypted tunnel for header information 530c), said second packet
portion including at least a portion of said first packet payload figs. 5A-5C, ¶ [0115], the selected at least one communication tunnel 530a-n may correspond to at least one communication tunnel 530a-n that is unencrypted and/or unsecured. In some embodiments, the tunnel selector 515 may select the unencrypted tunnel for payload data 530b); communicating, in encrypted form, the first packet portion from the first node to a second node; communicating, in unencrypted form, the second packet portion from the first node to the second node (figs. 5A-5C, ¶ [0115], the selected at least one communication tunnel 530a-n may correspond to at least one communication tunnel 530a-n that is unencrypted and/or unsecured. In some embodiments, the tunnel selector 515 may select the unencrypted tunnel for payload data 530b and the encrypted tunnel 530a or the encrypted tunnel for header information 530c, ¶ [0119], the communication engine 520a may split or partition the header information 545 and the payload 550 of the packet 540. ¶ [0120], ¶ [0117], ¶ [0096]).
Regarding claim 2, Dhanabalan teaches the communications method of claim 1, wherein communicating, in encrypted form, the first packet portion includes communicating the first packet portion using a secure communications tunnel which extends between the first node and the second node (figs. 5A-5C, ¶ [0115]).
Regarding claim 4, Dhanabalan teaches the communications method of claim 1, wherein the first packet portion includes the first packet header (figs. 5A-5C, ¶ [0117], The communication tunnel 530a-n with the defined level of security greater than or equal to the threshold level of security may be for delivering the header information 545 (and/or an identifier or digest) of the packet 540 (e.g., encrypted tunnel 530c). ¶ [0119], the communication engine 520a may split or partition the header information 545 and the payload 550 of the packet 540. Communicate the header information 545 via the selected communication tunnel 530a-n with a defined cryptographic algorithm and a level of encryption greater the threshold level of encryption); wherein the second packet portion includes bits of the first packet payload not included in said first packet portion; and wherein more bits of the first packet payload are included in said second packet portion than said first packet portion (figs. 5A-5C, ¶ [0117], ¶ [0119], the communication engine 520a may split or partition the header information 545 and the payload 550 of the packet 540. ¶ [0120], The communication engine 520a may insert, concatenate, append, or otherwise add the identifier for the payload 550 (e.g., the digest of the payload 550) to the header information 545. Where it is implicit that the payload 550 (not including the digest/identifier of the payload 550 added to the header 545) includes more bits than digest/identifier (included in the first portion/header)).
Regarding claim 7, Dhanabalan teaches the communications method of claim 1, further comprising: operating the second node to receive the first packet portion in encrypted form; operating the second node to receive the second packet portion in unencrypted form; operating the second node to decrypt the encrypted first packet portion to produce a decrypted first packet portion; and operating the second node to reconstruct the first packet from the decrypted first packet portion and unencrypted second packet portion to form a reconstructed first packet (fig 5C, ¶ [0122], The communication engine 520b may also receive the header information 545 and the payload 550 separately from multiple communication tunnels 530a-n (e.g., the encrypted tunnel 530c and the unencrypted tunnel 530b, or the encrypted tunnel 530a and the unencrypted tunnel 530b). ¶ [0124], the communication engine 520b may process the entirety of the packet 540 from the at least one communication tunnel 530a-n. The communication engine 520b may decrypt the packet 540 to generate a recovered packet 540′. The recovered packet 540′ may have a recovered header information 545′ and payload 550′. ¶ [0125]).
Regarding claim 8, Dhanabalan teaches the communications method of claim 7, further comprising: operating the second node to send the reconstructed first packet to a third node which is an intended destination of the first packet, said third node being an end node of the first communications session (¶ [0122], When running on the client-side appliance 200a, the communication engine 520b may route or forward the recovered packet 540′ to the client 102 via the network 104. When running on the server-side appliance 200b, the communication engine 520b may route or forward the recovered packet 540′ to the server 106 via the network 104″. ¶ [0125]).
Regarding claim 9, Dhanabalan teaches the communications method of claim 1, further comprising: making a decision, at the first node, based on an application type of a second communications session whether to communicate packets corresponding to the second communications session (¶ [0130], a lack of the connection information may indicate that the packet is a first packet to establish a new session and/or connection. ¶ [0103], ¶ [0106]) to said second node via a secure tunnel or by splitting the packets and sending first portions of packets of the second communications session to the second node via a secure tunnel and second portions of packets corresponding to the second communications session to the second node via a communication path which does not include a secure tunnel (¶ [0132], The sender network device may parse the header of the packet to identify metadata related to and/or indicative of the application. Certain applications may be associated with a particular security level. Using the metadata, the sender network device may identify the security level. The sender network device may determine whether the security level is greater than or equal to a threshold (630). The threshold may specify a type of cryptographic algorithm/mechanism/function and a threshold encryption level. If the security level is less than the threshold, the sender network device may select the encrypted tunnel. ¶ [0133]).
Regarding claim 10, Dhanabalan teaches the communications method of claim 9,
wherein making said decision includes deciding to communicate second communications session packets to the second node via a secure tunnel; and
wherein the method further comprises: operating the first node to communicate packets corresponding to said second communications session to said second node via a secure tunnel (¶ [0131], If the session identifier is not in the database, the sender network device may select (e.g., establish, identify and/or use) the encrypted tunnel for both the header and the payload (620). ¶ [0132], If the security level is less than the threshold, the sender network device may select the encrypted tunnel).
Regarding claim 11, Dhanabalan teaches the communications method of claim 10, further comprising: operating the second node to receive packets corresponding to the second communications session via said secure tunnel in encrypted form; operating the second node to recover packets corresponding to the second communications session by decrypting the received packets corresponding to the second communications session; and operating the second node to forward recovered packets corresponding to the second communication session to an end node of said second communications session (fig. 5C, ¶ [0122]-¶ [0127], ¶ [0130]-¶ [0132]).
Regarding claim 13, Dhanabalan teaches the communications system of claim 12, wherein communicating, in encrypted form, the first packet portion includes communicating the first packet portion using a secure communications tunnel which extends between the first node and the second node (figs. 5A-5C, ¶ [0115]).
Regarding claim 15, Dhanabalan teaches the communications system of claim 12, wherein the second packet portion includes bits of the first packet payload not included in said first packet portion (figs. 5A-5C, ¶ [0117], The communication tunnel 530a-n with the defined level of security greater than or equal to the threshold level of security may be for delivering the header information 545 of the packet 540 (e.g., encrypted tunnel 530c). ¶ [0119], the communication engine 520a may split or partition the header information 545 and the payload 550 of the packet 540. Communicate the header information 545 via the selected communication tunnel 530a-n with a defined cryptographic algorithm and a level of encryption greater the threshold level of encryption); and wherein more bits of the first packet payload are included in said second packet portion than said first packet portion (figs. 5A-5C, ¶ [0104], ¶ [0117], ¶ [0119], the communication engine 520a may split or partition the header information 545 and the payload 550 of the packet 540. ¶ [0120]. Where it is implicit that the payload 550 (not including the header 545 or header 545 with the digest/identifier of the payload 550) includes more bits than digest/identifier (included in the first portion/header)).
Regarding claim 16, Dhanabalan teaches the communications system of claim 12, wherein the second node includes a second processor, the second processor
controlling the second node to perform the following operations: receive the first packet portion in encrypted form; receive the second packet portion in unencrypted form;
decrypt the encrypted first packet portion to produce a decrypted first
packet portion; reconstruct the first packet from the decrypted first packet portion and
unencrypted second packet portion to form a reconstructed first packet; and
send the reconstructed first packet to a third node which is an intended
destination of the first packet, said third node being an end node in the first communications session (fig 5C, ¶ [0122], The communication engine 520b may also receive the header information 545 and the payload 550 separately from multiple communication tunnels 530a-n (e.g., the encrypted tunnel 530c and the unencrypted tunnel 530b, or the encrypted tunnel 530a and the unencrypted tunnel 530b). When running on the client-side appliance 200a, the communication engine 520b may route or forward the recovered packet 540′ to the client 102 via the network 104. When running on the server-side appliance 200b, the communication engine 520b may route or forward the recovered packet 540′ to the server 106 via the network 104″.. ¶ [0124], the communication engine 520b may process the entirety of the packet 540 from the at least one communication tunnel 530a-n. The communication engine 520b may decrypt the packet 540 to generate a recovered packet 540′. The recovered packet 540′ may have a recovered header information 545′ and payload 550′. ¶ [0125]).
Regarding claim 17, Dhanabalan teaches the communications system of claim 12, wherein the first processor further controls the first node to perform the following additional operations: making, at the first node, a decision based on an application type of a second communications session whether to communicate packets corresponding to the second communications session (¶ [0130], a lack of the connection information may indicate that the packet is a first packet to establish a new session and/or connection. ¶ [0103], ¶ [0106]) to said second node via a secure tunnel or by splitting the packets and sending first portions of packets of the second communications session to the second node via a secure tunnel and second portions of packets corresponding to the second communications session to the second node via a communication path which does not include a secure tunnel (¶ [0132], The sender network device may parse the header of the packet to identify metadata related to and/or indicative of the application. Certain applications may be associated with a particular security level. Using the metadata, the sender network device may identify the security level. The sender network device may determine whether the security level is greater than or equal to a threshold (630). The threshold may specify a type of cryptographic algorithm/mechanism/function and a threshold encryption level. If the security level is less than the threshold, the sender network device may select the encrypted tunnel. ¶ [0133]).
Regarding claim 18, Dhanabalan teaches the communications system of claim 17, wherein making said decision includes deciding to communicate second
communications session packets to the security function node via a secure tunnel; and
wherein the first processor further controls the first node to perform the
following additional operation: communicating packets corresponding to said second communications session to said second node via a secure tunnel (¶ [0131], If the session identifier is not in the database, the sender network device may select (e.g., establish, identify and/or use) the encrypted tunnel for both the header and the payload (620). ¶ [0132], If the security level is less than the threshold, the sender network device may select the encrypted tunnel).
Regarding claim 19, Dhanabalan teaches the communications system of claim 18, wherein the second processor further controls the second node to perform the following additional operations: receive packets corresponding to the second communications session via said secure tunnel in encrypted form; recover packets corresponding to the second communications session by decrypting the received packets corresponding to the second communications session; and forward recovered packets corresponding to the second communication session
to an end node of said second communications session (fig. 5C, ¶ [0122]-¶ [0127], ¶ [0130]-¶ [0132]).
Claim Rejections - 35 USC § 103
5. 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.
6. The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
7. Claims 3 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Dhanabalan in view of Mehta et al. (US 2021/0306900 A1, hereinafter “Mehta”).
Regarding claims 3 and 14, Dhanabalan teaches the communications method of claim 2, wherein the secure communications tunnel is an Internet Protocol Security (IPSec) secure tunnel (¶ [0096]).
Dhanabalan does not explicitly teach wherein the first node is a wireless base station; wherein the second node is located in a core network.
However, Dhanabalan teaches one or more clients 102(1)-102(n) in communication with one or more servers 106(1)-106(n) via one or more networks 104(1)-104n (generally referred to as network(s) 104). Where Networks 104 may employ one or more types of physical networks and/or network topologies, such as wired and/or wireless networks or cellular networks (figs. 1A, 1C, 5A, ¶ [0039], ¶ [0040], ¶ [0043], ¶ [0052], [0055] and ¶ [0058], appliance 200 may be implemented as a server, gateway, router, switch, bridge or other type of computing or network device. ¶ [0060], ¶ [0093], ¶ [0094]).
Further, it is well known in the art to utilize an IPSec secure tunnel between a base station and a node located in a core network, as evidenced by fig. 3 of Mehta.
Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to utilize the method of Dhanabalan in a cellular network (i.e., utilize a wireless base station as the first node and a node located in the core network as the second node) to further improve industrial applicability.
Allowable Subject Matter
8. Claims 5 and 6 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.
9. The following is a statement of reasons for the indication of allowable subject matter:
Regarding claim 5, prior art of record fails to teach or render obvious “wherein said first portion of the first packet payload included in the first packet portion is a first amount of the first packet payload, said first amount being smaller in size than a second amount which would cause a delay greater than a first threshold value” in combination with limitations specified in the base claim.
Regarding claim 6, prior art of record fails to teach or render obvious “wherein said first portion of the first packet payload included in the first packet portion is a first amount of the first packet payload, said first packet payload including user data, said first amount being small enough that a delay in communicating the first packet portion from the first node to the second node, introduced by the addition of the first amount of the first payload in said first packet portion, is below a service provider threshold” in combination with limitations specified in the base claim.
Double Patenting
10. The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP § 2146 et seq. for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The filing of a terminal disclaimer by itself is not a complete reply to a nonstatutory double patenting (NSDP) rejection. A complete reply requires that the terminal disclaimer be accompanied by a reply requesting reconsideration of the prior Office action. Even where the NSDP rejection is provisional the reply must be complete. See MPEP § 804, subsection I.B.1. For a reply to a non-final Office action, see 37 CFR 1.111(a). For a reply to final Office action, see 37 CFR 1.113(c). A request for reconsideration while not provided for in 37 CFR 1.113(c) may be filed after final for consideration. See MPEP §§ 706.07(e) and 714.13.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
11. Claims 1, 2, 4-13 and 15-20 are rejected on the ground of nonstatutory double patenting as being unpatentable over claims 1-20 of U.S. Patent No. 12,028,747 B2. Although the claims at issue are not identical, they are not patentably distinct from each other because:
Regarding claim 1, claim 1 of U.S. Patent No. 12,028,747 B2 teaches a communications method, the method comprising: segmenting, at a first node, at least a first packet corresponding to a first communications session into at least a first packet portion and a second packet portion, said first packet including a first packet header and a first packet payload, said first packet portion including at least a portion of said first packet header and a first portion of the first packet payload, said second packet portion including at least a second portion of said first packet payload; communicating, in encrypted form, the first packet portion from the first node to a second node; and
communicating, in unencrypted form, the second packet portion from the first
node to the second node.
Claim 1 merely broadens the scope of claim 1 of U.S. Patent No. 12,028,747 B2 by removing limitation (e.g., wherein said communicating, in encrypted form, the first packet portion includes communicating the first packet portion with a first packet identifier; wherein said communicating, in unencrypted form, the second packet portion includes communicating the second packet portion with the first packet identifier) from claim 1 of U.S. Patent No. 12,028,747 B2.
Regarding claim 2, claim 2 of U.S. Patent No. 12,028,747 B2 teaches wherein communicating, in encrypted form, the first packet portion includes communicating the first packet portion using a secure communications tunnel which extends between the first node and the second node.
Regarding claim 4, claim 9 of U.S. Patent No. 12,028,747 B2 teaches wherein the first packet portion includes the first packet header; wherein the second packet portion includes bits of the first packet payload not included in said first packet portion; and wherein more bits of the first packet payload are included in said second packet
portion than said first packet portion.
Regarding claim 5, claim 10 of U.S. Patent No. 12,028,747 B2 wherein said first portion of the first packet payload included in the first packet portion is a first amount of the first packet payload, said first amount being smaller in size than a second amount which would cause a delay greater than a first threshold value.
Regarding claim 6, claim 11 of U.S. Patent No. 12,028,747 B2 wherein said first portion of the first packet payload included in the first packet portion is a first amount of the first packet payload, said first packet payload including user data, said first amount being small enough that a delay in communicating the first packet portion from the first node to the second node, introduced by the addition of the first amount of the first payload in said first packet portion, is below a service provider threshold.
Regarding claim 7, claim 3 of U.S. Patent No. 12,028,747 B2 teaches further comprising: operating the second node to receive the first packet portion in encrypted form; operating the second node to receive the second packet portion in unencrypted
form; operating the second node to decrypt the encrypted first packet portion to
produce a decrypted first packet portion; and operating the second node to reconstruct the first packet from the decrypted first packet portion and unencrypted second packet portion to form a reconstructed first packet.
Regarding claim 8, claim 3 of U.S. Patent No. 12,028,747 B2 teaches further comprising: operating the second node to send the reconstructed first packet to a third node which is an intended destination of the first packet, said third node being an end node of the first communications session.
Regarding claim 9, claim 4 of U.S. Patent No. 12,028,747 B2 teaches making a decision, at the first node, based on an application type of a second communications session whether to communicate packets corresponding to the second communications session to said second node via a secure tunnel or by splitting the packets and sending first portions of packets of the second communications session to the second node via a secure tunnel and second portions of packets corresponding to the second communications session to the second node via a communication path which does not include a secure tunnel.
Regarding claim 10, claim 5 of U.S. Patent No. 12,028,747 B2 teaches wherein making said decision includes deciding to communicate second communications session packets to the second node via a secure tunnel; and wherein the method further comprises: operating the first node to communicate packets corresponding to said second communications session to said second node via a secure tunnel.
Regarding claim 11, claim 7 of U.S. Patent No. 12,028,747 B2 teaches operating the second node to receive packets corresponding to the second communications session via said secure tunnel in encrypted form; operating the second node to recover packets corresponding to the second communications session by decrypting the received packets corresponding to the second communications session; and
operating the second node to forward recovered packets corresponding to the
second communication session to an end node of said second communications session.
Regarding claim 12, claim 12 of U.S. Patent No. 12,028,747 B2 teaches a communications system comprising: a first node, said first node including: memory; and
a first processor, said first processor controlling the first node to perform the following operations: segmenting, at the first node, at least a first packet corresponding to a first communications session into at least a first packet portion and a second packet portion, said first packet including a first packet header and a first packet payload, said first packet portion including at least a portion of said first packet header, said second packet portion including at least a portion of said first packet payload; communicating, in encrypted form, the first packet portion from the first node to a second node; communicating, in unencrypted form, the second packet portion from the first node to the second node.
Claim 12 merely broadens the scope of claim 12 of U.S. Patent No. 12,028,747 B2 by removing limitation (e.g., wherein said communicating, in encrypted form, the first packet portion includes communicating the first packet portion with a first packet identifier; wherein said communicating, in unencrypted form, the second packet portion includes communicating the second packet portion with the first packet identifier) from claim 12 of U.S. Patent No. 12,028,747 B2.
Regarding claim 13, claim 13 of U.S. Patent No. 12,028,747 B2 teaches wherein communicating, in encrypted form, the first packet portion includes communicating the first packet portion using a secure communications tunnel which extends between the first node and the second node.
Regarding claim 15, claim 19 of U.S. Patent No. 12,028,747 B2 teaches wherein the first packet portion includes the first packet header; wherein the second packet portion includes bits of the first packet payload not included in said first packet portion; and wherein more bits of the first packet payload are included in said second packet
portion than said first packet portion.
Regarding claim 16, claim 14 of U.S. Patent No. 12,028,747 B2 teaches wherein the second node includes a second processor, the second processor controlling the second node to perform the following operations: receive the first packet portion in encrypted form; receive the second packet portion in unencrypted form; decrypt the encrypted first packet portion to produce a decrypted first packet portion; reconstruct the first packet from the decrypted first packet portion and unencrypted second packet portion to form a reconstructed first packet; and send the reconstructed first packet to a third node which is an intended destination of the first packet, said third node being an end node in the first communications session.
Regarding claim 17, claim 15 of U.S. Patent No. 12,028,747 B2 teaches
wherein the first processor further controls the first node to perform the following additional operations: making, at the first node, a decision based on an application type of a second communications session whether to communicate packets corresponding to the second communications session to said second node via a secure tunnel or by splitting the packets and sending first portions of packets of the second communications session to the second node via a secure tunnel and second portions of packets corresponding to the second communications session to the second node via a communication path which does not include a secure tunnel.
Regarding claim 18, claim 16 of U.S. Patent No. 12,028,747 B2 teaches
wherein making said decision includes deciding to communicate second communications session packets to the security function node via a secure tunnel; and
wherein the first processor further controls the first node to perform the following additional operation: communicating packets corresponding to said second communications session to said second node via a secure tunnel.
Regarding claim 19, claim 17 of U.S. Patent No. 12,028,747 B2 teaches wherein the second processor further controls the second node to perform the following additional operations: receive packets corresponding to the second communications session via said secure tunnel in encrypted form; recover packets corresponding to the second communications session by decrypting the received packets corresponding to the second communications session; and forward recovered packets corresponding to the second communication session to an end node of said second communications session.
Regarding claim 20, claim 20 of U.S. Patent No. 12,028,747 B2 teaches a non-transitory computer readable medium including a first set of computer executable instructions which when executed by a processor of a first node cause the first node to perform the steps of: segmenting, at the first node, at least a first packet corresponding to a first communications session into at least a first packet portion and a second packet portion, said first packet including a first packet header and a first packet payload, said first packet portion including at least a portion of said first packet header, said second packet portion including at least a portion of said first packet payload; communicating, in encrypted form, the first packet portion from the first node to a second node;
communicating, in unencrypted form, the second packet portion from the first
node to the second node.
Claim 20 merely broadens the scope of claim 20 of U.S. Patent No. 12,028,747 B2 by removing limitation (e.g., wherein said communicating, in encrypted form, the first packet portion includes communicating the first packet portion with a first packet identifier; wherein said communicating, in unencrypted form, the second packet portion includes communicating the second packet portion with the first packet identifier) from claim 20 of U.S. Patent No. 12,028,747 B2.
12. Claims 3 and 14 are rejected on the ground of nonstatutory double patenting as being unpatentable over claim 6 of U.S. Patent No. 12,028,747 B2 in view of Mehta.
Regarding claims 3 and 14, claim 6 of U.S. Patent No. 12,028,747 B2 teaches wherein the communication method of claim 1 or 12.
Claim 6 of U.S. Patent No. 12,028,747 B2 does not explicitly teach the first node is a wireless base station; wherein the second node is located in a core network; and wherein the secure communications tunnel is an Internet Protocol Security
(IPSec) secure tunnel.
Mehta teaches a first node is a wireless base station; a second node is located in a core network; and wherein a secure communications tunnel is an Internet Protocol Security (IPSec) secure tunnel (fig. 3).
Thus, it would have been obvious to one of ordinary skill in the art, before the effective filing date of the invention, to utilize a wireless base station as the first node communicating using an IPsec secure tunnel with a second node located in the core in the claim 1 or 12 of U.S. Patent No. 12,028,747 B2 to further improve industrial applicability.
Conclusion
13. The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Ragireddy et al. (US 7,360,083 B1).
14. Any inquiry concerning this communication or earlier communications from the examiner should be directed to MANDISH RANDHAWA whose telephone number is (571)270-5650. The examiner can normally be reached Monday-Thursday (9 AM-7 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, Chirag Shah can be reached at 571-272-3144. 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.
/MANDISH K RANDHAWA/Primary Examiner, Art Unit 2477
Prosecution Insights