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 .
Status of Claims:
Claims 1-20 are pending in this Office Action.
Claims 5 and 16 are amended.
Claims 1-20 are rejected. This rejection is FINAL.
Previous Rejections Withdrawn
The Double Patenting Rejection is withdrawn based upon the Terminal Disclaimer filed on 07/28/2026.
Response to Arguments
Applicant's arguments filed in the amendment filed 07/28/2026, have been fully considered but they are not persuasive. The reasons are set forth below.
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 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.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries set forth in Graham v. John Deere Co., 383 U.S. 1, 148 USPQ 459 (1966), that are applied for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claims 1-2, 5-7, 9-11, 14-16, and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Adjakple et al. (U.S. Publication No. 2024/0236835) in view of Shah et al. (U.S. Publication No. 2026/0100989), and further in view of Sangameshwara et al. (U.S. Publication No. 2024/0380824).
As per claim 1, Adjakple discloses a first network entity for wireless communication (Adjakple: paragraph 0009; an apparatus may include a UE), the first network entity comprising:
at least one memory (Adjakple: paragraph 0009; a memory); and
at least one processor (Adjakple: paragraph 0009; a processor) coupled with the at least one memory (Adjakple: paragraph 0009; The memory may store instructions that, when executed by the processor, cause the apparatus to perform one or more operations) and configured to cause the first network entity to:
in response to a mobility of a device indicating impending transfer from a source edge data network service area supported by the first network entity to a target edge data network service area (Adjakple: paragraph 0006; when the UE moves, the application located at the old edge network may not be suitable…paragraph 0094; Each DNN Replacement rule may consist of one or more “Original DNN”, a “Replacement DNN” and service area information where the rules may be applied…paragraph 0140; Original DNN should be replaced with Replacement DNN #2 in service area #2):
identify a first network slice associated with the source edge data network service area (Adjakple: paragraph 0144; the DNN Replacement Rules may be slice-based…the DNN Replacement Rules information element may indicate to the UE that the replacement rules only apply to certain slices. The slices may be identified by an S-NSSAI. In another alternative, the DNN Replacement Rule information element may indicate to the UE that the replacement rules only apply to certain slices…paragraph 0094; service area information where the rules may be applied);
determine a second network slice associated with the target edge data network service area (Adjakple: paragraph 0144; the DNN Replacement Rules may be slice-based…the DNN Replacement Rules information element may indicate to the UE that the replacement rules only apply to certain slices. The slices may be identified by an S-NSSAI. In another alternative, the DNN Replacement Rule information element may indicate to the UE that the replacement rules only apply to certain slices…paragraph 0094; service area information where the rules may be applied…paragraph 0140; Original DNN should be replaced with Replacement DNN #2 in service area #2); and
communicate, to the device, a slice configuration associated with the second network slice to maintain a continuity of the VAL service for the device (Adjakple: paragraph 0232; The proposed augmentation of the SF traffic influence request also provides the SMF with information about DNN replacement and application requirements for EAS relocation before the session continuity procedure is performed).
However Adjakple does not explicitly mention wherein the first network slice supports a vertical application layer (VAL) service for the device; and wherein the second network slice is capable of supporting the VAL service for the device.
However Shah teaches:
wherein the first network slice supports a vertical application layer (VAL) service for the device (Shah: paragraph 0003; network slicing for providing a dedicated network specialized to a specific service…paragraph 0008; A method performed by a vertical application layer (VAL) server in a wireless communication system…paragraph 0083; the VAL service area controller configures at least one VAL service area ID based on a VAL service area); and
wherein the second network slice is capable of supporting the VAL service for the device (Shah: paragraph 0003; network slicing for providing a dedicated network specialized to a specific service…paragraph 0008; A method performed by a vertical application layer (VAL) server in a wireless communication system…paragraph 0192; The Entity-1 provides the service enabler layer support functions for Avatar management to the VAL client(s) );
Therefore it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in Shah with the teachings as in Adjakple. The motivation for doing so would have been for providing methods and wireless networks for including Vertical Application Layer (VAL) Service Area and service enabler layer support functions for VAL client(s) (Shah: paragraphs 0001 and 0192).
However Adjakple and Shah do not explicitly mention according to a hypertext markup transfer protocol using a custom notify method.
However Sangameshwara teaches:
communicate, to the device, according to a hypertext markup transfer protocol using a custom notify method (Sangameshwara: paragraph 0024; send an HTTP response to the SNM-S upon matching the ID received in the channel ID parameter associated with the HTTP POST request with the locally stored channel ID at the SNM-C, process a VAL notification message list parameter comprising decoding at least one encoded VAL notification message received in an HTTP request entity-body of the HTTP POST request, and deliver each push notification message received from the VAL notification message list parameter to a VAL client running on a UE).
Therefore it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in Sangameshwara with the teachings as in Adjakple and Shah. The motivation for doing so would have been for providing a high-level procedure using a hypertext transport protocol (HTTP) to enable an SNM server (SNM-S) to push the notification messages to an SNM client (SNM-C) (Sangameshwara: Abstract).
As per claim 2, the modified Adjakple teaches the first network entity of claim 1, wherein: the slice configuration comprises a uniform resource locator (URL) address associated with a notify path (Sangameshwara: paragraph 0034 and fig. 7; PUSH callback-URL notification message in the SEAL notification management service during create notification channel procedure invocation…paragraph 0067; sets request URI to the PUSH callback-URL or the PUSH callback-URI), and the at least one processor is configured to cause the first network entity to: communicate with a second network entity in the target edge data network service area to determine the second network slice (Adjakple: paragraph 0232; The proposed augmentation of the SF traffic influence request also provides the SMF with information about DNN replacement and application requirements for EAS relocation before the session continuity procedure is performed).
The same motivation to combine as the independent claim applies here.
As per claim 5, the modified Adjakple teaches the first network entity of claim 1, wherein the at least one processor is configured to cause the first network entity to: communicate using a first application programming interface with a vertical application layer server that supports the vertical application layer service (API) (Shah: paragraph 0191; The registration of these mapping may be done by the VAL server (100) to the SEAL server (200) by an API call and can update these mappings by invoking these APIs with updated geographical areas…paragraph 0257; first information on a first list of at least one VAL service area ID and geographical information corresponding to the at least one VAL service area ID via an application programing interface (API) for configuring a VAL service area ID and receiving, from the location management server); and communicate with the device using a second API (Shah: paragraph 0257; second information as a response to the first information, the second information including a second list of at least one VAL service area ID via the API).
The same motivation to combine as the independent claim applies here.
As per claim 6, the modified Adjakple teaches the first network entity of claim 1, wherein the at least one processor is configured to cause the first network entity to: communicate using a first application programming interface (API), with both the device and a vertical application layer server associated with the vertical application layer service (Shah: paragraph 0035 and fig. 9; the VAL service area can be defined once, then the Service Arca information can be used at multiple application programing interface (APIs). When there is change/update in the VAL service Area, then the VAL server can just update the VAL service area at the SEAL server…paragraph 00191; The registration of these mapping may be done by the VAL server (100) to the SEAL server (200) by an API call and can update these mappings by invoking these APIs with updated geographical areas…paragraph 0207; The Entity-2 may expose the API for the consumer to create, register, modify or delete the Avatar and associated information or properties or configuration of Avatars. The consumer may be Entity-1 or MeAS or 3GPP NF (e.g. SMF, AMF, UDM, NEF, etc.,) or VAL server. In step-1, the Entity-1 or MeAS or 3GPP NF or VAL server sends request message to create or modify or delete the Avatar. In an embodiment, the request message is to manage the Avatar. The request also indicates the operation being requested to be performed by the Entity-2).
The same motivation to combine as the independent claim applies here.
As per claim 7, the modified Adjakple teaches the first network entity of claim 1, wherein the at least one processor is configured to cause the first network entity to: determine the mobility of the device indicates impending transfer from the source edge data network service area to the target edge data network service area (Adjakple: paragraph 0006; when the UE moves, the application located at the old edge network may not be suitable…paragraph 0094; Each DNN Replacement rule may consist of one or more “Original DNN”, a “Replacement DNN” and service area information where the rules may be applied…paragraph 0140; Original DNN should be replaced with Replacement DNN #2 in service area #2) based on receiving a request from a VAL server that provides the VAL service (Shah: paragraph 0207; VAL server sends request message…paragraph 0008; vertical application layer (VAL) server in a wireless communication system).
The same motivation to combine as the independent claim applies here.
With respect to claim 9, it is substantially similar to claim 1 and is rejected in the same manner, the same art and reasoning applying. Further, Adjakple also teaches a processor for wireless communication at a first network entity, the processor comprising: at least one controller coupled with at least one memory and configured to cause the processor to: (Adjakple: paragraph 0009 and figs. 9F-9G; a processor, communications circuitry, and a memory. The memory may store instructions that, when executed by the processor, cause the apparatus to perform one or more operations).
With respect to claim 10, it is substantially similar to claim 1 and is rejected in the same manner, the same art and reasoning applying. Further, Adjakple also teaches a method for wireless communication at a first network entity (Adjakple: paragraph 0303 and figs. 9F-9G; wireless communications and operations in accordance with the systems, methods, and apparatuses).
Regarding claim 11, it is substantially similar to claim 2, and is rejected in the same manner, the same arts and reasoning applying.
Regarding claims 14-15, they are substantially similar to claims 7-8, respectively, and are rejected in the same manner, the same arts and reasoning applying.
With respect to claim 16, it is substantially similar to claim 1 and is rejected in the same manner, the same art and reasoning applying. Further, Adjakple also teaches a device for wireless communication, the device comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the device to: (Adjakple: paragraph 0303; apparatus or device WTRU 102 that may be configured for wireless communications and operations in accordance with the systems, methods, and apparatuses described herein, such as a WTRU 102 of FIG. 9A, 9B, 9C, 9D, or 9E. As shown in FIG. 9F, the example WTRU 102 may include a processor 118, a transceiver 120, a transmit/receive element 122, a speaker/microphone 124, a keypad 126, a display/touchpad/indicators 128, non-removable memory 130, removable memory 132).
Regarding claim 20, it is substantially similar to claim 5, and is rejected in the same manner, the same arts and reasoning applying.
Claims 3, 12, and 17 are rejected under 35 U.S.C. 103 as being unpatentable over Adjakple et al. (U.S. Publication No. 2024/0236835) in view of Shah et al. (U.S. Publication No. 2026/0100989), in view of Sangameshwara et al. (U.S. Publication No. 2024/0380824), and further in view of Mladin et al. (U.S. Publication No. 2025/0365202).
As per claim 3, the modified Adjakple teaches the first network entity of claim 2.
However the modified Adjakple does not explicitly mention wherein: the first network entity comprises a source service enabler architecture layer network slice capability enablement (SNSCE) server in the source edge data network service area); the second network entity comprises a target SNSCE server in the target edge data network service area; and the device comprises an SNSCE client.
However Mladin teaches:
wherein: the first network entity comprises a source service enabler architecture layer network slice capability enablement (SNSCE) server in the source edge data network service area (Mladin: paragraph 0032 and fig. 9; SEAL Network Slice Capability Exposure (NSCE): In Release 18. 3GPP recognized the need for network slice capability exposure enhancements to SEAL that have yet to be realized and that enable trusted third parties to access the network slicing APIs defined and exposed by the 5G core network (CN). Aspects of the study include further exposure of network slice lifecycle management operations to trusted third party application layer enablement to support network slice management and control. Such enablement supports the network slice related operations, such as the mapping or migration of one or more vertical applications to one or more network slices); the second network entity comprises a target SNSCE server in the target edge data network service area (Mladin: paragraph 0033; The network slice capability exposure client communicates with the network slice capability exposure server over the NSCE-UU reference point. The network slice capability exposure client provides the support for network slice capability exposure functions to the VAL client(s) over the NSCE-C reference point. The VAL server(s) communicates with the network slice capability exposure server over the NSCE-S reference point); and the device comprises an SNSCE client (Mladin: paragraph 0034; NSCE client may be realized as functionality integrated within the SEAL client shown).
Therefore it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in Mladin with the teachings as in the modified Adjakple. The motivation for doing so would have been for providing functionality to coordinate network or service slices supporting a group of services (Mladin: Abstract).
Regarding claim 12, it is substantially similar to claim 3, and is rejected in the same manner, the same arts and reasoning applying.
As per claim 17, the modified Adjakple teaches the device of claim 16, wherein: the slice configuration comprises a uniform resource locator (URL) address associated with a notify path (Sangameshwara: paragraph 0034 and fig. 7; PUSH callback-URL notification message in the SEAL notification management service during create notification channel procedure invocation…paragraph 0067; sets request URI to the PUSH callback-URL or the PUSH callback-URI).
However the modified Adjakple does not explicitly mention the first network entity comprises a source service enabler architecture layer network slice capability enablement (SNSCE) server in the source edge data network service area; and the at least one memory comprises an SNSCE client; and the at least one processor is configured to cause the device to communicate, via the target edge data network service area, with a second network entity comprising a target SNSCE server in the target edge data network service area to maintain VAL service continuity subsequent to performing the transfer to the target edge data network area.
However Mladin teaches:
the first network entity comprises a source service enabler architecture layer network slice capability enablement (SNSCE) server in the source edge data network service area (Mladin: paragraph 0032 and fig. 9; SEAL Network Slice Capability Exposure (NSCE): In Release 18. 3GPP recognized the need for network slice capability exposure enhancements to SEAL that have yet to be realized and that enable trusted third parties to access the network slicing APIs defined and exposed by the 5G core network (CN). Aspects of the study include further exposure of network slice lifecycle management operations to trusted third party application layer enablement to support network slice management and control. Such enablement supports the network slice related operations, such as the mapping or migration of one or more vertical applications to one or more network slices); the at least one memory comprises an SNSCE client (Mladin: paragraph 0034; NSCE client may be realized as functionality integrated within the SEAL client shown); and the at least one processor is configured to cause the device to communicate (Mladin: paragraph 0033; The network slice capability exposure client communicates with the network slice capability exposure server over the NSCE-UU reference point…paragraph 0034; NSCE client may be realized as functionality integrated within the SEAL client), via the target edge data network service area, with a second network entity comprising a target SNSCE server (Mladin: paragraph 0033; The network slice capability exposure client communicates with the network slice capability exposure server over the NSCE-UU reference point) in the target edge data network service area (Adjakple: paragraph 0006; when the UE moves, the application located at the old edge network may not be suitable…paragraph 0140; Replacement DNN #2 in service area #2) to maintain VAL service continuity subsequent to performing the transfer to the target edge data network area (Adjakple: paragraph 0232; The proposed augmentation of the SF traffic influence request also provides the SMF with information about DNN replacement and application requirements for EAS relocation before the session continuity procedure is performed. See also Mladin: Abstract; coordinate network or service slices supporting a group of services…paragraph 0030; Vertical Application Layer (VAL) client(s) accesses the services offered by SEAL client(s) on the UE).
Therefore it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in Mladin with the teachings as in the modified Adjakple. The motivation for doing so would have been for providing functionality to coordinate network or service slices supporting a group of services (Mladin: Abstract).
Claims 4, 13, and 18-19 are rejected under 35 U.S.C. 103 as being unpatentable over Adjakple et al. (U.S. Publication No. 2024/0236835) in view of Shah et al. (U.S. Publication No. 2026/0100989), in view of Sangameshwara et al. (U.S. Publication No. 2024/0380824), and further in view of Zhu et al. (U.S. Publication No. 2024/0259857).
As per claim 4, the modified Adjakple teaches the first network entity of claim 1.
However the modified Adjakple does not explicitly mention wherein the at least one processor is configured to cause the first network entity to: receive, from the device, one of: (i) a hypertext markup transfer protocol (HTTP) 204 no content status code; or (ii) a HTTP status code respectively indicating success or failure of the device receiving the slice configuration; and record an indication of the received one of the HTTP no content status code or the HTTP status code.
However Zhu teaches:
wherein the at least one processor is configured to cause the first network entity to: receive, from the device, one of: (i) a hypertext markup transfer protocol (HTTP) 204 no content status code; or (ii) a HTTP status code respectively indicating success or failure of the device receiving the slice configuration (Zhu: paragraph 0119; the response is an HTTP response message including the status code “204 No Content” in the header of the HTTP message); and record an indication of the received one of the HTTP no content status code or the HTTP status code (Zhu: paragraph 0120 and table 6; The MTS consumer 701 uses the DELETE method to unregister from the MTS service 710. This DELETE method supports the request and response data structures, and response codes, as specified in table 6).
Therefore it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in Zhu with the teachings as in the modified Adjakple. The motivation for doing so would have been in order to provide HTTP response code handling, including status code 204 No Content and other response codes, for confirming successful or unsuccessful processing of the request (Zhu: paragraphs 0119 and 0120).
Regarding claim 13, it is substantially similar to claim 4, and is rejected in the same manner, the same arts and reasoning applying.
As per claim 18, the modified Adjakple teaches the device of claim 16.
However the modified Adjakple does not explicitly mention wherein the at least one processor is configured to cause the device to: determine whether the slice configuration is successfully received; and communicate, via the source edge data network service area to the first network entity, a hypertext markup transfer protocol (HTTP) 204 no content status code in response to determining that the slice configuration is successfully received.
However Zhu teaches:
wherein the at least one processor is configured to cause the device to: determine whether the slice configuration is successfully received; and communicate, via the source edge data network service area to the first network entity, a hypertext markup transfer protocol (HTTP) 204 no content status code in response to determining that the slice configuration is successfully received (Zhu: paragraph 0119; the response is an HTTP response message including the status code “204 No Content” in the header of the HTTP message, which indicates that the service consumer's 701 request has been successfully processed (i.e., deleting the indicated MTS session) and is not returning any content).
Therefore it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in Zhu with the teachings as in the modified Adjakple. The motivation for doing so would have been in order to provide HTTP response code handling, including status code 204 No Content and other response codes, for confirming successful or unsuccessful processing of the request (Zhu: paragraphs 0119 and 0120).
As per claim 19, the modified Adjakple teaches the device of claim 16, wherein the at least one processor is configured to cause the device to: determine whether the slice configuration is successfully received; and communicate, via the source edge data network service area to the first network entity, a hypertext markup transfer protocol (HTTP) status code indicating failure in response to determining that the slice configuration is not successfully received (Zhu: paragraph 0144; On failure or redirection (operation 2), one of the HTTP status code listed in Table 6.2.3.2.3.1-3 of [R04] is returned).
Therefore it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in Zhu with the teachings as in the modified Adjakple. The motivation for doing so would have been in order to provide HTTP response code handling, including status code 204 No Content and other response codes, for confirming successful or unsuccessful processing of the request (Zhu: paragraphs 0119 and 0120).
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Adjakple et al. (U.S. Publication No. 2024/0236835) in view of Shah et al. (U.S. Publication No. 2026/0100989), in view of Sangameshwara et al. (U.S. Publication No. 2024/0380824), and further in view of Seed et al. (U.S. Publication No. 2025/0212105).
As per claim 8, the modified Adjakple teaches the first network entity of claim 1.
However the modified Adjakple does not explicitly mention wherein the at least one processor is configured to cause the first network entity to: determine whether the first network slice supports a quality of service (QOS) requirement associated with the VAL service; and determine the mobility of the device indicates impending transfer from the source edge data network service area to the target edge data network service area based at least in part on determining that the first network slice does not support the QoS requirement associated with the VAL service.
However Seed teaches:
wherein the at least one processor is configured to cause the first network entity to: determine whether the first network slice supports a quality of service (QOS) requirement associated with the VAL service (Seed: paragraph 0018; network slice monitoring and triggering of dynamic network slice lifecycle management operations due to changes in application requirements (e.g., QoS)…paragraph 0030; The query request(s) may be used by the NSCE server to determine the types of network slices (e.g., SST values) supported by the core network and the locations in the network where these types of network slices are supported (e.g., within specific regions, domains in the network and/or within specific edge data networks). The query request(s) may also be used by the NSCE server to determine whether there are any existing network slice instances (NSIs) already allocated which meet the minimum required service or QoE KPIs of the VAL client(s) on the specified UE(s)); and
determine the mobility of the device indicates impending transfer from the source edge data network service area to the target edge data network service area based at least in part on determining that the first network slice does not support the QoS requirement associated with the VAL service (Seed: paragraph 0049; obtaining authorization for the VAL client(s) on the UE(s) to access the VAL server(s) via the network slice instances, where obtaining authorization comprises one or more of the following operations: sending an authorization request to a service in the network (e.g., AS, EAS, authorization service) to obtain an authorization approval for the VAL client(s), querying entities in the system (e.g., OAM service) to determine whether network slice instances exist which already meet the minimum required service or QoE KPIs of the VAL client(s) on the specified UE(s) and whether these network slices have availability to the UE(s) at the required scheduled time(s), location(s) and/or routes, if adequate network slice instance(s) do not exist, then triggering the allocation of a new or modification of an existing network slice instance that comprises adequate network resources to meet the minimum required service or QoE KPIs of the VAL client(s) on the specified UE(s) and that have availability to the UE(s) at the required scheduled time(s), location(s) and/or routes, obtaining authorization for the VAL client(s) on the UE(s) to access the network slice instances. Adjakple: paragraph 0006; when the UE moves, the application located at the old edge network may not be suitable…paragraph 0094; Each DNN Replacement rule may consist of one or more “Original DNN”, a “Replacement DNN” and service area information where the rules may be applied…paragraph 0140; Original DNN should be replaced with Replacement DNN #2 in service area #2).
Therefore it would have been obvious for one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teachings as in Seed with the teachings as in the modified Adjakple. The motivation for doing so would have for providing network slice monitoring and triggering of dynamic network slice lifecycle management operations due to changes in application requirements (e.g., QoS) or a network slice status change (Seed: paragraphs 0018).
REMARKS
Applicant submitted arguments to overturn the rejection on 07/28/2026. The examiner maintains the rejections, see remarks below.
The applicant Argues:
Applicant argues at Remarks, pages 9-10 that Adjakple does not teach two slices.
Fig. 1 shows a vehicle in Location A that is serviced by a first edge application server under DNN1 travelling to a second Location B that is serviced by a second edge application server under DNN2. Paragraph 0094 states a DNN replacement rule takes effect in a particular service area. Paragraph 0139 describes that DNN replacement rules are rules that replace an original DNN with a replacement DNN “when the UE is in the service area that is indicated by the rule.” Thus, Adjakple discloses a first DNN associated with a source edge data network service area (e.g., Location A serviced by EAS1) and a second DNN associated with a target edge data network service area (e.g., Location B serviced by EAS2). The transfer of DNN1 to DNN2 is performed by “replac[ing] the original DNNs with the Replacement DNN when the UE is in the service area that is indicated by the rule.” In other words, moving to Location B triggers the Original DNN to become the Replacement DNN and turns DNN1 into DNN2.
The DNN Replacement rules are sliced based, see paragraph 0144. This means that, taking Fig. 1 as an example, the vehicle moving from Location A triggers a DNN replacement, and it may land on DNN2 and a first slice, or it may land on a DNN3 and a second slice. Applicant reads this as “the slice is held constant while the DNN varies” but that is incorrect. UEs have multiple allowable slices. Paragraph 0144 states slices are identified by S-NSSAI and paragraph 0158 that when pushing replacement rules the AMF may consider the slices in the UE’s Allowed NSSAI when determining what rules to send to the UE, i.e. one reason the vehicle may jump to DNN2 rather than DNN3 (apply a first replacement ruleset rather than a second replacement ruleset) is because DNN2 are rules for slices that the UE in the vehicle may jump to (allowed NSSAI) while DNN3 are rules for slices that are not allowed for the UE. If the UE was staying on a single slice the AMF would have no reason to consider the slices (plural) in the UE’s Allowed list in determining what replacement rules to send. Thus, moving from Location A to Location B triggers a rules analysis that is both a function of service area (paragraph 0094) and slice (paragraph 0144).
Applicant further argues at page 10 that the same citation cannot be cited to both a first and second slice/service area, but there is no incongruity because the cited language is talking about a change (replacement) in slice-based rules due to moving to another service area. Further the citations are in the context of examiner already having cited paragraphs 0006 and 0140. Paragraph 0006 discusses the UE moving and the “old edge network” and paragraph 0140 discusses service areas #1/#2.
At Remarks, pages 10-11, Applicant argues Shah does not teach slices supporting VAL Services. But, as above, Adjakple already taught multiple slices and Applicant appears to admit or at least not dispute that Shah discloses VAL services in 5G which, as a standard, performs network slicing “for providing a dedicated network specialized to a specific service.” This suggests network slices with VAL services. Applicant appears to want an anticipatory paragraph that explicitly discusses VAL slices, but the reference is clear that VAL works in 5G/6G systems which support network slicing, which suggests slices with VAL functionality. Similarly, at Remarks, pages 11-12 Applicant states that “one skilled in the art will appreciate that Shah’s VAL service area is a geographic identifier, not a network slice.” But Adjakple already related moving geographic location to different DNNs which suggests different network slices as discussed above. In other words, Adjakple already taught moving locations causing a change in service area and therefore network slice, such as moving to EAS2 from EAS1, and Shah adds VAL service areas, i.e. the EAS have VAL services.
Applicant argues at page 12 that “A VAL service area, as provided in Shah, identifies where something is. A network slice, in contrast, identifies a logical partition of network resources. The two concepts are very different in kind, and one skilled in the art would not confuse or equate the two with the other.” Examiner agrees that the two are very different in kind, but Applicant proceeds as if “edge” resources express no relationship between physical location and logical service areas. A person of skill would not understand that to be the case. The reason “edge” resources exist is to present logical resources that service geographic areas for, among other reasons, latency and capacity reasons. A given RAN supports a certain amount of bandwidth over a certain amount of physical distance. That RAN has logical connections to data centers whose latency in communications is a function, in part, of physical distance. A person of ordinary skill would have recognized that the reason Adjakple Fig. 1 does not disclose a single central network with a plurality of servers and rather shows two edge networks with different servers that have connections to different locations is because EAS1 cannot service Location B as efficiently as EAS2 can by nature of the geographic location of Location B. Similarly, if Location A is a highly trafficked or populus location while Location B is not, that logically commends to what resources are made available to define the capacity of the edge networks. Consequently, the logical resources afforded by EAS2 commend themselves to a geographic service area in a way that the logical resources of EAS1 do not. The geographic and logical groupings were indeed understood to be very different in kind, but they were also understood to be related.
At Remarks, pages 12-13, Applicant argues that Adjakple does not convey slice configuration to the device. As above, DNN replacement is slice based, and the cited paragraph 0232 deals with session continuity when UE mobility causes a relocation of the EAS, i.e. travelling from Location A to Location B requires EAS1 to hand off to EAS2. But, as previously detailed, communicating with EAS2 is a function of applying replacement rules DNN2, which is a slice-based distinction. Session continuity over a slice transition suggests a slice configuration associated with the second network slice.
At Remarks, page 13, Applicant argues Sangameshwara does not teach a custom notify method. Applicant’s arguments confirm a custom notify method. Applicant describes Sangameshwara’s disclosure as “the standard SEAL push-notification mechanism, carried over an ordinary HTTP POST.” Examiner questions whether “a push-notification carried over a HTTP POST” is a communication using a standard notify method, but even if it is Applicant then faults the Sangameshwara payload as “carr[ying] a list of notification messages, not a slice configuration[]” and therefore failing to teach. But Applicant improperly piecemeal attacks the rejection. Adjakple suggests slice configuration in preserving the session continuity as above, and the combination with Sangameshwara’s disclosure creates a custom notify method for at least the reason that it modifies the Sangameshwara notification, which Applicant asserts is standard. To the extent that Applicant feels the modification is not sufficiently customized, or posits some other type of customization, examiner notes that the claim defines no particular standard for customization and the broadest reasonable interpretation of “custom” is anything except the standard. Applicant presents (1) no evidence that shows what a communication of a slice configuration using a hypertext markup transfer protocol standard notify method is and (2) no argument as to why the proposed combination of teachings is not “custom” compared to that.
At Remarks, pages 13-14, Applicant argues that Examiner uses hindsight reasoning and characterizes the changes are a complex series of modifications. But Adjakple preserves sessions between service areas even if those sessions involve slice transfers, so the main distinction between Adjakple and the claims is that the particular session one is seeking to continue is VAL services. This application does not purport to have invented VAL services, and Applicant advances no reasoning (let alone evidence) that VAL services were disfavored, or some other reason that a person of ordinary skill who sought to continue sessions wouldn’t be motivated to continue known VAL services as opposed to any other service. With respect to the actual continuation of services, Claim 1 provides no limiting details for executing continuity of the VAL service other than “a slice configuration associated with the second network slice” is communicated in a “custom” manner. Examiner disagrees that this is a complex modification or that the instant disclosure is needed as a roadmap to generate this solution.
Examiner maintains the obviousness rejection to all claims.
Conclusion
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KARINA J. GARCIA-CHING whose telephone number is (571)270-7159. The examiner can normally be reached Monday - Wednesday (9:00 AM - 5:00 PM).
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, Vivek Srivastava can be reached at (571) 272-7304. 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.
/KARINA J GARCIA-CHING/Examiner, Art Unit 2449
/VIVEK SRIVASTAVA/Supervisory Patent Examiner, Art Unit 2449
