DETAILED ACTION
1. The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
2. This communication is in response to the Continuation Application filed on March 26, 2025, in which claims 1-20 have been presented for examination.
Status of Claims
3. Claims 1-20 are pending, all of which are rejected under 35 U.S.C. 103.
Priority
4. Examiner has acknowledged Applicant’s claim for the benefit of prior-filed International Application No. PCT/CN2023/119350, filed September 18, 2023.
5. Acknowledgment is also 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. Should applicant desire to obtain the benefit of foreign priority under 35 U.S.C. 119(a)-(d) prior to declaration of an interference, a certified English translation of the foreign application must be submitted in reply to this action. 37 CFR 41.154(b) and 41.202(e). Failure to provide a certified translation may result in no benefit being accorded for the non-English application.
Information Disclosure Statement
6. The information disclosure statements, filed on April 24, 2025, and December 2, 2025, are in compliance with the provisions of 37 CFR 1.97, 1.98 and MPEP § 609. They have been placed in the application file, and the information referred to therein has been considered as to the merits.
Specification
7. The disclosure is objected to because of the following informalities: With reference to FIG. 9, paragraph [0261] of instant Specification recites, “After receiving the address information and/or the port information of the SEALDD server, the SEALDD client may use the address information and/or the port information of the SEALDD server to send data (for example, media data) to the SEALDD server. If the SMF or the UPF detects that the SEALDD client sends data to the SEALDD server, the SMF may provide the first information for the UPF, so that the UPF provides second information, as shown in steps 910 and 920”. However, FIG. 9 fails to illustrate a reference character labeled as “step 920”. As such, it appears as though paragraph [0261] should be corrected to recite, ‘the SMF may provide the first information for the UPF, so that the UPF provides second information, as shown in steps 910 and 911,’ to address a minor typographical error and improve clarity. Appropriate correction is required.
Claim Rejections - 35 USC § 103
8. 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.
9. 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.
10. 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.
11. Claims 1-4, 9 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over LY et al. (United States Patent Application Publication No. US 2026/0052419 A1), hereinafter “LY” in view of LI et al. (United States Patent Application Publication No. US 2018/0192471 A1), hereinafter “LI”.
Regarding claim 1, LY discloses a communication method, comprising: receiving, by a service enabler architecture layer data delivery (SEALDD) server (wherein with reference to FIG. 6, LY discloses that a user equipment (UE) 601 is equipped with a Vertical Application Layer (VAL) client 610, as well as a Service Enabler Architecture Layer Data Delivery (SEALDD) client 611. FIG. 6 also illustrates a SEALDD server 612, which receives application traffic, as SEALDD data traffic 630) (LY, FIG. 6, paragraph [0058]), service request information from a terminal device (wherein more particularly, the VAL client 610 on UE 601 may request SEALDD services from the SEALDD client 611 over a SEALDD-C interface 620. The SEALDD client 611 may in turn route application traffic to a SEALDD server 612 over SEALDD-UU interface 621 (See FIG. 6), which may span over multiple network nodes. LY discloses that upon receiving the SEALDD data traffic 630, the SEALDD server 612 may forward the SEAL data traffic 630, as application data traffic 631, to a corresponding VAL server 613) (LY, FIG. 6, paragraph [0058]), wherein the service request information requests the SEALDD server to provide a service related to data transmission (again, requesting SEALDD services regarding application traffic/data delivery services. That is, the SEALDD clients and SEALDD servers together providing data delivery services over a SEAL-UU interface (513 in FIG. 5, 621 in FIG. 6), for transferring application traffic from the VAL layer) (LY, FIGS. 5 and 6, paragraphs [0057] and [0058]); and in response to the service request information, communicating, by the SEALDD server, data of the terminal device with a user plane network element through an N6 tunnel (wherein more particularly, and with further reference to FIG. 10, LY teaches that a VAL client 1010 on UE 1001, may make a request for a SEALDD data delivery service and may provide information about the application with the desired QoS requirements. The request may include an application identifier, the desired QoS, whether and what data transmission measurements to enable, data transmission measurement configuration information, and a list of one or more action guarantees with corresponding triggering events (See FIG. 10, step 1022). The SEALDD client 1011 may make a determination on which SEALDD server is best to provide the SEALDD data delivery service based on the information provided by the VAL client 1010 (See FIG. 10, step 1023). The SEALDD client 1011 may then establish a SEALDD connection with the selected SEALDD server 1003 and may provide information to configure and enable data transmission measurement for the SEALDD connection (See FIG. 10, step 1024). Examples of the information that can be provided for data transmission measurements are listed in Table 1. After the SEALDD client 1011 and SEALDD 1003 server establish a connection, LY teaches that at step 1027, the SEALDD server 1003 may subscribe to receive notifications from the 5G network or OAM management nodes 1002 to obtain network measurements and/or analytics. For example, the SEALDD server 1003 may subscribe to get user plane measurements from a Session Management Function (SMF) or from a User Plane Function (UPF). Referring back to FIG. 5, LY further teaches that the SEALDD server 512 (See again, FIG. 5) may have access to exposure information available from the 3GPP network (i.e., the core network) through the N33/N5 514 and N6 515 interfaces. Examiner notes that while not illustrated in FIG. 10, nonetheless, communication through the N6 interface is nonetheless inherently implied, as the SEALDD server 1003 would access the SMF and/or UPF in the core network (i.e., the 5GC/OAM 1002), via the N6 interface, as readily understood by those of ordinary skill in the art) (LY, FIGS. 5 and 10, paragraphs [0057], [0098]-[0100] and [0104]), wherein the N6 tunnel is established based on first information and second information (again, communicating with the UPF via the N6 interface, based the subscription(s) (first information) from the SEALDD server 1003, as well as receiving the subscribed-to network measurements and/or analytics (second information). Examiner notes that the claim is silent as to what the recited “first” and “second” information is, much less how the “first” and “second” information are used, if at all, in establishing the N6 tunnel) (LY, paragraph [0104]), the first information comprises information provided by the SEALDD server for establishing the N6 tunnel (again, the subscription from the SEALDD server. Again, Examiner notes that the claim is silent as to exactly what the recited “information” is, and Examiner interprets “establishing the N6 tunnel” as merely communicating with the UPF in the 5G system, as the 5G system (and UPF thereof) is accessed via the N6 interface regardless, as readily understood by those of ordinary skill in the art) (LY, paragraph [0104]). LY does not explicitly disclose that the second information comprises information provided by the user plane network element for establishing the N6 tunnel. However in an analogous art, LI discloses second information that comprises information provided by a user plane network element for establishing an N6 tunnel (wherein LI discloses basic Application Functions (AFs) in a data network (DN) that may request to receive notifications about events related to PDU sessions. LI teaches that the requests from the AFs may include information to identify the traffic to be routed, including information about the N6 traffic routing requirements for the identified traffic. LI notes that N6 refers to the interface between a UPF and a DN external to the CN. LI teaches that the information about the traffic routing requirements may be provided in the form of a list of routing profile ID(s) that each corresponds to a single host location of the application in the local DN, when applications are instantiated statically (i.e. the routing profile IDs each correspond to a DNAI). When the DNAI(s) where applications are instantiated may vary dynamically then, this may be provided in the form of a list of DNAIs and associated N6 routing information. Based on the information about the N6 traffic routing requirements, which in some embodiments may comprise the routing profile IDs, LI teaches that the PCF determines a list of traffic steering profiles ID(s) that each corresponds to a steering behaviour which is preconfigured on the SMF or UPF. The PCF transmits the traffic steering policy ID(s) to the SMF. The traffic steering policy ID(s) are related to the mechanism enabling traffic steering to the DN. If the AF interacts with the PCF via the NEF, it may indicate at least one of the DNN and the host location(s), in the form of address(es) or name(s), of the application, and the NEF may map the information to routing profile ID(s). In an embodiment, the SMF is operative to receive the traffic steering policy ID(s) and to determine which of the traffic steering policy ID(s), and the corresponding traffic steering behaviors, should be applied. The SMF passes the selected traffic steering policy ID(s) to the UPF. In an embodiment, the UPF is operative to identify corresponding traffic steering parameters that are pre-configured and are associated with the selected traffic steering policy ID(s). The UPF is further operative to apply the corresponding traffic steering parameters when handling data traffic. LI teaches that the N6 traffic routing requirements are related to the mechanism enabling traffic steering in the local access to the DN, and that they are expected to correspond to local rules configured in the UPFs in order to support traffic steering. The routing profile IDs may refer to a pre-agreed policy between the AF and the 5GC, or in an alternate embodiment they may simply refer to a predefined routing requirement. This policy may refer to different steering policy ID(s) sent to the SMF. In some implementations, the policies may be based on other conditions, such as temporal conditions (e.g. based on time of the day, etc.)) (LI, paragraphs [0104], [0107], [0113] and [0114]). LY is analogous art because LY is from the same field of endeavor, namely, management of data transmission measurements and data delivery services for SEALDD servers and clients (See LY, paragraph [0004]), while LI is analogous art because LI is reasonably pertinent to the particular problem with which the inventor was concerned, as LI is generally directed to Protocol Data Unit (PDU) session management in communication networking and Network Management systems, and in particular, to systems and methods for PDU session management that enable application awareness and application-friendly Protocol Data Unit (PDU) session management (See LI, paragraph [0002]). Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of LY and LI before him or her, to modify the SEALDD architecture of LY to include the additional limitation of second information that comprises information provided by a user plane network element for establishing an N6 tunnel, as disclosed in LI, with reasonable expectation that this would result in a SEALDD architecture having the added benefit of enabling traffic steering in the local access to the data network (DN), or the network where the SEALDD server resides (See LI, paragraph [0114]). This method of improving the SEALDD architecture of LY was well within the ordinary ability of one of ordinary skill in the art based on the teachings of LI. Therefore, it would have been obvious to one having ordinary skill in the art to combine the teachings of LY with LI to obtain the invention as specified in claim 1.
Regarding claim 2, LY-LI discloses the method according to claim 1, wherein the method further comprises: sending, by the SEALDD server, the first information to the user plane network element to trigger the user plane network element to establish the N6 tunnel (again, subscribing to receive notifications for obtaining network measurements and analytics) (LY, paragraph [0104]); and transmit the data of the terminal device to the SEALDD server through the N6 tunnel (again, the UPF sending user plane measurements to the SEALDD server 1003, and the SEALDD server 1003 together with the SEALDD client 1011 collecting and processing data for reporting data transmission measurements) (LY, paragraphs [0104] and [0105]). The motivation regarding the obviousness of claim 1 is also applied to claim 2.
Regarding claim 3, LY-LI discloses the method according to claim 2, wherein the sending, by the SEALDD server, the first information to the user plane network element comprises: sending, by the SEALDD server, the first information to the user plane network element in response to the SEALDD server determining, based on the service request information, to communicate the data of the terminal device on the N6 tunnel (wherein as above, the SEALDD server sends measurement subscriptions to UPF for measurements, whereby the measurements may be used by the SEALDD server 1003 to assist in determining where network congestion may be when SEALDD data delivery service is not providing the appropriate QoS. Again, this happens at step 1027 of FIG. 10, which occurs after the request for SEALDD data delivery service, at steps 1022, 1023 and 1024) (LY, FIG. 10, paragraph [0104]). The motivation regarding the obviousness of claim 1 is also applied to claim 3.
Regarding claim 4, LY-LI discloses the method according to claim 1, wherein the method further comprises: sending, by the SEALDD server to the terminal device, at least one of: address information of the SEALDD server (wherein at step 1029 (See again, FIG. 10) at the configured measurement reporting intervals, the SEALDD client 1011 and the SEALDD server 1003 may submit DTM reports containing the data transmission measurements that have been enabled and other information as shown in Table 2. Again, the DTM reports are relayed from the VAL server, to the SEALDD server, to the SEALDD client on the UE, which relays the report to the VAL client on the UE. As shown in Table 2, the DTM report information may include the source of the measurement, which can be from the SEALDD layer (e.g. a SEALDD client or server) and will specify IP address and/or MAC address) (LY, FIG. 10, Table 2, paragraph [0106]), or port information of the SEALDD server (also specifying port number) (LY, Table 2). The motivation regarding the obviousness of claim 1 is also applied to claim 4.
Regarding claim 9, LY discloses a communication method, comprising: receiving, by a user plane network element, first information from a service enabler architecture layer data delivery (SEALDD) server (wherein as discussed and shown above, the SEALDD server may send measurement subscriptions to UPF) (LY, FIG. 10, paragraph [0104]); and in response to the first information, establishing, by the user plane network element, an N6 tunnel (again, as readily known and appreciated by those of ordinary skill in the art, the data network (DN) connects to the 5GC via the UPF and an N6 interface. As well, again, LY illustrates the SEALDD server 512 of FIG. 5 connecting to the 5G network/UPF via the N6 interface to receive data traffic measurements (DTM reports) therefrom) (LY, FIG. 5, paragraph [0057]), wherein the N6 tunnel is established based on the first information (again, based on the subscriptions (i.e., as first information)) (LY, paragraph [0104]) and second information (again, as well as receiving the subscribed-to network measurements and/or analytics (second information). Examiner again points out that that the claim is silent as to what the recited “first” and “second” information is, much less how the “first” and “second” information are used, if at all, in establishing the N6 tunnel) (LY, paragraph [0104]), the first information comprises information provided by the SEALDD server for establishing the N6 tunnel (again, the measurement subscriptions) (LY, paragraph [0104]), and communicating, by the user plane network element, data of a terminal device with the SEALDD server through the N6 tunnel (wherein as above, with particular further reference to FIG. 10, LY teaches that a VAL client 1010 on UE 1001, may make a request for a SEALDD data delivery service and may provide information about the application with the desired QoS requirements. The request may include an application identifier, the desired QoS, whether and what data transmission measurements to enable, data transmission measurement configuration information, and a list of one or more action guarantees with corresponding triggering events (See FIG. 10, step 1022). The SEALDD client 1011 may make a determination on which SEALDD server is best to provide the SEALDD data delivery service based on the information provided by the VAL client 1010 (See FIG. 10, step 1023). The SEALDD client 1011 may then establish a SEALDD connection with the selected SEALDD server 1003 and may provide information to configure and enable data transmission measurement for the SEALDD connection (See FIG. 10, step 1024). Examples of the information that can be provided for data transmission measurements are listed in Table 1. After the SEALDD client 1011 and SEALDD 1003 server establish a connection, LY teaches that at step 1027, the SEALDD server 1003 may subscribe to receive notifications from the 5G network or OAM management nodes 1002 to obtain network measurements and/or analytics. For example, the SEALDD server 1003 may subscribe to get user plane measurements from a Session Management Function (SMF) or from a User Plane Function (UPF). Referring back to FIG. 5, LY further teaches that the SEALDD server 512 (See again, FIG. 5) may have access to exposure information available from the 3GPP network (i.e., the core network) through the N33/N5 514 and N6 515 interfaces. Examiner notes that while not illustrated in FIG. 10, nonetheless, communication through the N6 interface is nonetheless inherently implied, as the SEALDD server 1003 would access the SMF and/or UPF in the core network (i.e., the 5GC/OAM 1002), via the N6 interface, as readily understood by those of ordinary skill in the art) (LY, FIGS. 5 and 10, paragraphs [0057], [0098]-[0100] and [0104]). LY does not explicitly disclose, but LI discloses the second information comprises information provided by the user plane network element for establishing the N6 tunnel (wherein LI discloses basic Application Functions (AFs) in a data network (DN) that may request to receive notifications about events related to PDU sessions. LI teaches that the requests from the AFs may include information to identify the traffic to be routed, including information about the N6 traffic routing requirements for the identified traffic. LI notes that N6 refers to the interface between a UPF and a DN external to the CN. LI teaches that the information about the traffic routing requirements may be provided in the form of a list of routing profile ID(s) that each corresponds to a single host location of the application in the local DN, when applications are instantiated statically (i.e. the routing profile IDs each correspond to a DNAI). When the DNAI(s) where applications are instantiated may vary dynamically then, this may be provided in the form of a list of DNAIs and associated N6 routing information. Based on the information about the N6 traffic routing requirements, which in some embodiments may comprise the routing profile IDs, LI teaches that the PCF determines a list of traffic steering profiles ID(s) that each corresponds to a steering behaviour which is preconfigured on the SMF or UPF. The PCF transmits the traffic steering policy ID(s) to the SMF. The traffic steering policy ID(s) are related to the mechanism enabling traffic steering to the DN. If the AF interacts with the PCF via the NEF, it may indicate at least one of the DNN and the host location(s), in the form of address(es) or name(s), of the application, and the NEF may map the information to routing profile ID(s). In an embodiment, the SMF is operative to receive the traffic steering policy ID(s) and to determine which of the traffic steering policy ID(s), and the corresponding traffic steering behaviors, should be applied. The SMF passes the selected traffic steering policy ID(s) to the UPF. In an embodiment, the UPF is operative to identify corresponding traffic steering parameters that are pre-configured and are associated with the selected traffic steering policy ID(s). The UPF is further operative to apply the corresponding traffic steering parameters when handling data traffic. LI teaches that the N6 traffic routing requirements are related to the mechanism enabling traffic steering in the local access to the DN, and that they are expected to correspond to local rules configured in the UPFs in order to support traffic steering. The routing profile IDs may refer to a pre-agreed policy between the AF and the 5GC, or in an alternate embodiment they may simply refer to a predefined routing requirement. This policy may refer to different steering policy ID(s) sent to the SMF. In some implementations, the policies may be based on other conditions, such as temporal conditions (e.g. based on time of the day, etc.)) (LI, paragraphs [0104], [0107], [0113] and [0114]). LY is analogous art because LY is from the same field of endeavor, namely, management of data transmission measurements and data delivery services for SEALDD servers and clients (See LY, paragraph [0004]), while LI is analogous art because LI is reasonably pertinent to the particular problem with which the inventor was concerned, as LI is generally directed to Protocol Data Unit (PDU) session management in communication networking and Network Management systems, and in particular, to systems and methods for PDU session management that enable application awareness and application-friendly Protocol Data Unit (PDU) session management (See LI, paragraph [0002]). Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of LY and LI before him or her, to modify the SEALDD architecture of LY to include the additional limitation of the second information comprises information provided by the user plane network element for establishing the N6 tunnel, as disclosed in LI, with reasonable expectation that this would result in a SEALDD architecture having the added benefit of enabling traffic steering in the local access to the data network (DN), or the network where the SEALDD server resides (See LI, paragraph [0114]). This method of improving the SEALDD architecture of LY was well within the ordinary ability of one of ordinary skill in the art based on the teachings of LI. Therefore, it would have been obvious to one having ordinary skill in the art to combine the teachings of LY with LI to obtain the invention as specified in claim 9.
Regarding claim 14, LY-LI discloses the method according to claim 1, wherein the second information comprises at least one of: address information of the user plane network element, port information of the user plane network element, or a tunnel endpoint identifier of the N6 tunnel on a user plane network element side (again, information about the N6 traffic routing requirements for traffic are provided in the form of a list of routing profile ID(s) that each corresponds to a single host location of the application in the local DN, when such applications are instantiated statically (i.e. the routing profile IDs each correspond to a DNAI), and alternatively provided in the form of a list of DNAIs and associated N6 routing information, when instantiated dynamically. Again, the N6 interface refers to the interface between the UPF and a DN external to the CN) (LI, paragraph [0113]). LY is analogous art because LY is from the same field of endeavor, namely, management of data transmission measurements and data delivery services for SEALDD servers and clients (See LY, paragraph [0004]), while LI is analogous art because LI is reasonably pertinent to the particular problem with which the inventor was concerned, as LI is generally directed to Protocol Data Unit (PDU) session management in communication networking and Network Management systems, and in particular, to systems and methods for PDU session management that enable application awareness and application-friendly Protocol Data Unit (PDU) session management (See LI, paragraph [0002]). Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of LY and LI before him or her, to modify the SEALDD architecture of LY to include the additional limitation of wherein the second information comprises at least one of: address information of the user plane network element, port information of the user plane network element, or a tunnel endpoint identifier of the N6 tunnel on a user plane network element side, as disclosed in LI, with reasonable expectation that this would result in a SEALDD architecture having the added benefit of enabling the PCF to determines a list of traffic steering profile ID(s) that each corresponds to a steering behaviour which is preconfigured on the UPF (See LI, paragraph [0113]). This method of improving the SEALDD architecture of LY was well within the ordinary ability of one of ordinary skill in the art based on the teachings of LI. Therefore, it would have been obvious to one having ordinary skill in the art to combine the teachings of LY with LI to obtain the invention as specified in claim 14.
12. Claims 5-8, 10-13 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over LY-LI, and further in view of Pateromichelakis et al. (United States Patent Application Publication No. US 2025/0024284 A1), hereinafter “Pateromichelakis 1”.
Regarding claim 5, LY-LI discloses the method according to claim 1, wherein the communicating, by the SEALDD server, the data of the terminal device with the user plane network element through the N6 tunnel comprises: receiving, by the SEALDD server, a first data packet from an application server (again, SEALDD server 1003 (See again, FIG. 10) receiving the data transmission measurement reports from the VAL server 1004, as part of application data traffic transfer at step 1028) (LY, FIG. 10, paragraph [0105]); and sending, by the SEALDD server, the first data packet to the user plane network element through the N6 tunnel (again, traffic traversing the 5GC 1002 (See again, FIG. 10) via the UPF and N6 interface (See again, FIG. 5)) (LY, FIGS. 5 and 10, paragraph [0057]) based on at least one of address information or port information of the first data packet (wherein the UE IP address and port number of redundant PDU sessions, or information to manually manage redundant transport at the SEALDD layer, are sent from the SEALDD client 1411 to SEALDD server 1403 (shown in FIG. 14, for requesting use of redundant transport)) (LY, FIG. 14, paragraph [0150]). LY-LI does not expressly disclose, a mapping relationship, wherein the mapping relationship indicates a relationship among the SEALDD server, the application server, the terminal device, and the N6 tunnel. However in an analogous art, Pateromichelakis 1 discloses a mapping relationship, wherein the mapping relationship indicates a relationship among a SEALDD server, an application server, a terminal device, and an N6 tunnel (wherein with reference to FIG. 10, Pateromichelakis 1 teaches that a Global Application Data Collection Coordination Function (G-ADCCF 1026), which is disclosed as implemented as a SEALDD server in paragraph [0128] as well as in FIG.8, initially receives a subscription request for data collection from a service consumer 1030 (e.g., ADAES, VAL server) which can be for a specific event identity and/or type (e.g. VAL performance data). At the same time as or subsequent to the subscription request, the service consumer 1030 may also configure the data collection required (e.g. which sources and what granularity of data, including a definition of the abstraction required). Based on the subscription, the ADCCF/service consumer 1030 checks whether offline data about the VAL server 1024 data network performance exist and are accessible. Such offline data may be available from an ADRF. Then, the ADCCF/service consumer 1030 also requests and receives data from the configured data sources (edge platform load data, 5GC monitoring data, SEAL data, PM/FM data from OAM). Pateromichelakis 1 teaches that when a relevant session starts, which is a session between the VAL server 1024 (i.e., application server) and VAL UE 1010 (i.e., terminal) via 5GS (i.e., having UPF and N6 interface - See FIGS. 8 and 10) and identified by the event identity, then the G-ADCCF 1026 (i.e., the SEALDD server) may also collect data from the networking stack 1022 (TCP/QUIC/UDP/IP) related to the performance of the end-to-end session. The ADCCF 1030 may abstract and/or correlate the data from real-time measurement from the networking stack with the data received before the session and will provide this data to the service consumer 1030 in the format requested by the service consumer 1030. The requested data may be provided periodically or based on the occurrence of an event identified by the event identity, such as a performance lower than a threshold, or based on the consumer request. For example, the provided data can be an indication of an RT deviation, a VAL server 1024 load at the target service area where the session is ongoing, a network status at the target area, or an active UE connection density. At 1060 (See again, FIG. 10), the ADCCF/service consumer 1030 (which Pateromichelakis 1 teaches can be an analytics enabler server, or a VAL server 1024, or an edge application server) subscribes to G-ADCCF 1026 (i.e., the SEALDD server) with a data request that indicates a real-time performance data for VAL server 1024 (using a unique event identifier). The request includes the event identifier, the area of interest for which performance data is required and time of interest for which performance data is required as well as the identity of the application server or interest for which performance data is required) (Pateromichelakis 1, FIGS. 8 and 10, paragraphs [0128], [0167] and [0169]). LY-LI and Pateromichelakis 1 are analogous art because they are from the same field of endeavor, namely, management of data transmission measurements and data delivery services for SEALDD servers and clients. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of LY-LI and Pateromichelakis 1 before him or her, to modify the SEALDD architecture of LY-LI to include the additional limitation of a mapping relationship, wherein the mapping relationship indicates a relationship among a SEALDD server, an application server, a terminal device, and an N6 tunnel, as disclosed in Pateromichelakis 1, with reasonable expectation that this would result in a SEALDD architecture having the added benefit of determining where to direct the requests, using the mapping of the event identifier (See Pateromichelakis 1, paragraph [0172]). This method of improving the SEALDD architecture of LY-LI was well within the ordinary ability of one of ordinary skill in the art based on the teachings of Pateromichelakis 1. Therefore, it would have been obvious to one having ordinary skill in the art to combine the teachings of LY-LI with Pateromichelakis 1 to obtain the invention as specified in claim 5.
As to claim 6, LY-LI-Pateromichelakis 1 discloses the method according to claim 5, wherein the first data packet comprises feature information of the first data packet (wherein the SEALDD server 512 (shown in FIG. 5) may further access performance statistics from a Network Data Analytics Function (NWDAF) through a Network Exposure Function (NEF)) (LY, FIG. 5, paragraph [0057]). The motivation regarding the obviousness of claim 5 is also applied to claim 6.
Regarding claim 7, LY-LI-Pateromichelakis 1 discloses the method according to claim 1, wherein the communicating, by the SEALDD server, the data of the terminal device with the user plane network element through an N6 tunnel comprises: receiving, by the SEALDD server, a second data packet from the user plane network element through the N6 tunnel (again, application data transfer, i.e., multiple reports, traversing through the 5GC network 1002 (shown at step 1028 of FIG. 10), and again, traffic traverses the 5GC 1002 (See again, FIG. 10) via the UPF and N6 interface (See again, FIG. 5)) (LY, FIGS. 5 and 10, paragraphs [0057] and [0105]); and sending, by the SEALDD server, the second data packet to an application server (again, to VAL server 1004) (LY, FIG. 10) based on at least one of address information or port information of the second data packet (wherein again, the UE IP address and port number of redundant PDU sessions, or information to manually manage redundant transport at the SEALDD layer, are sent from the SEALDD client 1411 to SEALDD server 1403 (shown in FIG. 14, for requesting use of redundant transport)) (LY, FIG. 14, paragraph [0150]), the N6 tunnel (again, impliedly, as N6 is reaching the UPF of the 5GC from the DN) (LY, FIG. 5, paragraph [0057]), and a mapping relationship, wherein the mapping relationship indicates a relationship among the SEALDD server, the application server, the terminal device, and the N6 tunnel (wherein with reference to FIG. 10, Pateromichelakis 1 teaches that a Global Application Data Collection Coordination Function (G-ADCCF 1026), which is disclosed as implemented as a SEALDD server in paragraph [0128] as well as in FIG.8, initially receives a subscription request for data collection from a service consumer 1030 (e.g., ADAES, VAL server) which can be for a specific event identity and/or type (e.g. VAL performance data). At the same time as or subsequent to the subscription request, the service consumer 1030 may also configure the data collection required (e.g. which sources and what granularity of data, including a definition of the abstraction required). Based on the subscription, the ADCCF/service consumer 1030 checks whether offline data about the VAL server 1024 data network performance exist and are accessible. Such offline data may be available from an ADRF. Then, the ADCCF/service consumer 1030 also requests and receives data from the configured data sources (edge platform load data, 5GC monitoring data, SEAL data, PM/FM data from OAM). Pateromichelakis 1 teaches that when a relevant session starts, which is a session between the VAL server 1024 (i.e., application server) and VAL UE 1010 (i.e., terminal) via 5GS (i.e., having UPF and N6 interface - See FIGS. 8 and 10) and identified by the event identity, then the G-ADCCF 1026 (i.e., the SEALDD server) may also collect data from the networking stack 1022 (TCP/QUIC/UDP/IP) related to the performance of the end-to-end session. The ADCCF 1030 may abstract and/or correlate the data from real-time measurement from the networking stack with the data received before the session and will provide this data to the service consumer 1030 in the format requested by the service consumer 1030. The requested data may be provided periodically or based on the occurrence of an event identified by the event identity, such as a performance lower than a threshold, or based on the consumer request. For example, the provided data can be an indication of an RT deviation, a VAL server 1024 load at the target service area where the session is ongoing, a network status at the target area, or an active UE connection density. At 1060 (See again, FIG. 10), the ADCCF/service consumer 1030 (which Pateromichelakis 1 teaches can be an analytics enabler server, or a VAL server 1024, or an edge application server) subscribes to G-ADCCF 1026 (i.e., the SEALDD server) with a data request that indicates a real-time performance data for VAL server 1024 (using a unique event identifier). The request includes the event identifier, the area of interest for which performance data is required and time of interest for which performance data is required as well as the identity of the application server or interest for which performance data is required) (Pateromichelakis 1, FIGS. 8 and 10, paragraphs [0128], [0167] and [0169]). LY-LI and Pateromichelakis 1 are analogous art because they are from the same field of endeavor, namely, management of data transmission measurements and data delivery services for SEALDD servers and clients. Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of LY-LI and Pateromichelakis 1 before him or her, to modify the SEALDD architecture of LY-LI to include the additional limitation of a mapping relationship, wherein the mapping relationship indicates a relationship among the SEALDD server, the application server, the terminal device, and the N6 tunnel, as disclosed in Pateromichelakis 1, with reasonable expectation that this would result in a SEALDD architecture having the added benefit of determining where to direct the requests, using the mapping of the event identifier (See Pateromichelakis 1, paragraph [0172]). This method of improving the SEALDD architecture of LY-LI was well within the ordinary ability of one of ordinary skill in the art based on the teachings of Pateromichelakis 1. Therefore, it would have been obvious to one having ordinary skill in the art to combine the teachings of LY-LI with Pateromichelakis 1 to obtain the invention as specified in claim 7.
Regarding claim 8, LY-LI-Pateromichelakis 1 discloses the method according to claim 7, wherein the second data packet comprises feature information of the second data packet (wherein the SEALDD server 512 (shown in FIG. 5) may further access performance statistics from a Network Data Analytics Function (NWDAF) through a Network Exposure Function (NEF)) (LY, FIG. 5, paragraph [0057]). The motivation regarding the obviousness of claim 5 is also applied to claim 8.
Claims 10-12 include method claims that perform limitations substantially as recited in method claims 5-7, respectively, and do not appear to contain any additional features with regard to novelty and/or nonobviousness; therefore, they are rejected under the same rationale.
Regarding claim 13, LY-LI-Pateromichelakis 1 discloses the method according to claim 1, wherein the first information comprises at least one of: information about the terminal device, routing information of the N6 tunnel, address information of the SEALDD server (wherein a subscription request may include a VAL client/server 1201 identifier, a SEALDD connection identifier, one or more data transmission measurement identifiers, and the conditions for which to received notifications) (LY, paragraph [0124]), port information of the SEALDD server, or a tunnel endpoint identifier of the N6 tunnel on an SEALDD server side. The motivation regarding the obviousness of claim 5 is also applied to claim 13.
Regarding claim 15, LY-LI-Pateromichelakis 1 discloses the method according to claim 1, wherein the first information comprises information provided by the SEALDD server for establishing at least two N6 tunnels (see also FIG. 11, illustrating an example SEALDD data transmission measurement procedure 1100, having two separate measurement periods) (LY, FIG. 11), the at least two N6 tunnels are N6 tunnels between the SEALDD server and the user plane network element (see again, FIGS. 5 and 10, each illustrating a SEAL client 1011 of a UE (e.g., such as SEAL client 1101) and a SEAL server 1003 (e.g., such as SEAL server 1102) separated by 5GC 1002, and 3GPP system via an N6 interface, respectively) (LY, FIGS. 5 and 10, paragraphs [0057] and [0100]), and the at least two N6 tunnels are usable to transmit different types of data of the terminal device (again, the different types of measurements, e.g., time-based measurements such as round-trip time and packet rate loss, as well as throughput and jitter) (LY, FIG. 11, paragraphs [0111] and [0113]). The motivation regarding the obviousness of claim 5 is also applied to claim 15.
13. Claims 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over LI in view of Pateromichelakis et al. (United States Patent Application Publication No. US 2023/0284078 A1), hereinafter “Pateromichelakis 2”.
Regarding claim 16, LI discloses a communication method, comprising: determining, by a session management network element, second information (wherein a Policy Control Function (PCF) determines a list of traffic steering profile ID(s) (e.g., second information) that each corresponds to a steering behaviour which is preconfigured on a Session Management Function (SMF) or a User Plane Function (UPF). The PCF transmits the traffic steering policy ID(s) to the SMF, and the traffic steering policy ID(s) are related to the mechanism enabling traffic steering to the Data Network (DN). If the Application Function (AF) interacts with the PCF via the Network Exposure Function (NEF), it may indicate at least one of the Data Network Name (DNN) and the host location(s), in the form of address(es) or name(s), of the application, and the NEF may map the information to routing profile ID(s). In an embodiment, the SMF is operative to receive the traffic steering policy ID(s) from the PCF and to determine which of the traffic steering policy ID(s), and the corresponding traffic steering behaviors, should be applied. The SMF then passes the selected traffic steering policy ID(s) to the UPF) (LI, paragraph [0113]), wherein the second information comprises information provided by a user plane network element for establishing an N6 tunnel (wherein again, the selected traffic steering policy ID(s) are passed to the UPF. LI teaches that that N6 interface refers to the interface between a UPF and a DN external to the CN, and that this information is want is provided in the form of the list of routing profile ID(s), each corresponding to a single host location of the application in the local DN) (LI, paragraph [0113]), and the N6 tunnel is usable to transmit data of a terminal device (wherein in some embodiments, LI teaches that the local DN may be responsible for routing application traffic between PDU session anchors and traffic-handling AFs. In particular, the local DN may implement the N6 interface to ensure session and service continuity in the presence of UE/application mobility. In some embodiments, the local DN provides N6 related traffic routing information to the Core Network for being configured in PDU session anchors, i.e., anchor UPFs of PDU sessions associated to edge computing applications. Further still, in some embodiments, LI teaches that based on the N6 point-to-point tunnelling requirements in the traffic steering policy, the SMF calculates the N6 point-to-point tunnel information and configures it into the PDU session anchor. The N6 point-to-point tunnel information may include Traffic Forwarding Template (TFT) for mapping N6 tunnel to UP path for DL packets and packet handling instructions (e.g. tunnelling protocol header to be applied) for UL packets) (LI, paragraphs [0398] and [0569]). LI does not explicitly disclose the N6 tunnel is an N6 tunnel between a service enabler architecture layer data delivery (SEALDD) server and the user plane network element; and sending, by the session management network element, the second information to the SEALDD server to trigger the SEALDD server to establish the N6 tunnel. However in an analogous art, Pateromichelakis 2 discloses an N6 tunnel is an N6 tunnel between a service enabler architecture layer data delivery (SEALDD) server and a user plane network element (wherein FIG. 1 illustrates a wireless communication system 100 for end-to-end QoS fulfillment. In particular, mobile core network 120 includes several network functions (“NFs”). As depicted, the mobile core network 120 may include one or multiple user plane functions (“UPFs”) 121, connecting SEAL Server 135 via N6 interface (See FIG. 1). The SEAL server 135 provides on-demand (subscription or request) services for all vertical enabler layer (aka middleware) platforms (e.g., UAE servers 133).) (Pateromichelakis 2, FIG. 1, paragraphs [0052], [0063] and [0073]); and sending, by a session management network element, second information to a SEALDD server to trigger the SEALDD server to establish the N6 tunnel (wherein FIGS. 5A and 5B depict a procedure 500 for Network-triggered joint QoS adaptation. With particular reference to FIG. 5B, at Step 5a, the control unit 405 at UAE/SEAL server receives a trigger event from the 5GC (SMF/NEF), denoting a QoS change (experienced or expected). Pateromichelakis 2 teaches that message includes at least the UAV ID, Application ID, and expected degraded QoS parameters (e.g., latency, reliability, data rate, jitter, etc.)) (Pateromichelakis 2, FIGS. 5A and 5B, paragraphs [0106] and [0127]). LI is analogous art because LI is reasonably pertinent to the particular problem with which the inventor was concerned, as LI is generally directed to Protocol Data Unit (PDU) session management in communication networking and Network Management systems, and in particular, to systems and methods for PDU session management that enable application awareness and application-friendly Protocol Data Unit (PDU) session management (See LI, paragraph [0002]), while Pateromichelakis 2 is analogous art, because Pateromichelakis 2 is reasonably pertinent to the particular problem with which the inventor was concerned, as Pateromichelakis 2 is generally directed to wireless communications, and more particularly relates to end-to-end QoS fulfillment (See Pateromichelakis 2, paragraph [0001]). Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of LI and Pateromichelakis 2 before him or her, to modify the SEALDD architecture of LI to include the additional limitations of the N6 tunnel is an N6 tunnel between a service enabler architecture layer data delivery (SEALDD) server and a user plane network element; and sending, by a session management network element, second information to the SEALDD server to trigger the SEALDD server to establish the N6 tunnel, as disclosed in Pateromichelakis 2, with reasonable expectation that this would result in a SEALDD architecture having the added benefit of enabling end-to-end quality of service (QoS) fulfillment, particularly by subscribing to receive notifications of QoS degradations, receiving such notifications, and then taking remedial action by causing appropriate and capable links to be upgraded, thus ensuring QoS requirements were satisfied (See Pateromichelakis 2, paragraph [0108]). This method of improving the SEALDD architecture of LI was well within the ordinary ability of one of ordinary skill in the art based on the teachings of Pateromichelakis 2. Therefore, it would have been obvious to one having ordinary skill in the art to combine the teachings of LI with Pateromichelakis 2 to obtain the invention as specified in claim 16.
As to claim 17, LI-Pateromichelakis 2 discloses the method according to claim 16, wherein the method further comprises: receiving, by the session management network element, first information from the SEALDD server (wherein the control unit 405 at UAE/SEAL server sends a request to 5GC (SMF/NEF), to receive supplement QoS information for the UAV-C (see messaging 615)) (Pateromichelakis 2, FIG. 6B, paragraph [0186]), wherein the first information comprises information provided by the SEALDD server for establishing the N6 tunnel (at least impliedly, as again, N6 is the interface for connecting the DN to the PLMN/5GC (See again, FIG. 1) which will be established regardless when communicating with the PLMN/5GC) (Pateromichelakis 2, FIGS. 1 and 6B, paragraphs [0052] and [0186]); and sending, by the session management network element, the first information to the user plane network element to trigger the user plane network element to establish the N6 tunnel (wherein SMF sends a QoS monitoring request to NG-RAN and to UPF (see block 709) (Pateromichelakis 2, paragraph [0207]). As discussed and shown above, LI is analogous art because LI is reasonably pertinent to the particular problem with which the inventor was concerned, as LI is generally directed to Protocol Data Unit (PDU) session management in communication networking and Network Management systems, and in particular, to systems and methods for PDU session management that enable application awareness and application-friendly Protocol Data Unit (PDU) session management (See LI, paragraph [0002]), while Pateromichelakis 2 is analogous art, because Pateromichelakis 2 is reasonably pertinent to the particular problem with which the inventor was concerned, as Pateromichelakis 2 is generally directed to wireless communications, and more particularly relates to end-to-end QoS fulfillment (See Pateromichelakis 2, paragraph [0001]). Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of LI and Pateromichelakis 2 before him or her, to modify the SEALDD architecture of LI to include the additional limitations of receiving, by the session management network element, first information from the SEALDD server, wherein the first information comprises information provided by the SEALDD server for establishing the N6 tunnel; and sending, by the session management network element, the first information to the user plane network element to trigger the user plane network element to establish the N6 tunnel, as disclosed in Pateromichelakis 2, with reasonable expectation that this would result in a SEALDD architecture having the added benefit of enabling end-to-end quality of service (QoS) fulfillment, particularly by subscribing to receive notifications of QoS degradations, receiving such notifications, and then taking remedial action by causing appropriate and capable links to be upgraded, thus ensuring QoS requirements were satisfied (See Pateromichelakis 2, paragraph [0108]). This method of improving the SEALDD architecture of LI was well within the ordinary ability of one of ordinary skill in the art based on the teachings of Pateromichelakis 2. Therefore, it would have been obvious to one having ordinary skill in the art to combine the teachings of LI with Pateromichelakis 2 to obtain the invention as specified in claim 17.
Regarding claim 18, LI-Pateromichelakis 2 discloses the method according to claim 17, wherein the first information comprises at least one of: information about the terminal device (wherein control unit 405 acting as AF, subscribes to 5GC/NEF per each AF-Service-Identifier or session ID for the UAV and UAV-C session to receive QoS and network monitoring events) (Pateromichelakis 2, paragraph [0126]), routing information of the N6 tunnel, address information of the SEALDD server, port information of the SEALDD server, or a tunnel endpoint identifier of the N6 tunnel on an SEALDD server side. Again, LI is analogous art because LI is reasonably pertinent to the particular problem with which the inventor was concerned, as LI is generally directed to Protocol Data Unit (PDU) session management in communication networking and Network Management systems, and in particular, to systems and methods for PDU session management that enable application awareness and application-friendly Protocol Data Unit (PDU) session management (See LI, paragraph [0002]), while Pateromichelakis 2 is analogous art, because Pateromichelakis 2 is reasonably pertinent to the particular problem with which the inventor was concerned, as Pateromichelakis 2 is generally directed to wireless communications, and more particularly relates to end-to-end QoS fulfillment (See Pateromichelakis 2, paragraph [0001]). Before the effective filing date of the claimed invention, it would have been obvious to one of ordinary skill in the art, having the teachings of LI and Pateromichelakis 2 before him or her, to modify the SEALDD architecture of LI to include the additional limitations of information about the terminal device, routing information of the N6 tunnel, address information of the SEALDD server, port information of the SEALDD server, or a tunnel endpoint identifier of the N6 tunnel on an SEALDD server side, as disclosed in Pateromichelakis 2, with reasonable expectation that this would result in a SEALDD architecture having the added benefit of having knowledge of which sessions to monitor for QoS events (See Pateromichelakis 2, paragraph [0126]). This method of improving the SEALDD architecture of LI was well within the ordinary ability of one of ordinary skill in the art based on the teachings of Pateromichelakis 2. Therefore, it would have been obvious to one having ordinary skill in the art to combine the teachings of LI with Pateromichelakis 2 to obtain the invention as specified in claim 18.
Regarding claim 19, LI-Pateromichelakis 2 discloses the method according to claim 18, wherein the determining, by the session management network element, the second information comprises: allocating, by the session management network element, the second information to the user plane network element (wherein again, the SMF passes the selected traffic steering policy ID(s) to the UPF) (LI, paragraph [0113]; or receiving, by the session management network element, the second information from the user plane network element (wherein N6 traffic routing requirements are related to the mechanism enabling traffic steering in the local access to the DN. They are expected to correspond to local rules configured in the UPFs in order to support traffic steering. The routing profile IDs may refer to a pre-agreed policy between the AF and the 5GC, or in an alternate embodiment they may simply refer to a predefined routing requirement. This policy may refer to different steering policy ID(s) sent to the SMF) (LI, paragraph [0114]). The motivation regarding the obviousness of claim 16 is also applied to claim 19.
Regarding claim 20, LI-Pateromichelakis 2 discloses the method according to claim 18, wherein the second information comprises at least one of: address information of the user plane network element, port information of the user plane network element, or a tunnel endpoint identifier of the N6 tunnel on a user plane network element side (again, traffic steering policy ID(s) of N6 routing information) (LI, paragraph [0113]). The motivation regarding the obviousness of claim 16 is also applied to claim 20.
Conclusion
14. Further references of interest are cited on Form PTO-892, which is an attachment to this Office Action. For instance, PATEROMICHELAKIS (USPGPUB 2025/0202787) discloses a method for providing energy data for an application service. The method comprises receiving an energy data requirement for the application service from a requesting node, and determining a set of energy data producers associated with the application service from which to collect energy data based on the energy data requirement. The method further comprises collecting a first set of energy data from the set of energy data producers, and computing a second set of energy data for the application service based on the first set of energy data. The method 400 further comprises sending a report comprising the second set of energy data to the requesting node (See Abstract). SALKINTZIS (WO 2023/099040) discloses a method in a wireless communications device, the method comprising: receiving a data collection requirement from a data collection coordination node, the data collection requirement defining a data collection event associated with application traffic between the wireless communications device and a node within the wireless communications network; detecting the occurrence of the data collection event; collecting data associated with application traffic between the wireless communications device and the node within the wireless communications network in respect of the data collection event; and sending the collected data to the data collection coordination node (See Abstract).
15. Any inquiry concerning this communication or earlier communications from the examiner should be directed to KOSTAS J. KATSIKIS whose telephone number is (571)270-5434. The examiner can normally be reached Monday-Friday, 9:00am-5:00pm. 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, Kamal B. Divecha can be reached at 571-272-5863. 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.
/KOSTAS J KATSIKIS/Primary Examiner, Art Unit 2453
Prosecution Insights