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 .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Response to Arguments
Applicant’s amendments with respect to the specification and abstract have been fully considered. The objection of the specification and abstract has been withdrawn.
Applicant’s amendments with respect to claim 5 and 13 have been fully considered. The objection of claim 5 and 13 has been withdrawn.
Applicant’s arguments with respect to claim(s) 1, 5, 9 and 13 have been fully considered, a new ground for rejection has been made in view of amendment. Claims 1, 5, 9 and 13 are rejected under 35 U.S.C 103 (See 103 rejection of claims 9 and 13 below).
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) 1, 5, 9 and 13 is/are rejected under 35 U.S.C. 103 as being unpatentable over US 20240171484 A1 (hereinafter Alonso), in view of “5G; 5G System; Technical Realization of Service Based Architecture; Stage 3”, 3GPP TS 29.500 version 17.8.0 Release 17 (2022-10) (hereinafter TS29500), and “List of IP protocol numbers”, Wikipedia, 10/3/2022 (hereinafter wiki)
Regarding claim 9, Alonso teaches A user plane function (UPF) in a wireless communication
system, the UPF comprising (Alonso UPF in Fig. 1; Fig. 13; [0091] FIG. 13 illustrates a User Plane Function (UPF). [0073] a User Plane Function, UPF, for providing data relating to tunneling traffic to a first network function, NF.):
a transceiver (Alonso communications interface 1302 in Fig. 13; [0509] the UPF 1300 may optionally comprise a communications interface 1302. The communications interface 1302 of the UPF 1300 can be for use in communicating with other nodes, such as other virtual nodes. For example, the communications interface 1302 of the UPF 1300 can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.); and
a processor operably connected to the transceiver, and configured to (Alonso processing circuitry (or logic) 1301 in Fig. 13; [0507] FIG. 13 illustrates a User Plane Function (UPF) 1300 comprising processing circuitry (or logic) 1301. The processing circuitry 1301 controls the operation of the UPF 1300 and can implement the method described herein in relation to a UPF 1300. The processing circuitry 1301 can comprise one or more processors, processing units, multi-core processors or modules that are configured or programmed to control the UPF 1300 in the manner described herein.
[0509] The processing circuitry 1301 of UPF 1300 may be configured to control the communications interface 1302 of the UPF 1300 to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.):
receive, from a network function (NF), a first UPF control message protocol (UCMP) message requesting a service, wherein the first UCMP message is generated by the NF (Alonso Fig. 7B step 703; [0172] In step 703, the NWDAF triggers data collection from UPF, specifically to retrieve information relative to DNS traffic detected by UPF for UE-ID. In order to do this, NWDAF transmits a Nupf_EventExposure_Subscribe request message to the UPF. The Nupf_EventExposure_Subscribe message may comprise one or more of the following parameters: [0173] Event-ID=DNSTraffic [0174] An optional UE-ID or list of UE-IDs, UE-Group-ID or list of UE-Group-IDs, or AnyUE. In this example, this parameter is set to a specific UE-ID. [0175] An optional Tag-ID. This parameter indicates that the traffic is DNS tunneling traffic. It is optional as it is also possible that the Tag-ID value is preconfigured at UPF. Note: NWDAF is the network function. Nupf_EventExposure_Subscribe is the first UCMP message.),
perform the service based on the first UCMP message (Alonso Fig. 7B step 709; [0195] In step 709 the UPF detects the uplink DNS traffic (the DNS query transmitted to the DNS resolver in step 710), which in this case is marked with Tag-ID and gathers data for Event-ID=DNSTraffic. Specifically, UPF stores the following information: [0196] For each detected DNS procedure (DNS query and the corresponding DNS answer): [0197] Tag-ID: this indicates that the traffic is, in this example, DNS tunneling traffic. Different Tag-IDs may be used for different types of tunneling traffic. [0198] Timestamp (DNS query and DNS answer) [0199] Volume (e.g. in bytes) of the DNS query and the DNS answer [0200] 5-tuple (including DNS server IP address) [0201] DNS query type (e.g. A/AAAA) [0202] QNAME in DNS query type A/AAAA [0203] List of Server IP addresses in the DNS answer.),
generate a second UCMP message including a result of the performed service, and transmit, to the NF, the second UCMP message (Alonso Fig. 7B step 722; [0225] In step 721, the UPF continues gathering data for Event-ID=DNSTraffic and at some point (e.g. periodic reporting), UPF reports data for Event-ID=DNSTraffic. In order to do that, UPF notifies NWDAF by transmitting, in step 722, a Nupf_EventExposure_Notify request message. The Nupf_EventExposure_Notify request message may comprise one or more of the following parameters: [0226] Event-ID=DNSTraffic [0227] UE-ID [0228] DNSTrafficInfo. This includes the following information (stored from previous steps): [0229] For each detected DNS procedure (DNS query and the corresponding DNS answer): [0230] Tag-ID: this indicates that the traffic is, in this example, DNS tunneling traffic. Different Tag-IDs may be used for different types of tunneling traffic. [0231] Timestamp (DNS query and DNS answer) [0232] Volume (e.g. in bytes) of the DNS query and the DNS answer [0233] 5-tuple (including DNS server IP address) [0234] DNS query type (e.g. A/AAAA) [0235] QNAME in DNS query type A/AAAA (base64encodeddata.adomain.com) [0236] List of Server IP addresses in the DNS answer. Note: Nupf_EventExposure_Notify is the second UCMP message.).
Although Alonso teaches a service based UPF, wherein each of the first UCMP message
and the second UCMP message is a service based message and includes UCMP data (Alonso [0176] assuming a service based UPF.
[0172] The Nupf_EventExposure_Subscribe message may comprise one or more of the following parameters: [0173] Event-ID=DNSTraffic [0174] An optional UE-ID or list of UE-IDs, UE-Group-ID or list of UE-Group-IDs, or AnyUE.
[0225] The Nupf_EventExposure_Notify request message may comprise one or more of the following parameters: [0226] Event-ID=DNSTraffic [0227] UE-ID [0228] DNSTrafficInfo.), Alonso does not explicitly teach a service based message includes an Internet protocol (IP) header and a service specific header.
TS29500 in the same or similar field of endeavor teaches a service based message includes an Internet protocol (IP) header and a service specific header (TS29500 page 15, Figure 5.1-1: SBI Protocol Stack; As shown in the Fig. 5.1-1, the service based message include a IP header and a HTTP header. Page 20-21, Table 5.2.3.2.1-1: Mandatory HTTP custom headers; a HTTP header includes 3gpp-Sbi-Routing-Binding header. Page 24-25, 5.2.3.2.5 3gpp-Sbi-Routing-Binding; 3gpp-Sbi-Routing-Binding includes the information of a service.).
By modifying Alonso’s teachings of a service based UPF, wherein each of the first UCMP message and the second UCMP message is a service based message and includes UCMP data with TS29500’s teachings of a service based message includes an Internet protocol (IP) header and a service specific header, the modification results in wherein each of the first UCMP message and the second UCMP message includes an Internet protocol (IP) header, a UCMP header, and UCMP data (Note: UCMP header is the UPF service specific header.).
It would have been prima facie obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have modified Alonso with TS29500’s above teachings. The motivation is realization of the 5GC Service Based Architecture (TS29500 Scope). Known work in one field of endeavor (TS29500 prior art) may prompt variations of it for use in either the same field or a different one (Alonso prior art) based on design incentives (realization of the 5GC Service Based Architecture) or other market forces if the variations are predictable to one or ordinary skill in the art.
Although Alonso in view of TS29500 teaches UCMP message includes an Internet protocol (IP) header, a UCMP header, and UCMP data, Alonso in view of TS29500 does not explicitly teach protocol number of IP header indicates encapsulated protocol (i.e. UCMP).
Wiki in the same or similar field of endeavor teaches protocol number of IP header indicates encapsulated protocol (Wiki page 2, This is a list of the IP protocol numbers found in the field Protocol of the IPv4 header. It is an identifier for the encapsulated protocol and determines the layout of the data that immediately follows the header.)
Therefore Alonso in view of TS29500 in combination with Wiki teaches wherein the IP header indicates a UCMP.
It would have been prima facie obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have modified Alonso as modified by TS29500 with wiki’s above teachings. The motivation is supporting encapsulated protocol (wiki page 2). Known work in one field of endeavor (wiki prior art) may prompt variations of it for use in either the same field or a different one (Alonso and TS29500 prior art) based on design incentives (supporting encapsulated protocol) or other market forces if the variations are predictable to one or ordinary skill in the art.
Regarding claim 13, Alonso teaches A network function (NF) in a wireless communication
system, the NF comprising (Alonso NWDAF in Fig. 1; [0129] a User Plane Function, UPF, for providing data relating to tunneling traffic to a first network function, NF. The first NF may comprise an NWDAF.
Fig. 11; [0089] FIG. 11 illustrates a first network function (NF).):
a transceiver (Alonso communications interface 1102 in Fig. 11; [0501] the first NF 1100 may optionally comprise a communications interface 1102. The communications interface 1102 of the first NF 1100 can be for use in communicating with other nodes. the communications interface 1102 of the first NF 1100 can be configured to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.); and
a processor operably connected to the transceiver, and configured to (Alonso processing circuitry (or logic) 1101 in Fig. 11; [0499] FIG. 11 illustrates a first network function (NF) 1100 comprising processing circuitry (or logic) 1101. The processing circuitry 1101 controls the operation of the first NF 1100.
[0501] The processing circuitry 1101 of first NF 1100 may be configured to control the communications interface 1102 of the first NF 1100 to transmit to and/or receive from other nodes requests, resources, information, data, signals, or similar.):
generate a first user plane function (UPF) control message protocol (UCMP) message requesting a service, transmit, to a UPF, the first UCMP message requesting the service (Alonso Fig. 7B step 703; [0172] In step 703, the NWDAF triggers data collection from UPF, specifically to retrieve information relative to DNS traffic detected by UPF for UE-ID. In order to do this, NWDAF transmits a Nupf_EventExposure_Subscribe request message to the UPF. The Nupf_EventExposure_Subscribe message may comprise one or more of the following parameters: [0173] Event-ID=DNSTraffic [0174] An optional UE-ID or list of UE-IDs, UE-Group-ID or list of UE-Group-IDs, or AnyUE. In this example, this parameter is set to a specific UE-ID. [0175] An optional Tag-ID. This parameter indicates that the traffic is DNS tunneling traffic. It is optional as it is also possible that the Tag-ID value is preconfigured at UPF. Note: Nupf_EventExposure_Subscribe is the first UCMP message.), and
receive, from the UPF, a second UCMP message including a performance result of the service (Alonso Fig. 7B step 722; [0225] UPF notifies NWDAF by transmitting, in step 722, a Nupf_EventExposure_Notify request message. The Nupf_EventExposure_Notify request message may comprise one or more of the following parameters: [0226] Event-ID=DNSTraffic [0227] UE-ID [0228] DNSTrafficInfo. This includes the following information (stored from previous steps): [0229] For each detected DNS procedure (DNS query and the corresponding DNS answer): [0230] Tag-ID: this indicates that the traffic is, in this example, DNS tunneling traffic. Different Tag-IDs may be used for different types of tunneling traffic. [0231] Timestamp (DNS query and DNS answer) [0232] Volume (e.g. in bytes) of the DNS query and the DNS answer [0233] 5-tuple (including DNS server IP address) [0234] DNS query type (e.g. A/AAAA) [0235] QNAME in DNS query type A/AAAA (base64encodeddata.adomain.com) [0236] List of Server IP addresses in the DNS answer.),
wherein the service is performed based on the first UCMP message (Alonso Fig. 7B step 709; [0195] In step 709 the UPF detects the uplink DNS traffic (the DNS query transmitted to the DNS resolver in step 710), which in this case is marked with Tag-ID and gathers data for Event-ID=DNSTraffic. Specifically, UPF stores the following information: [0196] For each detected DNS procedure (DNS query and the corresponding DNS answer): [0197] Tag-ID: this indicates that the traffic is, in this example, DNS tunneling traffic. Different Tag-IDs may be used for different types of tunneling traffic. [0198] Timestamp (DNS query and DNS answer) [0199] Volume (e.g. in bytes) of the DNS query and the DNS answer [0200] 5-tuple (including DNS server IP address) [0201] DNS query type (e.g. A/AAAA) [0202] QNAME in DNS query type A/AAAA [0203] List of Server IP addresses in the DNS answer.), and
wherein the second UCMP message is generated by the UPF (Alonso Fig. 7B step 722; [0225] UPF notifies NWDAF by transmitting, in step 722, a Nupf_EventExposure_Notify request message.).
Although Alonso teaches a service based UPF, wherein each of the first UCMP message
and the second UCMP message is a service based message and includes UCMP data (Alonso [0176] assuming a service based UPF.
[0172] The Nupf_EventExposure_Subscribe message may comprise one or more of the following parameters: [0173] Event-ID=DNSTraffic [0174] An optional UE-ID or list of UE-IDs, UE-Group-ID or list of UE-Group-IDs, or AnyUE.
[0225] The Nupf_EventExposure_Notify request message may comprise one or more of the following parameters: [0226] Event-ID=DNSTraffic [0227] UE-ID [0228] DNSTrafficInfo.), Alonso does not explicitly teach a service based message includes an Internet protocol (IP) header and a service specific header.
TS29500 in the same or similar field of endeavor teaches a service based message includes an Internet protocol (IP) header and a service specific header (TS29500 page 15, Figure 5.1-1: SBI Protocol Stack; As shown in the Fig. 5.1-1, the service based message include a IP header and a HTTP header. Page 20-21, Table 5.2.3.2.1-1: Mandatory HTTP custom headers; a HTTP header includes 3gpp-Sbi-Routing-Binding header. Page 24-25, 5.2.3.2.5 3gpp-Sbi-Routing-Binding; 3gpp-Sbi-Routing-Binding includes the information of a service.).
By modifying Alonso’s teachings of a service based UPF, wherein each of the first UCMP message and the second UCMP message is a service based message and includes UCMP data with TS29500’s teachings of a service based message includes an Internet protocol (IP) header and a service specific header, the modification results in wherein each of the first UCMP message and the second UCMP message includes an Internet protocol (IP) header, a UCMP header, and UCMP data (Note: UCMP header is the UPF service specific header.).
It would have been prima facie obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have modified Alonso with TS29500’s above teachings. The motivation is realization of the 5GC Service Based Architecture (TS29500 Scope). Known work in one field of endeavor (TS29500 prior art) may prompt variations of it for use in either the same field or a different one (Alonso prior art) based on design incentives (realization of the 5GC Service Based Architecture) or other market forces if the variations are predictable to one or ordinary skill in the art.
Although Alonso in view of TS29500 teaches UCMP message includes an Internet protocol (IP) header, a UCMP header, and UCMP data, Alonso in view of TS29500 does not explicitly teach protocol number of IP header indicates encapsulated protocol (i.e. UCMP).
Wiki in the same or similar field of endeavor teaches protocol number of IP header indicates encapsulated protocol (Wiki page 2, This is a list of the IP protocol numbers found in the field Protocol of the IPv4 header. It is an identifier for the encapsulated protocol and determines the layout of the data that immediately follows the header.)
Therefore Alonso in view of TS29500 in combination with Wiki teaches wherein the IP header indicates a UCMP.
It would have been prima facie obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have modified Alonso as modified by TS29500 with wiki’s above teachings. The motivation is supporting encapsulated protocol (wiki page 2). Known work in one field of endeavor (wiki prior art) may prompt variations of it for use in either the same field or a different one (Alonso and TS29500 prior art) based on design incentives (supporting encapsulated protocol) or other market forces if the variations are predictable to one or ordinary skill in the art.
Claims 1 and 5 recite similar limitations of claims 9 and 13 respectively, are thus rejected under similar rational.
Claim(s) 3, 7, 11 and 15 is/are rejected under 35 U.S.C. 103 as being unpatentable over Alonso in view of TS29500 and wiki as applied to claims 1, 5, 9 and 13 above, and further in view of “Nupf eventexposure”, S2-1901733 3GPP TSG- SA WG2 Meeting #131 February 25 – March 1, 2019, Santa Cruz, Tenerife, Spain (hereinafter S2).
Regarding claim 3, Alonso in view of TS29500 and wiki (hereinafter combination) teaches The
method of claim 1.
Although the combination teaches the UCMP header is a UPF service specific header and
includes the UPF service information (See rejection of claim 1 above), the combination does not explicitly teach the UPF service includes a service name, a service operation, and an operation semantic.
S2 teaches the UPF service includes a service name, a service operation, and an operation semantic (S2 Table 5.2.8.1-1: NF services provided by the UPF;
Service Name Service Operations Operation Semantics
Nupf_EventExposure Notify Notify ).
By modifying the combination’s teachings of the UCMP header is a UPF service specific header and includes the UPF service information with S2’s teachings of the UPF service includes a service name, a service operation, and an operation semantic, the modification results in wherein the UCMP header includes a service name, a service operation, and an operation semantic.
It would have been prima facie obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have modified the combination with S2’s above teachings. The motivation is supporting UPF event exposure service (S2 page 1). Known work in one field of endeavor (S2 prior art) may prompt variations of it for use in either the same field or a different one (Alonso, TS29500 and wiki prior art) based on design incentives (supporting UPF event exposure service) or other market forces if the variations are predictable to one or ordinary skill in the art.
Claims 7, 11 and 15 recite similar limitations of claim 3 respectively, are thus rejected under similar rational.
Claim(s) 4, 8, 12 and 16 is/are rejected under 35 U.S.C. 103 as being unpatentable over Alonso in view of TS29500 and wiki as applied to claims 1, 5, 9 and 13 above, and further in view of WO 2021194163 A1 (US 20230143200 A1 is used as English translation of WO 2021194163 A1) (hereinafter Kweon).
Regarding claim 4, the combination teaches The method of claim 1.
Alonso teaches wherein UCMP data includes at least one of: an event identifier (ID)
(Alonso [0172] The Nupf_EventExposure_Subscribe message may comprise one or more of the following parameters: [0173] Event-ID=DNSTraffic [0174] An optional UE-ID or list of UE-IDs, UE-Group-ID or list of UE-Group-IDs, or AnyUE.
[0225] The Nupf_EventExposure_Notify request message may comprise one or more of the following parameters: [0226] Event-ID=DNSTraffic [0227] UE-ID [0228] DNSTrafficInfo.).
Alonso does not explicitly teach wherein UCMP data includes a terminal IP address, a generic public subscription identifier (GPSI), a data network name (DNN), or single network slice selection assistance information (S-NSSAI).
Kweon in the same or similar field of endeavor teaches wherein UCMP data includes a terminal
IP address, a generic public subscription identifier (GPSI), a data network name (DNN), or single network slice selection assistance information (S-NSSAI) (Kweon [0065] The subscription request message may include at least one of the following parameters. [0066] Event ID(s)
[0068] Target of Event Reporting
[0069] It may be any combination of a generic public subscription identifier (GPSI)
UE IP address (IPv4 address or IPv6 prefix)
data network name (DNN)/S-NSSAI (network slice selection assistance information) combination information. [0123] a service subscription request (Nupf_EventExposure_Subscribe).).
It would have been prima facie obvious to one of ordinary skill in the art before the effective
filing date of the claimed invention to have modified the combination with Kweon’s above teachings. The motivation is effectively providing a service in a wireless communication system (Kweon [0026]). Known work in one field of endeavor (Kweon prior art) may prompt variations of it for use in either the same field or a different one (Alonso, TS29500 and wiki prior art) based on design incentives (effectively providing a service in a wireless communication system) or other market forces if the variations are predictable to one or ordinary skill in the art.
Claims 8, 12 and 16 recite similar limitations of claim 3 respectively, are thus rejected under similar rational.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to David Z Sun whose telephone number is (571)270-0750. The examiner can normally be reached Monday-Friday 0800am-0500pm.
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, Moo Jeong can be reached at 571-272-9617. 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.
/D.Z.S./Examiner, Art Unit 2418 /Moo Jeong/Supervisory Patent Examiner, Art Unit 2418