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 Arguments
Applicant's arguments, filed 6/17/26, with respect to the rejection of the claims under 35 U.S.C. 102(a)(2) have been fully considered but they are not persuasive.
Applicant argued:
TS 23.434 outlines general models for identities, group management (Chapter 10), and various information flows, but it does not describe or illustrate a single network entity that receives a network slice configuration request containing the exact claimed combination of an application identifier, a route selection identifier that includes one or more route selection descriptors, and a group identifier, and that then responds by triggering network slice configuration specifically for each user device in the identified group while messaging a core network entity to adapt the route selection descriptors for the vertical application. The pages cited in the Office Action address these concepts in isolation or in different procedural contexts; they do not show the elements combined and arranged in the manner required by claim 1 such as triggering network slice configuration specifically for each user device in the identified group while messaging a core network entity to adapt the route selection descriptors for the vertical application.
The Examiner respectfully disagrees and submits that when reading the preamble in the context of the entire claim, the recitation “a single network entity” is not limiting because the body of the claim describes a complete invention and the language recited solely in the preamble does not provide any distinct definition of any of the claimed invention’s limitations. Thus, the preamble of the claim(s) is not considered a limitation and is of no significance to claim construction. See Pitney Bowes, Inc. v. Hewlett-Packard Co., 182 F.3d 1298, 1305, 51 USPQ2d 1161, 1165 (Fed. Cir. 1999). See MPEP § 2111.02. Therefore, any system performing the recited claim steps can read on the claimed limitations.
Although TS 23.434 shows the claimed limitations in different sections, it still teaches the elements combined and arranged in the manner required by claim 1. The entirety of TS 23.434 and the cited sections relate to network slice capabilities in a Vertical Application Layer (VAL). Thus TS 23.434 expressly discloses each claimed limitation. Although the disclosures appear in different sections, they describe the same embodiment and would be understood by a person of ordinary skill in the art as operating together.
Applicant further argued:
Moreover, the reference's treatment of route selection descriptors (often discussed in the context of general URSP or PDU session establishment flows) and group identifiers (discussed in the context of VAL group creation, membership, and configuration management) occurs in separate sections without the specific linkage through a unified "network slice configuration request" that drives both the per-device triggering within the group and the subsequent adaptation of those descriptors for the vertical application. The Office Action's reliance on pages 174-176 and 172-181 for the adaptation and messaging steps, for example, does not demonstrate that TS 23.434 teaches messaging a core network entity specifically to adapt route selection descriptors in response to the claimed request format that also carries the group identifier and triggers group- wide per-device configuration. Because anticipation requires that every limitation appear in the reference arranged as in the claim, and because the Examiner has not identified any disclosure in TS 23.434 of this integrated request, trigger, and adapt sequence performed by one network entity, the reference does not anticipate claim 1.
The Examiner submits that although the reference's treatment of route selection descriptors (often discussed in the context of general URSP or PDU session establishment flows) and group identifiers (discussed in the context of VAL group creation, membership, and configuration management) occurs in separate sections, TS 23.434 does indeed message a core network entity specifically to adapt route selection descriptors in response to the claimed request format that carries the group identifier and triggers group-wide per-device configuration. For instance, pages 172 and 173 of TS 23.434 state:
The network slice capability enablement is a SEAL service that offers network slice capability enablement capabilities, such as support for vertical application to slice re-mapping (which can be defined as the mapping of the UEs running a vertical application to different slice), to one or more vertical applications. In particular, network slice capability enablement uses a network-based mechanism to apply the slice re-mapping based on the network slice capability enablement server configuration, where the network slice capability enablement server acting as AF influences the URSP rules for the application traffic per UE by providing a guidance on the route selection parameters (including the S-NSSAI and DNN mapping). (Emphasis added).
The network slice capability enablement client communicates with the network slice capability enablement server over the NSCE-UU reference point. The network slice capability enablement client provides the support for network slice capability enablement functions to the VAL client(s) over NSCE-C reference point. The VAL server(s) communicates with the network slice capability enablement server over the NSCE-S reference point. It is assumed that the network slice capability enablement server is deployed at the 5G system domain. The network slice capability enablement
server, acting as AF, may communicate with the 5G Core Network functions via NEF (N33) reference point (for interactions with PCF). (Emphasis added).
Thus, it is evident that TS 23.434 does indeed provide a unified "network slice configuration request" that drives both the per-device triggering within the group and the subsequent adaptation of those descriptors for the vertical applications since the cited sections and the entirety of TS 23.434 for that matter relates to supporting network slice capability enablement functions to VAL clients.
Furthermore, the cited to page 181 of TS 23.434 states, “The Constrained Application Protocol (CoAP) is a light-weight protocol defined by IETF in RFC 7252 [32] and designed specifically for application layer communication for constrained devices. CoAP provides a request/response interaction model between application endpoints, supports built-in discovery of services and resources, and includes key concepts of the Web such as URIs and Internet media types.” (Emphasis added). Hence, the Examiner has clearly identified the disclosures in TS 23.434 of the integrated request, trigger, and adapt sequence performed by a system since the claim does not require a single network entity performing the claimed steps as shown above.
Applicant also argued:
Claim 2 requires that the network entity message a policy control function (PCF) node specifically to adapt the route selection descriptors; while the Office Action points to page 119 for PCF interactions, that page addresses general PCF functionality within the broader architecture and does not disclose the PCF messaging step occurring as part of the precise sequence triggered by the claimed network slice configuration request that includes the route selection identifier and group identifier.
The Examiner submits that since page 120 states, “Upon request from a VAL server via the NRM-S reference point it configures the TSC end-to-end QoS flows in the SGS. In line with other SEAL service enablers the SEAL NRM server provides a RESTful interface on the NRM-S reference point. As a TSCTSF the SEAL NRM server interacts with the SGS PCF over the Nxx reference point to configure the 5G QoS and TSCAI parameters in the SGS,” TS 23.434 discloses the PCF messaging step occurring as part of the precise sequence triggered by the claimed network slice configuration request that includes the route selection identifier and group identifier.
Applicant moreover argued:
Claim 3 requires that the message to adapt the route selection descriptors include a command to update one or more route selection policies for the vertical application when establishing a protocol data unit (PDU) session; page 92 of the reference discusses PDU sessions at a general level but does not teach this specific command in the context of the request-driven adaptation flow of claim 1.
The Examiner submits that since page 92 states, “The VAL server configures VAL group for Uu communication defined by VAL Group ID for one or more VAL services with list of VAL Service ID with the group management server,” TS 23.434 teaches this specific command in the context of the request-driven adaptation flow of claim 1.
Applicant also argued:
Claims 4 and 5 specify that the network slice configuration request is received from a vertical application layer (VAL) client or VAL server; although pages 25 and 28 describe VAL entities, they do not show receipt of a request containing the claimed route selection identifier (with descriptors) and group identifier that then causes the network entity to perform the full triggering and adaptation sequence.
The Examiner submits that since page 28 states, “Supports authentication for identities provided within SIP signaling. Both the registrar (with integral location server) and authentication functions are supported by access either to the public network's own SIP database or the VAL service provider's SIP database,” TS 23.434 shows receipt of a request containing the claimed route selection identifier (with descriptors) and group identifier that then causes the network entity to perform the full triggering and adaptation sequence.
Applicant further argued:
Claims 6 through 9 recite that the network slice configuration request is part of a constrained application protocol (CoAP) or hypertext transfer protocol (HTTP) message
constructed with an application programming interface (API) uniform resource identifier (URI) or request URI that includes specific values or fields, such as a value identifying the vertical application together with a value identifying a configuration (or slice configuration) that defines the route selection descriptors and group identifier, or fields such as a configuration identifier, group identifier, network route selection, and configuration cause. The Office Action cites pages 60-61, 181, 29-30, and 32-33 for these message formats, yet those pages provide general examples of APIs, URIs, or information flows within the SEAL architecture. They do not disclose the use of these exact message structures or field combinations for a network slice configuration request that carries the route selection identifier containing descriptors and that drives the claimed per-device triggering within the group followed by adaptation of the descriptors.
The Examiner submits that since page 30 states, “LWP is a representation of a protocol to be used by the SEAL service enablers on their respective SEAL-UU reference points when the SEAL client is executing in a constrained UE. In this case the SEAL client should use the LWP-1 reference point with the LWP proxy and should use either the LWP-2 or the LWP-HTTP-2 reference point for transport and routing of the related signaling with the SEAL server,” TS 23.434 discloses the use of these exact message structures and field combinations for a network slice configuration request that carries the route selection identifier containing descriptors and that drives the claimed per-device triggering within the group followed by adaptation of the descriptors.
Applicant also argued:
Claim 10 requires transmission of a network slice configuration response that includes information confirming the adaptation of the route selection descriptors; page 174 addresses responses in a general sense but does not teach a confirming response tied to adaptation of the descriptors in the manner claimed.
The Examiner submits that since page 176 states, “The NSCE server acting as AF provides the updated S-NSSAI and DNN per VALUE. In particular. NSCE server sends this information to the PCF via NEF as part of the AF-driven guidance for URSP determination to 50 system (as specified in TS23.502 clause 4.15.6.10, TS 23.503 clause 6.6.2.2, TS 23.548 clause 6.2.4). This guidance may update the route selection parameters to indicate different sets of POU Session information (DNN, S-NSSAI) that can be associated with applications matching the application traffic,” TS 23.434 teaches a confirming response tied to adaptation of the descriptors in the manner claimed.
Applicant moreover argued:
Claim 11 requires that the route selection descriptors include single network slice selection assistance information (S-NSSAI) and data network name (DNN) information; while pages 172- 173 discuss these elements in the context of slicing, they do not do so as part of the integrated request and adaptation flow recited in claim 1.
As explained above, the cited sections and the entirety of TS 23.434 relates to supporting network slice capability enablement functions to VAL clients. Thus the (S-NSSAI) and the data network name (DNN) information discussed in pages 172-173 are a part of the integrated request and adaptation flow recited in claim 1.
The Examiner respectfully reminds applicant of the broadest reasonable interpretation standard (See MPEP 2111), "During examination, the claims must be interpreted as broadly as their terms reasonably allow." In re American Academy of Science Tech Center, 367 F.3d 1359, 1369, 70 USPQ2d 1827, 1834 (Fed. Cir. 2004) (The USPTO uses a different standard for construing claims than that used by district courts; during examination the USPTO must give claims their broadest reasonable interpretation.) In Phillips v. AWH Corp., 415 F.3d 1303, 75 USPQ2d 1321 (Fed. Cir. 2005), the court further elaborated on the “broadest reasonable interpretation" standard and recognized that “The Patent and Trademark Office (“PTO") determines the scope of claims in patent applications not solely on the basis of the claim language, but upon giving claims their broadest reasonable construction." Thus, when interpreting claims, the courts have held that Examiners should (1) interpret claim terms as broadly as their terms reasonably allows and (2) interpret claim phrases as broadly as their construction reasonably allows. In conclusion, upon taking the broadest reasonable interpretation of the claims, the cited reference teaches all of the claimed limitations and the rejections are maintained as below.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim(s) 1-11 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by "Service Enabler Architecture Layer for Verticals (SEAL); Functional architecture and information flows; (Release 17)", 3GPP STANDARD; TECHNICAL SPECIFICATION; 3GPP TS 23.434; no. V17.5.0 23 March 2022; XP052144755, hereinafter referred to as “3GPP”.
As per claim 1, 3GPP teaches a network entity for wireless communication, comprising: at least one memory; and at least one processor coupled with the at least one memory and configured to cause the network entity to: receive a network slice configuration request for a vertical application, wherein the network slice configuration request includes:
an identifier of the vertical application;
an identifier of a network route selection that includes one or more route selection descriptors of a network route for the vertical application [pages 174-176]; and
a group identifier for a group of one or more user devices associated with the vertical application [pages 69-72];
trigger a network slice configuration for each user device of the group of one or more user devices associated with the vertical application [pages 49-51]; and
message a core network entity to adapt the route selection descriptors for the vertical application [pages 172 and 181].
As per claim 2, 3GPP teaches the network entity of claim 1, wherein the at least processor is further configured to cause the network entity to: message a policy control function (PCF) node of a wireless communications system to adapt the route selection descriptors for the vertical application [pages 119-120].
As per claim 3, 3GPP teaches the network entity of claim 1, wherein the message to adapt the route selection descriptors for the vertical application includes a command to update one or more route selection policies for the vertical application when establishing a protocol data unit (PDU) session for the vertical application [page 92].
As per claim 4, 3GPP teaches the network entity of claim 1, wherein the network slice configuration request for the vertical application is received from a vertical application layer (VAL) client contained by one or more user devices associated with the vertical application [page 25].
As per claim 5, 3GPP teaches the network entity of claim 1, wherein the network slice configuration request for the vertical application is received from a vertical application layer (VAL) server that communicates with VAL clients contained by one or more user devices associated with the vertical application [page 28].
As per claim 6, 3GPP-Sternberg teaches the network entity of claim 1, wherein the network slice configuration request is part of a constrained application protocol (CoAP) message constructed by an application programming interface (API) uniform resource identifier (URI) that includes: a value identifying the vertical application; and a value identifying a configuration that defines the one or route selection descriptors of the network route for the vertical application and the group identifier for the group of one or more user devices associated with the vertical application [pages 60-61 and 181].
As per claim 7, 3GPP-Sternberg teaches the network entity of claim 1, wherein the network slice configuration request is part of a constrained application protocol (CoAP) message constructed by an application programming interface (API) uniform resource identifier (URI) includes: a value identifying the vertical application; and a value identifying a slice configuration that defines the one or route selection descriptors of the network route for the vertical application and the group identifier for the group of one or more user devices associated with the vertical application [pages 60-61 and 181].
As per claim 8, 3GPP teaches the network entity of claim 1, wherein the network slice configuration request is part of a hypertext transfer protocol (HTTP) message that includes: a request uniform resource identifier (URI) that identifies an entity of the vertical application; a configuration identifier that identifies a configuration identity; a group identify that identifies the group of one or more user devices; a network route selection that includes the one or more route selection descriptors; and a configuration cause that identifies a cause of a configuration represented by the configuration identity [pages 29-30].
As per claim 9, 3GPP teaches the network entity of claim 1, wherein the network slice configuration request is part of a hypertext transfer protocol (HTTP) message that includes: a request uniform resource identifier (URI) that identifies an entity of the vertical application; a slice configuration identifier that identifies a configuration identity for a network slice associated with the vertical application; a group identify that identifies the group of one or more user devices; a network route selection that includes the one or more route selection descriptors; and a configuration cause that identifies a cause of a configuration represented by the configuration identity [pages 32-33].
As per claim 10, 3GPP teaches the network entity of claim 1, wherein the at least one processor is further configured to cause the network entity to: transmit a network slice configuration response that includes information confirming the adaptation of the route selection descriptors for the vertical application [pages 174-176].
As per claim 11, 3GPP teaches the network entity of claim 1, wherein the one or more route selection descriptors of the network route for the vertical application include single network slice selection assistance information (S-NSSAI) and data network name (DNN) information [pages 172-173].
There are prior art made of record not relied upon but is considered pertinent to applicant's disclosure. See attached.
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 extension fee 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 RANODHI N SERRAO whose telephone number is (571)272-7967. The examiner can normally be reached Monday to Friday 8:00 am to 4: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, John Follansbee can be reached on (571) 272-3964. 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.
Ranodhi N. Serrao
/RANODHI SERRAO/Primary Examiner, Art Unit 2444
Prosecution Insights