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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 12/22/2025 has been entered.
DETAILED ACTION
Claims 26-43 are presented for examination.
This is a first action on the merits based on Applicant’s claims submitted 12/22/2025.
In this RCE filed, Applicant amended claims 26, 28, 31, 35, 37, and 40. Claims 1-25 have been cancelled. Currently, claims 26-43 are pending for examination.
Foreign Priority
Acknowledgment is made of applicant' s claim for foreign priority under 35 U.S.C. 119 (a)-(d).
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Specification
The specification has been reviewed and accepted.
Examiner’s Note: Telephonic Interview Request
Examiner attempted to reach out to Attorney on record on April 1, 2026 in an effort to advance prosecution, but no reply was received.
Response to Arguments
Regarding rejection under 35 USC § 103, the arguments filed 12/22/2025 have been considered but are not persuasive to overcome the references on record: Motorola Mobility, et al. (NPL: Update of Solution 1 (UE-Assisted), hereinafter “Motorola”) in view of Csaszar et al. (US 2010/0250930 A1, hereinafter “Csaszar”).
In claim 26:
Applicant states that “Motorola discloses methods for packet filtering for encrypted data traffic but otherwise is unrelated to content filtering. Motorola inserts an AppKey into the packet header to assist the network in identifying Packet Detection Rules (PDRs) to classify packet flows, which can then be subjected to Forwarding Action Rules (FARs), QoS Enforcement Rules (QERs), and Usage Reporting Rules (URRs). The UPF applying the PDRs is not aware of application layer content contained in the body of the packet and does not filter packets based on content. PDRs are not used for content filtering. For example, a PDR as described in Motorola would treat packets containing adult content as normal HTTP traffic. Motorola also makes no mention of the domain name of the content server or of filtering packets based on application layer content.” Examiner notes that the claim language broadly recites content filtering. Figure 6.1.2.3-1 steps 4-6 clearly shows UPF extracting AppKey, which is part of the header of the packet. This extraction, under BRI, is considered content filtering. The claims do not specify what kind of content is being filtered.
Applicant also states that “Because the body of the claim refers to elements defined in the preamble, the preamble limitations are because the preamble limitations are needed to give life and meaning to the claims.” However, Examiner notes that MPEP 2111.02 states that “if the body of a claim fully and intrinsically sets forth all of the limitations of the claimed invention, and the preamble merely states, for example, the purpose or intended use of the invention, rather than any distinct definition of any of the claimed invention’s limitations, then the preamble is not considered a limitation and is of no significance to claim construction”. In the claims, the preamble explains the data packet flow, which according to prior art of record (for example, Motorola), is known in the art. The preamble also states the data packet flow "encrypting a domain name". However, the body of the claim does not explicitly define what entity within the system is encrypting the data packets in the flow between the UE and the content provider. Therefore the claims as constructed are omitting steps and cannot be considered as “necessary to give life, meaning and vitality to the claim”.
Additionally, the Applicant states “Finally, Applicants notes that a person skilled the art would not be likely to modify Motorola to add a domain name in unencrypted form as suggested by Examiner.” The explanation of the rejection was set forth in the Response to Arguments section of the Final Rejection sent on 11/17/2025.
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 may not be obtained though the invention is not identically disclosed or described as set forth in section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the manner in which the invention was made.
Claims 26-32, 34-41, 43 rejected under 35 U.S.C. 103 as being unpatentable over *Motorola Mobility, et al. (NPL: Update of Solution 1 (UE-Assisted), hereinafter “Motorola”) in view of Csaszar et al. (US 2010/0250930 A1, hereinafter “Csaszar”).
*Provided by Applicant’s IDS.
Regarding claim 26, Motorola teaches:
26. (Currently Amended) A method for operating a policy control entity (Motorola: i.e. PCF) in a wireless communications network, in which a data packet flow (Motorola: i.e. service data flows, section 1.1) is provided for exchanging data packets between a user equipment and a content provider (Motorola: section 1.1), the data packet flow encrypting a domain name of the content provider (Examiner note: no patentability weight will be given to this portion of the preamble since the body of the claims do not require encryption of domain name), the method comprising the steps of:
receiving a user policy profile from a data repository, the user policy profile comprising a content filtering policy for filtering the data packets (Examiner notes that such language is an intended result of the receipt of the user policy profile) in the data packet flow (Motorola: page 9, “7. … SM policy, including the PCC rules… 8. …Packet Detection Rules… based on the received PCC rules…” and page 1, “PDRs … for detecting unencrypted data flows but also for detecting encrypted data flows.”) between the user equipment and content provider (Figure 6.1.2.3-1, step 4 – shows the packet is from UE to 5GC);
transmitting, to a session control entity (Motorola: i.e. SMF) of the wireless communications network, a session policy based on the user policy profile, the session policy instructing a user plane entity of the wireless communications network to filter the data packets (Examiner notes that such language is an intended result of the receipt of the user policy profile) in the data packet flow (Motorola: page 9, “7. … SM policy, including the PCC rules… 8. …Packet Detection Rules… based on the received PCC rules…” and page 1, “PDRs … for detecting unencrypted data flows but also for detecting encrypted data flows.”) between the user equipment and content provider (Figure 6.1.2.3-1, step 4-6); and
transmitting, to an access management entity (Motorola: i.e. access management entity) of the wireless communications network, a user policy based on the user policy profile, the user policy instructing the user equipment [to add the domain name in un-encrypted form} to the data packets in the data packet flow (Motorola: Fig. 6.1.2.2-1, steps 10a and 10b, using PDU session ID (initially provided by UE) is instructed to construct the packet) between the user equipment and content provider (Figure 6.1.2.3-1, step 4 – shows the packet is from UE to 5GC).
Motorola does not explicitly teach yet Csaszar teaches:
Adding domain name in un-encrypted form to the data packet (par 54: “end-host sends an address query to the DNS system… the end-host must know the address or corresponding destination identity of the DNS system for such queries. The DNS address could be a well-known address”; Examiner notes that Csaszar discloses decryption of the data packet, which implies ability to apply cryptography to the domain name and therefore encrypt and decrypt (i.e. un-encrypt)).
Accordingly, it would have been obvious to one having ordinary skill in the art before the effective filing date of the invention to have implemented the addition of the domain name in the data packet, utilizing a cryptographic method, as taught by Csaszar, to Motorola’s invention. The motivation to do so would have been in order to protect the routing of data packets in a packet data network (Csaszar: Abstract).
Regarding claim 27, same rationale for combination of Motorola and Csaszar, which combined in claim 26, applies here as it encompasses same subject matter. Therefore, the combination of Motorola and Csaszar teach
27. (Previously Presented) The method according to claim 26, wherein the session policy and/or the user policy comprise an identifier (Motorola: page 9, point 10; i.e. the UE receives message including application identities to activate encrypted traffic detection of data flow, see also Figure 6.1.2.2-1, steps 11-12) for indicating, to the user plane entity, transmission of the domain name in un-encrypted form (Examiner notes that this is being interpreted as intended use and therefore since Motorola recognizes an identifier, Motorola is capable of indicating the content of the data packet. Furthermore, Csaszar teaches in par 54: “end-host sends an address query to the DNS system… the end-host must know the address or corresponding destination identity of the DNS system for such queries. The DNS address could be a well-known address”; Examiner notes that Csaszar discloses decryption of the data packet, which implies ability to apply cryptography to the domain name and therefore encrypt and decrypt (i.e. un-encrypt)).
Regarding claim 28, Motorola teaches:
28. (Currently Amended) A method for operating a user plane entity in a wireless communications network, in which a data packet flow (Motorola: i.e. service data flows, section 1.1) is provided for exchanging data packets between a user equipment and a content provider (Motorola: section 1.1), the data packet flow encrypting a domain name of the content provider (Examiner’s note: no patentability weight will be given since the body of the claims do not require encryption of domain name), the method comprising the steps of:
receiving, from a session control entity of the wireless communications network, a session policy instructing the user plane entity to filter the data packets in the data packet flow (Motorola: page 9, “7. … SM policy, including the PCC rules… 8. …Packet Detection Rules… based on the received PCC rules…” and page 1, “PDRs … for detecting unencrypted data flows but also for detecting encrypted data flows.”) between the user equipment and content provider Figure 6.1.2.3-1, step 4 – shows the packet is from UE to 5GC);
filtering the data packets based on the session policy [and the extracted domain name] (Motorola: figure 6.1.2.3-1 steps 2-5, Examiner notes that figure 6.1.2.3-1 shows the filtering is also based on the AppKey).
Motorola does not teach yet Csaszar suggests:
receiving, from the user equipment, at least one data packet of the data packet flow between the user equipment and content provider comprising the domain name in un-encrypted form (Csaszar: par 54: “end-host sends an address query to the DNS system… the end-host must know the address or corresponding destination identity of the DNS system for such queries. The DNS address could be a well-known address”; Examiner notes that Csaszar discloses decryption of the data packet, which implies ability to apply cryptography to the domain name and therefore encrypt and decrypt (i.e. un-encrypt));
extracting the domain name from the at least one data packet in the data packet flow between the user equipment and content provider (Csaszar: fig. 7, 704); and
Filtering … based on extracted domain name (Csaszar: fig. 7, 708)
Accordingly, it would have been obvious to one having ordinary skill in the art before the effective filing date of the invention to have implemented the addition of the domain name in the data packet, utilizing a cryptographic method, and performed filtering based on the domain name as taught by Csaszar, to Motorola’s invention. The motivation to do so would have been in order to protect the routing of data packets in a packet data network (Csaszar: Abstract).
Regarding claim 29, same rationale for combination of Motorola and Csaszar, which combined in claim 28, applies here as it encompasses same subject matter. Therefore, the combination of Motorola and Csaszar teach:
29. (Previously Presented) The method according to claim 28, wherein the extracting step identifies the at least one data packet comprising the domain name in un-encrypted form by recognizing an identifier (Motorola: page 9, point 10; i.e. the UE receives message including application identities to activate encrypted traffic detection of data flow, see also Figure 6.1.2.2-1, steps 11-12), for indicating transmission of the domain name in un-encrypted form, in the at least one data packet (Examiner notes that this is being interpreted as intended use and therefore since Motorola recognizes an identifier, Motorola is capable of indicating the content of the data packet. Furthermore, Csaszar teaches in par 54: “end-host sends an address query to the DNS system… the end-host must know the address or corresponding destination identity of the DNS system for such queries. The DNS address could be a well-known address”; Examiner notes that Csaszar discloses decryption of the data packet, which implies ability to apply cryptography to the domain name and therefore encrypt and decrypt (i.e. un-encrypt)).
Regarding claim 30, the combination of Motorola and Csaszar teach:
30. (Previously Presented) The method according to claim 29, wherein the session policy comprises the identifier (Motorola: page 9, “10…AppKeys assist the detecting the application associated with … data flow”).
Regarding claim 31, Motorola teaches:
31. (Previously Presented) A method for operating a user equipment connectable to a wireless communications network for establishing a data packet flow (Motorola: i.e. service data flows, section 1.1) for exchanging data packets between the user equipment and a content provider (Motorola: section 1.1), the data packet flow encrypting a domain name of the content provider (Examiner’s note: no patentability weight will be given since the body of the claims do not require encryption of domain name), the method comprising the steps of:
transmitting the at least one data packet in the data packet flow between the user equipment and content provider to a user plane entity of the wireless communications network (Motorola: Figure 6.1.2.3-1, step 4 – shows the packet is from UE to 5GC).
Motorola does not teach yet Csaszar suggests:
adding, to at least one data packet of the data packet flow between the user equipment and content provider, the domain name in un- encrypted form (Csaszar: par 54: “end-host sends an address query to the DNS system… the end-host must know the address or corresponding destination identity of the DNS system for such queries. The DNS address could be a well-known address”; Examiner notes that Csaszar discloses decryption of the data packet, which implies ability to apply cryptography to the domain name and therefore encrypt and decrypt (i.e. un-encrypt)).
Accordingly, it would have been obvious to one having ordinary skill in the art before the effective filing date of the invention to have implemented the addition of the domain name in the data packet, utilizing a cryptographic method, as taught by Csaszar, to Motorola’s invention. The motivation to do so would have been in order to protect the routing of data packets in a packet data network (Csaszar: Abstract).
Regarding claim 32, same rationale for combination of Motorola and Csaszar, which combined in claim 31, applies here as it encompasses same subject matter. Therefore, the combination of Motorola and Csaszar teach
32. (Previously Presented) The method according to claim 31, further comprising adding, to the at least one data packet, an identifier (Motorola: page 9, point 10; i.e. the UE receives message including application identities to activate encrypted traffic detection of data flow, see also Figure 6.1.2.2-1, steps 11-12) for indicating transmission of the domain name in un-encrypted form (Examiner notes that this is being interpreted as intended use and therefore since Motorola recognizes an identifier, Motorola is capable of indicating the content of the data packet. Furthermore, Csaszar teaches in par 54: “end-host sends an address query to the DNS system… the end-host must know the address or corresponding destination identity of the DNS system for such queries. The DNS address could be a well-known address”; Examiner notes that Csaszar discloses decryption of the data packet, which implies ability to apply cryptography to the domain name and therefore encrypt and decrypt (i.e. un-encrypt)).
Regarding claim 34, the combination of Motorola and Csaszar teach:
34. (Previously Presented) The method according to claim 32, wherein the user policy comprises the identifier (Motorola: page 9, point 10; i.e. the UE receives message including application identities to activate encrypted traffic detection of data flow, see also Figure 6.1.2.2-1, steps 11-12).
Regarding claim 35, all claim limitations are set forth and rejected as it has been discussed in claim 26.
Regarding claim 36, all claim limitations are set forth and rejected as it has been discussed in claim 27.
Regarding claim 37, all claim limitations are set forth and rejected as it has been discussed in claim 28.
Regarding claim 38, all claim limitations are set forth and rejected as it has been discussed in claim 29.
Regarding claim 39, all claim limitations are set forth and rejected as it has been discussed in claim 30.
Regarding claim 40, all claim limitations are set forth and rejected as it has been discussed in claim 31.
Regarding claim 41, all claim limitations are set forth and rejected as it has been discussed in claim 32.
Regarding claim 43, all claim limitations are set forth and rejected as it has been discussed in claim 34.
Allowable Subject Matter
Claims 33, 42 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 an examiner's statement of reasons for allowance:
Prior art of record teaches:
Motorola Mobility, et al. (NPL: Update of Solution 1 (UE-Assisted) teaches, as already specified in TS 23.503, during the establishment/modification of an N4 session, the SMF provides to UPF Packer Detection Rules (PDRs), which are used in the UPF to detect selected traffic and perform actions on the detected traffic (e.g. drop, buffer, forward, duplicate, etc.).
In solution 1, the SMF provides one or more PDRs to UPF (as normally). They are used in UPF for detecting unencrypted data flows but also for detecting encrypted data flows. A PDR used for encrypted data flow detection includes one or more AppKeys in the Packer Detection Information (PDI) of the PDR rule. As an example, a PDR for encrypted data flow detection can indicate:
- Packet Detection Information: AppKey-1, AppKey-2
- Forwarding Action: Drop
When the UPF receives an incoming packer containing an AppKey that matches a PDR, then the UPF stores the 5-tuples of this packet and applies the PDR to all incoming packets having the same 5-tupie.
Therefore, to support encrypted traffic detection, solution 1 requires (a) a PDR provided to UPF to contain one or more AppKeys and (b) when the UPF receives an incoming packet containing an AppKey that marches a PDR, lO store the 5-tuples of this packet and to apply the PDR to all incoming packets having the same 5-tuple. The actions executed by UPF after detecting an encrypted data flow, can be any of the currently defined actions (specified in TS 23.503 and in TS 29.244).
Csaszar et al. (US 2010/0250930 A1) teaches a method and apparatus for protecting the routing of data packets in a packet data network. When a first end-host sends an address query to a DNS server system regarding a second end-host, the DNS server system responds by providing a destination parameter containing an encrypted destination address associated with the second end-host. Thereby, the first end-host is able to get across data packets to the second end-host by attaching the destination parameter to each transmitted data packet. A router in the packet data network admits a received packet if a destination parameter is attached to the pocket including a valid destination address encrypted by a key dependent on a distributed master encryption key. Otherwise, the router discards the packet if no such valid destination address can be derived from the packet by applying decryption to the destination parameter.
Dao et al. (US 2020/0145876 A1) teaches a method for handling delayed packets in a mobile wireless network performed by a PCF. The method includes receiving information pertaining to packet handling policy (PHP) parameters for a PDU session; and sending the PHP to other network functions for instructing devices in the user plane of the mobile wireless network how to handle delayed packets.
Aldor et al. (US 2010/0138910 A1) discloses methods, media, and perimeter gateways for encrypted-traffic URL filtering using address-mapping interception, methods including the steps of: providing a client system having a client application for accessing websites from web servers; upon the client application attempting to access an encrypted website, performing a name-to-address query to resolve a name of the encrypted website; intercepting address-mapping responses; creating a mapping between the name and at least one network address of the encrypted website; intercepting incoming encrypted traffic; extracting a server's network address from the incoming encrypted traffic; establishing a resolved name being accessed using the mapping; and filtering the resolved name. Preferably, the step of filtering includes redirecting the encrypted traffic. Preferably, the method further includes the step of: blocking all encrypted traffic for unresolved names.
Yadav (US 8,578,468 B1) teaches a method of client authentication that includes receiving an Internet protocol source address of a client packet and determining a packet origination, a network connection point, and a network path of the client packet. The method further includes comparing the determined packet origination with at least one packet origination associated with the client, comparing the determined network connection point with at least one network connection point associated with the client, and assessing a compatibility between the determined network path and at least one of the determined packet origination or the determined network connection point. The method includes signaling execution of client authentication challenges when either of the two comparisons fails and/or the determined network path is incompatible with at least one of the determined packet origination or the determined network connection point.
However, none of the prior art of record teach by themselves or in any combination nor would have anticipated nor render obvious by combination the claimed invention of the present invention at or before the time it was filed. The prior art of record is silent on " prior to the adding step, a step of: receiving, from an access management entity of the wireless communications network, a user policy instructing the user equipment to add the domain name in un- encrypted form in the data packet flow”, in combination with all other claim limitations of the independent claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant’s disclosure.
(1) Killion (US 2021/0392159 A1) teaches harvesting fully qualified domain names from malicious data packets.
(2) Leung et al. (US 8,973,088 B1) teaches policy enforcement using host information profile.
(3) Xie et al. (US 2012/0304244 A1) teaches malware analysis system.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to LIZBETH TORRES-DIAZ whose telephone number is (571)272-1787. The examiner can normally be reached on 9:00a-4:30p.
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 on (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 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.
/LIZBETH TORRES-DIAZ/Primary Examiner, Art Unit 2408
/April 3, 2026/
/ltd/