DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA . This action is in response to the communication filed on 12/14/2023. Claims 1-9, 11-12, 14-18, 20, 34, 36 are pending.
Examiner Note
The examiner is here to serve, to assist, and to help applicant to the very best of his ability. The Primary Patent Examiner position is a position of serving and it is an honor to externally serve the applicant and attorney and to internally serve junior examiners and supervisors. The goal of the examiner is to work with and assist applicant to move cases along as efficiently as possible.
Applicant is encouraged to call examiner to schedule an interview if applicant has any questions about this action, wants to discuss any possible paths forward, has proposed amendments to the claims to run by the examiner, or for any other issues that applicant would like to discuss.
Examiner can normally be reached at (571) 270-3863 or michael.keller@uspto.gov, Monday-Friday, from about 6 AM - 10 PM EST and if your call is missed examiner will try to return call quickly, thank you.
Priority
This application claims priority of PCT/CN2021/104039, filed 7/1/2021. The assignee of record is Telefonaktiebolaget LM Ericsson (publ). The listed inventor(s) is/are: Xu, Wenliang.
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 12/14/2023, 6/26/2025 is/are in compliance with the provisions of 37 CFR 1.97. Accordingly, the IDS(s) is/are being considered by the examiner.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-2, 5-9, 11-12, 14-17, 20, 34, & 36 is/are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Zhou (WO 2017124820 A1, published 7/27/2017, English translation provided with the office action completed 2/2026; hereinafter WO820).
For Claim 1, WO820 teaches a method performed by a server, comprising (To make it easier to reference for the applicant and the examiner, the examiner is first providing a complete reproduction of the English translation of Example 6. Throughout claim 1, examiner will be referring to the passage below.
Examiner recommends to skip to the mapping of the limitations and then to reference back up to the provided section, thank you.
Please see WO820 Pg 38-42 reproduced below, thank you:
Example six:
As shown in FIG. 15 , in this example, the example provides a third-party application service deployment method, including:
Step 801: The third-party application decides to deploy a new type of service, and the third-party application provides the SCEF entity with a service feature field of the service, where the service feature field may be an application IP quintuple, or a URL, or a server IP. Address, IP address segment. The third-party application may also provide the service-related description information to the SCEF entity. The service-related description information may be the service type, the QoS required by the service, the type of the service, and whether the third-party deployment of the service data is applied to the operator. The indication information of the service function entity in the network, if the third-party application deploys multiple service function entities in the carrier network, the corresponding service function entity identification information is also carried.
Step 802: The SCEF entity sends a reply confirmation message to the third party application.
Step 803: The SCEF entity authorizes the request of the third-party application, and determines an application identifier (here denoted as the application identifier 1), a charging policy, and a QoS policy of the service. The charging policy includes the charging button to be set for the application, and the QoS policy includes the QCI and ARP to be set by the application. If a third-party service function entity deployed in the carrier network is to be applied to the data of the application, the operator also authorizes the application third-party service function entity.
Step 804: The SCEF entity provides policy rule provision to the PCRF entity, including application identifier 1, charging policy, QoS policy, and service function entity indication information (which may further include service function entity identifier information).
Step 805: The PCRF entity replies with a confirmation message.
Step 806: Optionally, the PCRF entity saves the received information.
Step 807: The SCEF entity sets the service feature field and the corresponding application identifier (ie, the application identifier) 1) Provided as an application feature rule (here denoted as application feature rule 1) to the RDB entity, the RDF entity updates the application feature rule 1 to the local save application signature database.
Step 808: The RDB entity replies to the SCEF entity with a confirmation message.
At the same time, the operator's BOSS performs policy configuration for the user subscription update and the PCRF entity, for example, updating the user subscription to increase whether the subscription user can access the application, and whether to apply the subscription information such as the subscription information of the service function entity provided by the third-party application, etc. The configuration policy of the PCRF entity is updated so that the PCRF can formulate corresponding PCC/ADC rules for detecting and controlling the service.
Steps 809 to 816 are processes for the RDB entity to perform application detection and control for the user who newly attaches or newly establishes an IP-CAN session after applying the feature rule 1.
Step 809: The UE attaches to the network or requests to establish an IP-CAN session.
Step 810: The PCEF entity interacts with the PCRF entity to establish an IP-CAN session, and the PCRF sends a PCC rule to the PCEF.
Step 811: The PCRF entity determines, according to the subscription information of the user, that the user can access the application provided by the third-party application in step 801, and the PCRF entity sends one or a group of ADC rules to carry the application identifier 1 and the TSC policy. The ADC rule may also carry a charging policy and a QoS policy. The PCRF determines the TSC policy according to the service function entity indication information. The TDF/TSSF entity installs the delivered ADC rules. The PCRF entity may need to interact with the SPR entity to obtain the user's subscription information.
Step 812: The TDF/TSSF replies to the PCRF with an acknowledgement message.
Step 813: When the UE accesses the application, the TDF/TSSF entity detects the IP address, IP quintuple or URL of the application accessed by the user.
Step 814: The TDF/TSSF entity reports the detected IP address, IP quintuple or URL to the RDB entity.
Step 815: The RDB entity performs matching according to the application signature database, and returns to the TDF/TSSF entity. Returns the matching application ID 1. The RDB entity herein is also one of the application detection control entities in the foregoing embodiment.
Step 816: The TDF/TSSF entity executes the TSC policy corresponding to the ADC rule 1 according to the application identifier 1.
Steps 817 through 822 are directed to users who have attached or have established an IP-CAN session when the RDB receives the application feature rule 1.
Step 817: The PCRF entity determines, according to the subscription information of the user, that the user can access the application provided by the third-party application in step 801, and the PCRF entity updates the ADC rule to the TDF/TSSF entity. The updated ADC rule carries the application identifier 1 and the TSC policy. The ADC rule may also carry a charging policy and a QoS policy. The PCRF entity determines the TSC policy based on the service function entity indication information. The PCRF entity may need to interact with the SPR entity to obtain a user's subscription.
Step 818: The TDF/TSSF entity replies with a confirmation message.
Step 819: The service data detection, the service data detection may include: when the UE accesses the service, the TDF/TSSF entity detects an IP address, an IP quintuple or a URL of the application accessed by the user.
Step 820: The TDF/TSSF entity sends a service feature field obtained by detecting the service data to the RDB entity. The detected service feature field herein may be an IP address, an IP quintuple or a URL of the service.
Step 821: The RDB entity performs matching according to the application signature database, and returns a corresponding application identifier 1 to the TDF/TSSF entity.
Step 822: The service data routing control may specifically include: determining, by the TDF/TSSF entity, the TSC policy corresponding to the ADC rule 1 according to the application identifier 1, and performing the TSC policy on the service data, and controlling whether the service data is routed to the The business function entity of the three application deployment.
In an example, the PCRF entity provides the TDF/TSSF entity to the TDF/TSSF entity upon receiving the application feature rule generated by the SCEF entity. In other embodiments, the PCRF entity can determine whether there is an already attached UE that can access the application, and if so, the PCRF entity immediately The TDF/TSSF entity provides an application feature rule generated after pre-processing; if not, the PCRF entity provides an application feature rule to the TDF/TSSF entity after the PCRF entity detects that the UE that can access the application attaches or establishes an IP-CAN session.
In Example 5 and Example 6, the PCRF entity provides an ADC rule to the TDF/TSSF entity, and the TDF/TSSF entity interacts with the RDB entity to obtain an application identity, thereby executing the ADC rule according to the application identity. Similarly, the PCRF entity provides a PCC rule to the PCEF entity, and the TDF/TSSF entity interacts with the RDB entity to obtain an application identifier, thereby executing the PCC rule according to the application identifier.
In an example, the SCEF entity may determine the TSC policy based on the service function entity indication information and provide it to the PCRF entity. The PCRF entity may include the TSC policy in the determined PCC/ADC rules.):
sending a packet flow description (PFD) management request (WO820 step 801) to an exposure function entity (WO820 step 801), wherein the PFD management request comprises at least one PFD comprising information used for traffic detection of a specific application service (WO820 step 801) and an application identifier corresponding to the specific application service (WO820 step 803); and
providing specific quality of service (QoS) information (WO820 step 803) and the application identifier corresponding to the specific application service (WO820 step 804) for requesting data session with the specific QoS to a policy function entity (WO820 step 804).
For Claim 2, WO820 teaches the method according to claim 1, wherein the information used for traffic detection of the specific application service comprises at least one of a domain name or a uniform resource locator (WO820 step 801).
For Claim 5, WO820 teaches the method according to claim 1, wherein providing the specific QoS information and the application identifier corresponding to the specific application service for requesting data session with the specific QoS to the policy function entity comprises: directly sending a message comprising the specific QoS information and the application identifier corresponding to the specific application service for requesting data session with the specific QoS to the policy function entity; or providing the specific QoS information and the application identifier corresponding to the specific application service for requesting data session with the specific QoS to the policy function entity via the exposure function entity (WO820 step 804).
For Claim 6, WO820 teaches the method according to claim 1, wherein the policy function entity comprises at least one of: policy control function (PCF), or policy and charging rules function (PCRF) (WO820 step 811).
For Claim 7, WO820 teaches the method according to claim 1, wherein the exposure function entity comprises at least one of: network exposure function (NEF), or service capability exposure function (SCEF) (WO820 step 801).
For Claim 8, WO820 teaches the method according to claim 1, wherein the server comprises at least one of: an edge enabler server; or an application server (WO820 step 801).
For Claim 9, WO820 teaches the method according to claim 1, wherein when the server is an edge enabler server, the method further comprises: receiving a request for establishing a data session with the specific QoS from an edge application server (WO820 step 801), wherein the request comprises the information used for traffic detection of the specific application service (WO820 step 801-803).
For Claim 11, WO820 teaches the method according to claim 9, wherein when the application identifier corresponding to the specific application service is absent in the request, the method further comprises: deriving the application identifier corresponding to the specific application service (WO820 step 803).
For Claim 12, WO820 teaches the method according to claim 9, further comprising: checking whether the edge application server is authorized (WO820 step 803).
For Claim 14, WO820 teaches the method according to claim 9, further comprising: sending a response for the request to the edge application server (WO820 step 802).
For Claim 15, WO820 teaches the method according to claim 9, wherein the data session comprises a protocol data unit (PDU) data session between an application client and the edge application server (WO820 step 809 & step 813).
For Claim 16, WO820 teaches a method performed by an edge application server, comprising: sending a request for establishing a data session with specific quality of service (QoS) to an edge enabler server (WO820 step 801), wherein the request comprises information used for traffic detection of a specific application service (WO820 step 801-803).
For Claim 17, WO820 teaches the method according to claim 16, wherein the information used for traffic detection of the specific application service comprises at least one of a domain name or a uniform resource locator (WO820 step 801).
For Claim 20, WO820 teaches the method according to claim 16, wherein the traffic detection of the specific application service comprises encrypted traffic detection of the specific application service (WO820 step 801).
For Claim(s) 34, the claim(s) is/are substantially similar to claim 1 and therefore is/are rejected for the same reasoning set forth above.
For Claim(s) 36, the claim(s) is/are substantially similar to claim 16 and therefore is/are rejected for the same reasoning set forth above.
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.
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.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 3-4, 18 is/are rejected under 35 U.S.C. 103 as being unpatentable over WO820 in view of Neystadt et al. (US 20200186501 A1, published 6/11/2020; hereinafter Ney).
For Claim 3, WO820 teaches the method according to claim 2, WO820 does not explicitly teach wherein the domain name comprises Transport Layer Security Server Name Indication (TLS SNI).
However, Ney teaches wherein the domain name comprises Transport Layer Security Server Name Indication (TLS SNI) (Ney ¶ 0018 cloud-hosted proxy server receives this request preferably in an encrypted form (e.g., using HTTP over TLS), with the proxy hostname being in the TLS SNI field. Please also see Ney ¶ 0058, 0078).
Ney and WO820 are analogous art because they are both related to network traffic.
Before the effective filing date of the claimed invention it would have been obvious to one of ordinary skill in the art to use the encryption techniques and the TLS SNI filed of Ney with the system of WO820 because the proxy can select and apply the correct security policy, as well as authenticate/authorize the client and create audit log of the client activities with it against that client identifier (Ney ¶ 0018).
For Claim 4, WO820 teaches the method according to claim 1, WO820 does not explicitly teach wherein the traffic detection of the specific application service comprises encrypted traffic detection of the specific application service. However, Ney teaches wherein the traffic detection of the specific application service comprises encrypted traffic detection of the specific application service (Ney ¶ 0018).
For Claim 18, WO820 teaches the method according to claim 16, WO820 does not explicitly teach wherein the domain name comprises Transport Layer Security Server Name Indication (TLS SNI). However, Ney teaches wherein the domain name comprises Transport Layer Security Server Name Indication (TLS SNI) (Ney ¶ 0018).
Citation of Pertinent Prior Art
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is listed below, thank you:
i. WO 2020127148 A1, USER DATA TRAFFIC HANDLING
Please see PTO-892 for additional listing of relevant prior art made of record but not relied upon, thank you.
Conclusion
Any inquiry concerning communications from the examiner should be directed to Michael Keller at (571)270-3863 or michael.keller@uspto.gov. If attempts to reach the examiner are unsuccessful, the examiner’s supervisor, Brian Gillis can be reached on 571-272-7952.
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.
/MICHAEL A KELLER/
Primary Patent Examiner, Art Unit 2446