DETAILED ACTION
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 .
Response to Amendment
The Amendment filed July 20, 2026, has been entered. Claims 1-6 and 9-22 are pending in the application. Applicant has submitted amendments to the claims along with other remarks.
Response to Arguments
Applicant’s arguments and amendments, see pp. 10-19 of the response, filed July 20, 2026, with respect to the rejection(s) of claim(s) 1-6 and 9-22 under § 103 have been fully considered and are persuasive. However, upon further consideration for the amendments, a new ground(s) of rejection is made in view of new reference, please see the rejection for details.
Claim Objections
Applicant is advised that should claim 13 be found allowable, claim 16 will be objected to under 37 CFR 1.75 as being a substantial duplicate thereof. When two claims in an application are duplicates or else are so close in content that they both cover the same thing, despite a slight difference in wording, it is proper after allowing one claim to object to the other as being a substantial duplicate of the allowed claim. See MPEP § 608.01(m).
Claim Rejections - 35 USC § 103
The text of those sections of Title 35, U.S. Code not included in this action can be found in a prior Office action.
Claims 1, 5-6, 9-12, 18, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. Publication No. 2022/0124543 (hereinafter “Orhan”) in view of U.S. Publication No. 2021/0337420 (hereinafter “Lo”)
Regarding claim 1, Orhan teaches: A system, comprising: a processing system including a processor; and a memory that stores executable instructions that, when executed by the processing system, facilitate performance of operations, the operations comprising: training a machine learning model to obtain a trained model according to service management and orchestration (SMO) network domain functions ([0088] The Non-RT RIC 320 can use data analytics and AI/ML training/inference to determine the RAN optimization actions for which it can leverage SMO 302 services such as data collection and provisioning services of the O-RAN nodes.), wherein: the trained model is trained to enable selection of at least one of a wireline network or a wireless network, and the wireline network comprises a wireline network element and the wireless network comprises a wireless network element ([0233-237]); obtaining a service requirement of a network-enabled user device ([0021] The present disclosure provides an ML/AI-based framework for load-aware connection management and/or handover management to optimize user associations/connections and load balancing to fulfill QoS requirements.[0140] measurements related to Carrier (CARR); measurements related to QoS Flows (QF) (e.g., number of released active QoS flows, number of QoS flows attempted to release, in-session activity time for QoS flow, in-session activity time for a UE 1011, 1021, number of QoS flows attempted to setup, number of QoS flows successfully established, number of QoS flows failed to setup, number of initial QoS flows attempted to setup, number of initial QoS flows successfully established, number of initial QoS flows failed to setup, number of QoS flows attempted to modify, number of QoS flows successfully modified, number of QoS flows failed to modify, etc.); [0415]); receiving, at a network edge, first network information of the wireline network accessible by the network-enabled user device from the wireline network element via a standard interface ([0036] In addition or alternatively to the various examples mentioned previously, the CMF 136 techniques and technologies can be applied to other types of networks of different communicating nodes . . . a gateway device, [0422] The term “QoS Identifier” at least in some embodiments refers to a scalar that is used as a reference to a specific QoS forwarding behavior (e.g., packet loss rate, packet delay budget, etc.) to be provided to a QoS flow. This may be implemented in an access network by referencing node specific parameters that control the QoS forwarding treatment (e.g., scheduling weights, admission thresholds, queue management thresholds, link layer protocol configuration, etc.).), wherein: the network edge comprises an access domain intelligent controlling operating in an open access network architecture ([0022]); receiving, at the network edge, second network information of the wireless network accessible by the network-enabled user device from the wireless network element via the standard interface ([0087] Here, the logical functions of the xApp, which optimize CU 132, DU 131, and RU 130 functions and resources, run with control loops of 10 milliseconds (ms) to 1 second (s). The Near-RT RIC 301 allows for the reading and writing of RAN and/or UE information, messaging infrastructure, and interfaces to service management and orchestration (SMO) 302 and E2 nodes 303.); receiving, at the network edge, supporting information from a first microservice of a first plurality of microservices, wherein the first microservice is remote from the network edge and the supporting information is obtained via SMO network domain functions ([0091] The Near-RT RIC 301 also hosts or otherwise provides various functions hosted by xApps, which allow services to be executed at the Near-RT RIC 301 and the outcomes sent to the E2 Nodes 303 via E2 interface. In various embodiments, the xApp functionality hosted by the Near-RT RIC 301 includes the CMF 136 implemented as CMF xApp 400.; [0080] As mentioned previously, the CMF 136 can be implemented using the O-RAN framework (see e.g., [O-RAN]), where the CMF 136 can be implemented as an xApp operated by a RIC. In O-RAN, xApps are applications designed to run on the near-RT RIC to provide one or more microservices. The microservices obtain input data through interfaces between the RIC and RAN functionality, and provide additional functionality as output data to a RAN. In various embodiments, the CMF 136 is implemented as a scalable xApp that provides connection management for network deployments. . . . The examples discussed infra involve a GNN-RL model being used for “connection events” (sometimes referred to as “measurement events” or “mobility events”) in which mobile users in a network request new connections, which may include, for example, connection establishment, connection re-establishment, connection reconfiguration, connection release (e.g., to re-direct the UE 221) to a different frequency or carrier frequency), connection suspension, connection resumption, handovers, cell selection or cell re-selection, measurement report triggering, radio link failure/recovery, WiFi associate messages, WiFi reassociate messages, WiFi disassociate messages, WiFi measurement requests and/or measurement reports, WiFi channel switch, and/or other mobility and state transitions . . . When the CMF 136 detects a connection event (e.g., receipt of a measurement report, an HO request for an intra-RAT HO and/or inter-RAT HO, cell selection message, cell reselection message, radio link failure detection and recovery message(s), beam failure detection and recovery message(s), WiFi associate messages, WiFi reassociate messages, WiFi disassociate messages, WiFi measurement requests and/or measurement reports, WiFi channel switch, and the like), the CMF 136 operates the GNN-RL model to make new connection decisions to optimize the network 100 such as by balancing the load across the network 100.); sending the first network information and the second network information to a second microservice (CMF 136) of a second plurality of microservices at the network edge, wherein: the trained model is provided to a network element hosting the second microservice ([0021] The edge intelligence 135 includes a connection management function (CMF) 136 and a number of CUs 132.), the second microservice is configured to operate in association with the trained model ([0087] In this example, the GNN-RL model is implemented as a CMF xApp 350, which utilizes the O1, A1, and E2 interfaces in the Near-RT RIC 301 and works in conjunction with other xApps 1 to A.), the second microservice is configured to select at least one of the wireline network or the wireless network according to the first network information, the second network information, the supporting information, and the trained model to obtain a network selection, and the network selection is further based on the network policy ([0080] In various embodiments, the CMF 136 is implemented as a scalable xApp that provides connection management for network deployments. . . . The examples discussed infra involve a GNN-RL model being used for “connection events” (sometimes referred to as “measurement events” or “mobility events”); and establishing a network connection to the network-enabled user device according to the network selection, wherein a service according to the service requirement is supported via the network connection ([0080] the CMF 136 is implemented as a scalable xApp that provides connection management for network deployments).
Orhan teaches that the “Non-RT RIC 320 supports intelligent RAN optimization by providing policy-based guidance.” Orhan does not explicitly teach identifying a network policy.
However, in the same field of endeavor, Lo teaches: identifying a network policy ([0271] At operation 2001, the near-RT RIC receives a policy from the non-RT RIC over A1 interface or from the SMO entity over O1 interface.).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Orhan to include the feature of identifying a policy and a combination of Orhan with Lo renders the claim prima facie obvious within the described scope of the prior art and any indicated differences within the level of one of ordinary skill in the art (e.g., telecommunications engineer) according to a combination of known prior art elements with known methods to yield predictable results. MPEP 2143(I)(A) (e.g., identifying a policy).
Regarding claim 5, Orhan teaches: wherein the establishing the network connection to the network-enabled user device comprises designing and orchestrating a plurality of network elements to obtain a configuration of network infrastructure ([0059] Graph Neural Networks (GNNs) are a framework to capture the dependence of nodes in graphs via message passing between the nodes. Unlike deep neural networks (DNNs), GNNs directly operate on a graph to represent information from its neighborhood with arbitrary hops.).
Regarding claim 6, Orhan teaches: wherein the plurality of network elements comprises virtual network elements of a cloud service ([0127]; [0153]).
Regarding claim 9, Orhan does not explicitly teach: wherein the network policy comprises maintaining a threshold level of the service requirement.
However, in the same field of endeavor, Lo teaches: wherein the network policy comprises maintaining a threshold level of the service requirement ([0277]; [0288] Rsrp-ThresholdCSI-RS).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Orhan to include the feature of a threshold level of service requirement and a combination of Orhan with Lo renders the claim prima facie obvious within the described scope of the prior art and any indicated differences within the level of one of ordinary skill in the art (e.g., telecommunications engineer) according to a combination of known prior art elements with known methods to yield predictable results. MPEP 2143(I)(A) (e.g., including a threshold level of service requirement).
Regarding claim 10, Orhan teaches: wherein the wireless network comprises at least one of a wireless link, a radio access network of a mobile cellular service, a satellite communications link, a microwave link, a free-space optical link, or a wired link ([0402] optical and/or visible light communication (VLC) technologies/standards such as IEEE 802.15.7 and the like).
Regarding claim 11, Orhan teaches: wherein the wireline network comprises a passive optical network ([0402] optical and/or visible light communication (VLC) technologies/standards such as IEEE 802.15.7 and the like).
Regarding claim 12, Orhan teaches: A method, comprising: training a machine learning model to obtain a trained model according to service management and orchestration (SMO) network domain functions ([0088] The Non-RT RIC 320 can use data analytics and AI/ML training/inference to determine the RAN optimization actions for which it can leverage SMO 302 services such as data collection and provisioning services of the O-RAN nodes.), wherein; the trained model is trained to enable selection of at least one of a wireline network or a wireless network, and the wireline network comprises a wireline network element and the wireless network comprises a wireless network element ([0233-237]); identifying, by a processing system comprising a processor, a service requirement of a user device ([0021] The present disclosure provides an ML/AI-based framework for load-aware connection management and/or handover management to optimize user associations/connections and load balancing to fulfill QoS requirements.[0140] measurements related to Carrier (CARR); measurements related to QoS Flows (QF) (e.g., number of released active QoS flows, number of QoS flows attempted to release, in-session activity time for QoS flow, in-session activity time for a UE 1011, 1021, number of QoS flows attempted to setup, number of QoS flows successfully established, number of QoS flows failed to setup, number of initial QoS flows attempted to setup, number of initial QoS flows successfully established, number of initial QoS flows failed to setup, number of QoS flows attempted to modify, number of QoS flows successfully modified, number of QoS flows failed to modify, etc.); [0415]); receiving, by the processing system, at a network edge, first network information of the wireline network accessible by the user device from the wireline network element via a standard interface ([0036] In addition or alternatively to the various examples mentioned previously, the CMF 136 techniques and technologies can be applied to other types of networks of different communicating nodes . . . a gateway device, [0422] The term “QoS Identifier” at least in some embodiments refers to a scalar that is used as a reference to a specific QoS forwarding behavior (e.g., packet loss rate, packet delay budget, etc.) to be provided to a QoS flow. This may be implemented in an access network by referencing node specific parameters that control the QoS forwarding treatment (e.g., scheduling weights, admission thresholds, queue management thresholds, link layer protocol configuration, etc.).), wherein the network edge comprises an access domain intelligent controlling operating in an open access network architecture ([0022]); receiving, by the processing system, at the network edge, second network information of the wireless network accessible by the user device from the wireless network element via the standard interface ([0087] Here, the logical functions of the xApp, which optimize CU 132, DU 131, and RU 130 functions and resources, run with control loops of 10 milliseconds (ms) to 1 second (s). The Near-RT RIC 301 allows for the reading and writing of RAN and/or UE information, messaging infrastructure, and interfaces to service management and orchestration (SMO) 302 and E2 nodes 303.); receiving, by the processing system, at the network edge, supporting information from a first microservice of a first plurality of microservices, wherein the first microservice is remote from the network edge and the supporting information is obtained via -SMO network domain functions ([0091] The Near-RT RIC 301 also hosts or otherwise provides various functions hosted by xApps, which allow services to be executed at the Near-RT RIC 301 and the outcomes sent to the E2 Nodes 303 via E2 interface. In various embodiments, the xApp functionality hosted by the Near-RT RIC 301 includes the CMF 136 implemented as CMF xApp 400.; [0080] As mentioned previously, the CMF 136 can be implemented using the O-RAN framework (see e.g., [O-RAN]), where the CMF 136 can be implemented as an xApp operated by a RIC. In O-RAN, xApps are applications designed to run on the near-RT RIC to provide one or more microservices. The microservices obtain input data through interfaces between the RIC and RAN functionality, and provide additional functionality as output data to a RAN. In various embodiments, the CMF 136 is implemented as a scalable xApp that provides connection management for network deployments. . . . The examples discussed infra involve a GNN-RL model being used for “connection events” (sometimes referred to as “measurement events” or “mobility events”) in which mobile users in a network request new connections, which may include, for example, connection establishment, connection re-establishment, connection reconfiguration, connection release (e.g., to re-direct the UE 221) to a different frequency or carrier frequency), connection suspension, connection resumption, handovers, cell selection or cell re-selection, measurement report triggering, radio link failure/recovery, WiFi associate messages, WiFi reassociate messages, WiFi disassociate messages, WiFi measurement requests and/or measurement reports, WiFi channel switch, and/or other mobility and state transitions . . . When the CMF 136 detects a connection event (e.g., receipt of a measurement report, an HO request for an intra-RAT HO and/or inter-RAT HO, cell selection message, cell reselection message, radio link failure detection and recovery message(s), beam failure detection and recovery message(s), WiFi associate messages, WiFi reassociate messages, WiFi disassociate messages, WiFi measurement requests and/or measurement reports, WiFi channel switch, and the like), the CMF 136 operates the GNN-RL model to make new connection decisions to optimize the network 100 such as by balancing the load across the network 100.); forwarding, by the processing system, the first network information and the second network information to a second microservice (CMF 136) of a second plurality of microservices at the network edge, wherein: the trained model is provided to a network element hosting the second microservice ([0021] The edge intelligence 135 includes a connection management function (CMF) 136 and a number of CUs 132.), the second microservice is configured to operate in association with the trained model ([0087] In this example, the GNN-RL model is implemented as a CMF xApp 350, which utilizes the O1, A1, and E2 interfaces in the Near-RT RIC 301 and works in conjunction with other xApps 1 to A.), the second microservice is configured to select at least one of the wireline network or the wireless network according to the first network information, the second network information, the supporting information to obtain a network selection, and the trained model, and the network selection is further based on the network policy ([0080] In various embodiments, the CMF 136 is implemented as a scalable xApp that provides connection management for network deployments. . . . The examples discussed infra involve a GNN-RL model being used for “connection events” (sometimes referred to as “measurement events” or “mobility events”); and coordinating a network connection to the user device according to the network selection, wherein a service according to the service requirement is supported via the network connection ([0080] the CMF 136 is implemented as a scalable xApp that provides connection management for network deployments).
Orhan teaches that the “Non-RT RIC 320 supports intelligent RAN optimization by providing policy-based guidance.” Orhan does not explicitly teach identifying a network policy.
However, in the same field of endeavor, Lo teaches: identifying a network policy ([0271] At operation 2001, the near-RT RIC receives a policy from the non-RT RIC over A1 interface or from the SMO entity over O1 interface.).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Orhan to include the feature of identifying a policy and a combination of Orhan with Lo renders the claim prima facie obvious within the described scope of the prior art and any indicated differences within the level of one of ordinary skill in the art (e.g., telecommunications engineer) according to a combination of known prior art elements with known methods to yield predictable results. MPEP 2143(I)(A) (e.g., identifying a policy).
Regarding claim 18, Orhan teaches: A non-transitory, machine-readable medium, comprising executable instructions that, when executed by a processing system including a processor, facilitate performance of operations, the operations comprising: training a machine learning model to obtain a trained model according to service management and orchestration (SMO) network domain functions ([0088] The Non-RT RIC 320 can use data analytics and AI/ML training/inference to determine the RAN optimization actions for which it can leverage SMO 302 services such as data collection and provisioning services of the O-RAN nodes.), wherein; the trained model is trained to enable selection of at least one of a wireline network or a wireless network, and the wireline network comprises a wireline network element and the wireless network comprises a wireless network element ([0233-237]); determining a service requirement of a user device ([0021] The present disclosure provides an ML/AI-based framework for load-aware connection management and/or handover management to optimize user associations/connections and load balancing to fulfill QoS requirements.[0140] measurements related to Carrier (CARR); measurements related to QoS Flows (QF) (e.g., number of released active QoS flows, number of QoS flows attempted to release, in-session activity time for QoS flow, in-session activity time for a UE 1011, 1021, number of QoS flows attempted to setup, number of QoS flows successfully established, number of QoS flows failed to setup, number of initial QoS flows attempted to setup, number of initial QoS flows successfully established, number of initial QoS flows failed to setup, number of QoS flows attempted to modify, number of QoS flows successfully modified, number of QoS flows failed to modify, etc.); [0415]); obtaining at a network edge, first network information of the wireline network and second network information of the wireless network, wherein: the network edge comprises an access domain intelligent controlling operating in an open access network architecture ([0022]) the first network information is received from the wireline network element ([0036] In addition or alternatively to the various examples mentioned previously, the CMF 136 techniques and technologies can be applied to other types of networks of different communicating nodes . . . a gateway device, [0422] The term “QoS Identifier” at least in some embodiments refers to a scalar that is used as a reference to a specific QoS forwarding behavior (e.g., packet loss rate, packet delay budget, etc.) to be provided to a QoS flow. This may be implemented in an access network by referencing node specific parameters that control the QoS forwarding treatment (e.g., scheduling weights, admission thresholds, queue management thresholds, link layer protocol configuration, etc.).), and the second wireless information is received from the wireless network element ([0087] Here, the logical functions of the xApp, which optimize CU 132, DU 131, and RU 130 functions and resources, run with control loops of 10 milliseconds (ms) to 1 second (s). The Near-RT RIC 301 allows for the reading and writing of RAN and/or UE information, messaging infrastructure, and interfaces to service management and orchestration (SMO) 302 and E2 nodes 303.); providing, at the network edge, the first network information and the second network information to a first microservice configured to select at least one of the wireline network or the wireless network according to the first network information and the second network information to obtain a network selection ([0080] In various embodiments, the CMF 136 is implemented as a scalable xApp that provides connection management for network deployments. . . . The examples discussed infra involve a GNN-RL model being used for “connection events” (sometimes referred to as “measurement events” or “mobility events”), wherein: the network selection is further based on supporting information received from a second microservice in communication with the first microservice, the supporting information is obtained via the SMO network domain functions ([0091] The Near-RT RIC 301 also hosts or otherwise provides various functions hosted by xApps, which allow services to be executed at the Near-RT RIC 301 and the outcomes sent to the E2 Nodes 303 via E2 interface. In various embodiments, the xApp functionality hosted by the Near-RT RIC 301 includes the CMF 136 implemented as CMF xApp 400.; [0080] As mentioned previously, the CMF 136 can be implemented using the O-RAN framework (see e.g., [O-RAN]), where the CMF 136 can be implemented as an xApp operated by a RIC. In O-RAN, xApps are applications designed to run on the near-RT RIC to provide one or more microservices. The microservices obtain input data through interfaces between the RIC and RAN functionality, and provide additional functionality as output data to a RAN. In various embodiments, the CMF 136 is implemented as a scalable xApp that provides connection management for network deployments. . . . The examples discussed infra involve a GNN-RL model being used for “connection events” (sometimes referred to as “measurement events” or “mobility events”) in which mobile users in a network request new connections, which may include, for example, connection establishment, connection re-establishment, connection reconfiguration, connection release (e.g., to re-direct the UE 221) to a different frequency or carrier frequency), connection suspension, connection resumption, handovers, cell selection or cell re-selection, measurement report triggering, radio link failure/recovery, WiFi associate messages, WiFi reassociate messages, WiFi disassociate messages, WiFi measurement requests and/or measurement reports, WiFi channel switch, and/or other mobility and state transitions . . . When the CMF 136 detects a connection event (e.g., receipt of a measurement report, an HO request for an intra-RAT HO and/or inter-RAT HO, cell selection message, cell reselection message, radio link failure detection and recovery message(s), beam failure detection and recovery message(s), WiFi associate messages, WiFi reassociate messages, WiFi disassociate messages, WiFi measurement requests and/or measurement reports, WiFi channel switch, and the like), the CMF 136 operates the GNN-RL model to make new connection decisions to optimize the network 100 such as by balancing the load across the network 100.), the trained model is provided to a network element hosting the first microservice, the first microservice is configured to operate in association with the trained model ([0087] In this example, the GNN-RL model is implemented as a CMF xApp 350, which utilizes the O1, A1, and E2 interfaces in the Near-RT RIC 301 and works in conjunction with other xApps 1 to A.), and the network selection is further based on the network policy ([0088]); and coordinating a network connection to the user device according to the network selection, wherein a service according to the service requirement is supported via the network connection ([0080] In various embodiments, the CMF 136 is implemented as a scalable xApp that provides connection management for network deployments. . . . The examples discussed infra involve a GNN-RL model being used for “connection events” (sometimes referred to as “measurement events” or “mobility events”).
Regarding claim 21, Orhan teaches: Orhan does not explicitly teach: wherein the network policy comprises maintaining a threshold level of the service requirement.
However, in the same field of endeavor, Lo teaches: wherein the network policy comprises maintaining a threshold level of the service requirement ([0277]; [0288] Rsrp-ThresholdCSI-RS).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify Orhan to include the feature of a threshold level of service requirement and a combination of Orhan with Lo renders the claim prima facie obvious within the described scope of the prior art and any indicated differences within the level of one of ordinary skill in the art (e.g., telecommunications engineer) according to a combination of known prior art elements with known methods to yield predictable results. MPEP 2143(I)(A) (e.g., including a threshold level of service requirement).
Claims 2-3, 13-16, and 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Orhan in view of Lo and further in view of U.S. Publication No. 2008/0317045 (hereinafter “Chen_1”).
Regarding claim 2, the combination of Orhan and Lo teaches performing operations based on a service requirement ([0021]). The combination of Orhan and Lo does not teach: categorizing the service requirement according to one of a metaverse service category or a non-metaverse service category to obtain a service categorization.
Chen_1 discloses a method for providing differentiated service based on a classification or categorization of the service. Chen_1 teaches: categorizing the service requirement according to one of a metaverse service category or a non-metaverse service category to obtain a service categorization ([0004] Providing DS-TE (Differentiated service-Traffic Engineering) services in an IP network using MPLS (Multi-Protocol Label Switching) technology is attracting more and more attention. It solves the problem of differentiating different service types in a network in an extensible way, and makes specific data get better treatment than a "Best Effort" service stream gets, and allows coexistence of delay-sensitive services and general IP services. Its main principle is that a router uses a group of well-defined structure blocks to classify service streams; individual level of service streams are differentiated through networks and services according to QoS required by the classified service streams. Thus, the DS-TE allows to perform different PHB (Per Hop Behavior) according to relative service priorities allocated to service streams when data packets are forwarded. Data packets sharing the same forwarding processing share the same level of services.).
Thus, the combination of Orhan and Lo with Chen_1 each disclose optimizing network traffic based on a service requirement. A person of ordinary skill in the art before the effective filing date of the claimed invention would have recognized that the categorization of Chen_1 could have been substituted for the service requirement of Orhan because both perform the function of optimizing network traffic according to a service requirement. Furthermore, a person of ordinary skill in the art would have been able to carry out the substitution. Finally, the substitution achieves the predictable result of categorizing the service requirement and optimizing network utilization using the methods known in Chen_1.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to substitute the categorization techniques in Chen_1 for the service requirement in Orhan according to known methods to yield the predictable result of optimization of network traffic according to categorization of a service requirement. Chen_1 and Orhan are silent on whether the service requirement is specifically related to metaverse or non-metaverse service categories; however, these elements are referred to generically in name only and specific technical details of their categorization is not recited. Generic categorization is taught by Chen_1 (See also, PAN-OS non-patent literature).
Regarding claim 3, Orhan teaches: wherein the network selection is further based on the service categorization ([0021] load balancing to fulfill QoS requirements).
Regarding claim 13, the combination of Orhan and Lo teaches performing operations based on a service requirement ([0021]) wherein the network selection is further based on the service categorization ([0021] load balancing to fulfill QoS requirements). The combination of Orhan and Lo does not teach: categorizing the service requirement according to one of a metaverse service category or a non-metaverse service category to obtain a service categorization.
Chen_1 discloses a method for providing differentiated service based on a classification or categorization of the service. Chen_1 teaches: categorizing the service requirement according to one of a metaverse service category or a non-metaverse service category to obtain a service categorization ([0004] Providing DS-TE (Differentiated service-Traffic Engineering) services in an IP network using MPLS (Multi-Protocol Label Switching) technology is attracting more and more attention. It solves the problem of differentiating different service types in a network in an extensible way, and makes specific data get better treatment than a "Best Effort" service stream gets, and allows coexistence of delay-sensitive services and general IP services. Its main principle is that a router uses a group of well-defined structure blocks to classify service streams; individual level of service streams are differentiated through networks and services according to QoS required by the classified service streams. Thus, the DS-TE allows to perform different PHB (Per Hop Behavior) according to relative service priorities allocated to service streams when data packets are forwarded. Data packets sharing the same forwarding processing share the same level of services.).
Thus, the combination of Orhan and Lo with Chen_1 each disclose optimizing network traffic based on a service requirement. A person of ordinary skill in the art before the effective filing date of the claimed invention would have recognized that the categorization of Chen_1 could have been substituted for the service requirement of Orhan because both perform the function of optimizing network traffic according to a service requirement. Furthermore, a person of ordinary skill in the art would have been able to carry out the substitution. Finally, the substitution achieves the predictable result of categorizing the service requirement and optimizing network utilization using the methods known in Chen_1.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to substitute the categorization techniques in Chen_1 for the service requirement in Orhan according to known methods to yield the predictable result of optimization of network traffic according to categorization of a service requirement. Chen_1 and Orhan are silent on whether the service requirement is specifically related to metaverse or non-metaverse service categories; however, these elements are referred to generically in name only and specific technical details of their categorization is not recited. Generic categorization is taught by Chen_1 (See also, PAN-OS non-patent literature).
Regarding claim 14, Orhan teaches: wherein the wireline network and the wireless network comprise access networks ([0128-129]).
Regarding claim 15, the combination of Orhan and Lo teaches performing operations based on a service requirement ([0021]). The combination of Orhan and Lo does not teach: categorizing the service requirement according to one of a metaverse service category or a non-metaverse service category to obtain a service categorization.
Chen_1 discloses a method for providing differentiated service based on a classification or categorization of the service. Chen_1 teaches: categorizing the service requirement according to one of a metaverse service category or a non-metaverse service category to obtain a service categorization ([0004] Providing DS-TE (Differentiated service-Traffic Engineering) services in an IP network using MPLS (Multi-Protocol Label Switching) technology is attracting more and more attention. It solves the problem of differentiating different service types in a network in an extensible way, and makes specific data get better treatment than a "Best Effort" service stream gets, and allows coexistence of delay-sensitive services and general IP services. Its main principle is that a router uses a group of well-defined structure blocks to classify service streams; individual level of service streams are differentiated through networks and services according to QoS required by the classified service streams. Thus, the DS-TE allows to perform different PHB (Per Hop Behavior) according to relative service priorities allocated to service streams when data packets are forwarded. Data packets sharing the same forwarding processing share the same level of services.).
Thus, the combination of Orhan and Lo with Chen_1 each disclose optimizing network traffic based on a service requirement. A person of ordinary skill in the art before the effective filing date of the claimed invention would have recognized that the categorization of Chen_1 could have been substituted for the service requirement of Orhan because both perform the function of optimizing network traffic according to a service requirement. Furthermore, a person of ordinary skill in the art would have been able to carry out the substitution. Finally, the substitution achieves the predictable result of categorizing the service requirement and optimizing network utilization using the methods known in Chen_1.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to substitute the categorization techniques in Chen_1 for the service requirement in Orhan according to known methods to yield the predictable result of optimization of network traffic according to categorization of a service requirement. Chen_1 and Orhan are silent on whether the service requirement is specifically related to metaverse or non-metaverse service categories; however, these elements are referred to generically in name only and specific technical details of their categorization is not recited. Generic categorization is taught by Chen_1 (See also, PAN-OS non-patent literature).
Regarding claim 16, Orhan teaches: wherein the network selection is further based on the service categorization ([0021] load balancing to fulfill QoS requirements).
Regarding claim 19, the combination of Orhan and Lo teaches performing operations based on a service requirement ([0021]) wherein the network selection is further based on the service categorization ([0021] load balancing to fulfill QoS requirements). The combination of Orhan and Lo does not teach: categorizing the service requirement according to one of a metaverse service category or a non-metaverse service category to obtain a service categorization.
Chen_1 discloses a method for providing differentiated service based on a classification or categorization of the service. Chen_1 teaches: categorizing the service requirement according to one of a metaverse service category or a non-metaverse service category to obtain a service categorization ([0004] Providing DS-TE (Differentiated service-Traffic Engineering) services in an IP network using MPLS (Multi-Protocol Label Switching) technology is attracting more and more attention. It solves the problem of differentiating different service types in a network in an extensible way, and makes specific data get better treatment than a "Best Effort" service stream gets, and allows coexistence of delay-sensitive services and general IP services. Its main principle is that a router uses a group of well-defined structure blocks to classify service streams; individual level of service streams are differentiated through networks and services according to QoS required by the classified service streams. Thus, the DS-TE allows to perform different PHB (Per Hop Behavior) according to relative service priorities allocated to service streams when data packets are forwarded. Data packets sharing the same forwarding processing share the same level of services.).
Thus, the combination of Orhan and Lo with Chen_1 each disclose optimizing network traffic based on a service requirement. A person of ordinary skill in the art before the effective filing date of the claimed invention would have recognized that the categorization of Chen_1 could have been substituted for the service requirement of Orhan because both perform the function of optimizing network traffic according to a service requirement. Furthermore, a person of ordinary skill in the art would have been able to carry out the substitution. Finally, the substitution achieves the predictable result of categorizing the service requirement and optimizing network utilization using the methods known in Chen_1.
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to substitute the categorization techniques in Chen_1 for the service requirement in Orhan according to known methods to yield the predictable result of optimization of network traffic according to categorization of a service requirement. Chen_1 and Orhan are silent on whether the service requirement is specifically related to metaverse or non-metaverse service categories; however, these elements are referred to generically in name only and specific technical details of their categorization is not recited. Generic categorization is taught by Chen_1 (See also, PAN-OS non-patent literature).
Regarding claim 20, Orhan teaches: wherein the wireline network and the wireless network comprise access networks ([0128-129]).
Claims 4, 17, and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Orhan in view of Lo and Chen_1 and further in view of Non-patent literature entitled, “Data Correlation-Aware Resource Management in Wireless Virtual Reality (VR): An Echo State Transfer Learning Approach” (hereinafter “Chen_2”).
Regarding claim 4, the combination of Orhan, Lo, and Chen_1 does not explicitly teach: wherein responsive to the service categorization comprising the metaverse service category, the operations further comprise: determining a data set pertaining to the network-enabled user device, the data set identifying a plurality of virtual items occurring with an instance of a metaverse environment of a metaverse service; and mapping an item of the plurality of virtual items to the network-enabled user device, wherein the network selection is further based on the mapping.
However, in the same field of endeavor, Chen_2 teaches: wherein responsive to the service categorization comprising the metaverse service category, the operations further comprise: determining a data set pertaining to the network-enabled user device, the data set identifying a plurality of virtual items occurring with an instance of a metaverse environment of a metaverse service (p. “visible contents” 3:2); and mapping an item of the plurality of virtual items to the network-enabled user device, wherein the network selection is further based on the mapping (pp. “QoS” 4:1, 5:2).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Orhan, Lo, and Chen_1 to include the feature of mapping virtual items to user devices and a combination of Orhan, Lo, and Chen_1 with Chen_2 renders the claim prima facie obvious within the described scope of the prior art and any indicated differences within the level of one of ordinary skill in the art (e.g., telecommunications engineer) according to a combination of known prior art elements with known methods to yield predictable results. MPEP 2143(I)(A) (e.g., mapping virtual items to user devices).
Regarding claim 17, the combination of Orhan, Lo, and Chen_1 does not explicitly teach: wherein responsive to the service categorization comprising the metaverse service category, the operations further comprise: determining a data set pertaining to the network-enabled user device, the data set identifying a plurality of virtual items occurring with an instance of a metaverse environment of a metaverse service; and mapping an item of the plurality of virtual items to the network-enabled user device, wherein the network selection is further based on the mapping.
However, in the same field of endeavor, Chen_2 teaches: wherein responsive to the service categorization comprising the metaverse service category, the operations further comprise: determining a data set pertaining to the network-enabled user device, the data set identifying a plurality of virtual items occurring with an instance of a metaverse environment of a metaverse service (p. “visible contents” 3:2); and mapping an item of the plurality of virtual items to the network-enabled user device, wherein the network selection is further based on the mapping (pp. “QoS” 4:1, 5:2).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Orhan, Lo, and Chen_1 to include the feature of mapping virtual items to user devices and a combination of Orhan, Lo, and Chen_1 with Chen_2 renders the claim prima facie obvious within the described scope of the prior art and any indicated differences within the level of one of ordinary skill in the art (e.g., telecommunications engineer) according to a combination of known prior art elements with known methods to yield predictable results. MPEP 2143(I)(A) (e.g., mapping virtual items to user devices).
Regarding claim 22, the combination of Orhan, Lo, and Chen_1 does not explicitly teach: wherein responsive to the service categorization comprising the metaverse service category, the operations further comprise: determining a data set pertaining to the network-enabled user device, the data set identifying a plurality of virtual items occurring with an instance of a metaverse environment of a metaverse service; and mapping an item of the plurality of virtual items to the network-enabled user device, wherein the network selection is further based on the mapping.
However, in the same field of endeavor, Chen_2 teaches: wherein responsive to the service categorization comprising the metaverse service category, the operations further comprise: determining a data set pertaining to the network-enabled user device, the data set identifying a plurality of virtual items occurring with an instance of a metaverse environment of a metaverse service (p. “visible contents” 3:2); and mapping an item of the plurality of virtual items to the network-enabled user device, wherein the network selection is further based on the mapping (pp. “QoS” 4:1, 5:2).
Therefore, it would have been obvious to a person of ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Orhan, Lo, and Chen_1 to include the feature of mapping virtual items to user devices and a combination of Orhan, Lo, and Chen_1 with Chen_2 renders the claim prima facie obvious within the described scope of the prior art and any indicated differences within the level of one of ordinary skill in the art (e.g., telecommunications engineer) according to a combination of known prior art elements with known methods to yield predictable results. MPEP 2143(I)(A) (e.g., mapping virtual items to user devices).
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JUSTIN BARRY whose telephone number is (571)272-0201. The examiner can normally be reached 8:00am EST to 5:00pm EST.
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, Jinsong HU can be reached at (571) 272-3965. 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.
/JAB/
Examiner, Art Unit 2643
/JINSONG HU/ Supervisory Patent Examiner, Art Unit 2643
Prosecution Insights