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 .
Claim status in the amendment received on 11/24/2025:
Claims 1, 16, 31, 48-49, 52-54, 57-60, 63-65, 68-71, 74-76 and 79-80 have been amended.
Claims 55-56, 66-67 and 77-78 have been canceled.
Claims 1, 16, 31, 48-49, 52-54, 57-60, 63-65, 68-71, 74-76 and 79-80 are pending.
Response to Arguments
The amended claims are addressed in the rejections below.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1, 16, 31, 48-49, 52-54, 57-60, 63-65, 68-71, 74-76 and 79-80 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
As to claims 1, 16 and 31,
The claims recite the limitation “…a timer identifier that identifies the timer created in the timers store in response to the receiving the request”, in the storing step. However, it is not clear what it is that is “created in the timers store in response to the receiving the request”, the timer or the timer identifier. Appropriate correction is required.
The phrases "in an instance" render the claim indefinite because it is unclear whether the limitation(s) following the phrases are part of the claimed invention. See MPEP § 2173.05(d).
There is insufficient antecedent basis for the limitation “the PUT request”, in the last line . “PUT request” recited in the optional step is not sufficient unless the optional step is explicitly claimed.
As to the claim(s) that are dependent on claim(s) 1, 16 or 31, the dependent claim(s) are also rejected under 112(b) for the same reason of their base claim(s).
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, 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.
Claims 1, 16, 31, 48-49, 52-54, 57-60, 63-65, 68-71, 74-76 and 79-80 is/are rejected under 35 U.S.C. 103 as being unpatentable over Patil (US 20200187290) et al. hereinafter Patil in view of 3GPP TS 29.598 v17.0.0. “3rd Generation Partnership Project: Technical Specification Group Core Network and Terminals; 5G System; Unstructured Data Storage Service Stage 3” hereinafter 3GPP.
Regarding claim 1, Patil teaches an apparatus comprising:
at least one processor; and
at least one memory comprising computer codes of an unstructured data storage function (UDSF) stored therein, wherein the computer code, when executed by the at least one processor, causes the apparatus to perform at least: receiving, from a stateless network function consumer or state efficient network function consumer, via an UDSF interface configured to provide access to a timer service of the UDSF, a request to create a timer to be handled by the USDF as a timer resource (see at least [0012]: An AMF instance (i.e. the stateless network function consumer as disclosed in [0015] in Patil) handles UE procedures and typically needs to create and maintain context/state for the UE (i.e. creating a timer). When a UE registers with the network, the AMF instance handling the UE's request creates a UE context (i.e. request to create a timer, e.g. UE context and state maintenance parameters = timer information as taught in Patil – [0014, 15]); see also [0014]: The service that the UDSF provides allows network function instances to store, retrieve, update and delete contexts (i.e. enabling access to a timer service provided by the UDSF). However, in many cases, the UE context tends to be associated with one or more timers. For example, an AMF is required to run timers to monitor re-registration of the UE; see also [0068]: AMF instance 220-1 may include the state maintenance parameters in a unified data management message (e.g., Nudsf_UDM_Create message 535) that AMF instance 220-1 sends to UDSF 230 (e.g., via a Nudsf interface) (i.e. receiving a request via the UDSF interface));
in response to the receiving the request from the stateless network function consumer or the state efficient network function consumer, creating the timer in a timers store, the timer having an expiration time (see [0046]: In the example of FIG. 5, AMF instance 220-1 may handle a registration procedure for UE 180 and create context for UE 180 in UDSF 230 (i.e. creating the timer in a timers store). Two timers used by AMF instance 220-1 in relation to the registration process include a re-registration timer and a purge timer; see also [0068]: AMF instance 220-1 may include the state maintenance parameters in a unified data management message (e.g., Nudsf_UDM_Create message 535) that AMF instance 220-1 sends to UDSF 230 (e.g., via a Nudsf interface). Upon receiving Nudsf_UDM_Create message 535 with the state maintenance parameters, UDSF 230 may run 540 the designated timers. For example, UDSF 230 may start the timers identified in the array of timers (e.g., the “Rereg timer” and the “Purge timer”) from the state maintenance parameters);
storing information regarding the timer (see [0012] and [0014]: According to implementations described herein, after an AMF instance completes a procedure for the UE, the AMF instance may store UE context in an Unstructured Data Storage Function (UDSF) … wherein the UE context tends to be associated with one or more timers; see also [0081]: Process 800 may also include receiving the UE context and state maintenance parameters (block 810), and storing the UE context and state maintenance parameters (block 815). For example, UDSF 230 may receive a unified data management message (e.g., Nudsf_UDM Create message 535) from AMF instance 220. The unified data management message may include the UE context and the state maintenance parameters for UE 180 (i.e. the timer that is created in timers store). UDSF 230 may store the UE context and the state maintenance parameters associated with a unique identifier (i.e. storing information regarding the timer)), wherein the information regarding the timer comprises a timer identifier that identifies the timer created in the timers store in response to the receiving the request (see at least [0025]: The state maintenance parameters may include, for example, settings for an array of timers to be run on the context … Settings for each timer may include, for example, a timer ID, a timer value, …; see also [0082]: monitor the different timers for expiration);
in an instance in which a PATCH request is received that comprises the timer identifier for the timer to be handled by the UDSF as a timer resource, modifying the timer based on the PATCH request;
in an instance in which a PUT request is received that comprises the timer identifier associated with the timer created to be handled by the UDSF as a timer resource, starting the timer; and
in an instance in which a DELETE request is received that comprises the timer identifier associated with the timer created to be handled by the UDSF as a timer resource, stopping the timer; or
upon expiration of the timer at the end of the expiration time associated with the timer, sending to the stateless network function consumer or the state efficient network function consumer, via the UDSF interface, a POST request indicating that the timer associated with the PUT request has expired (see [0040]: The state maintenance parameters may include … an action to be performed upon expiry of the timer values (e.g., notify AMF set 225); see also [0075]: In response to detecting the timer expiration, UDSF 230 may refer to state maintenance parameters to generate a Nudsf_UDM_Notify message 710 (i.e. notify via the UDSF interface) for AMF set 225. Nudsf_UDM_Notify message 710 may include an identifier (id) for the particular UE and/or data, context (e.g., still active, pending the grace period), and an expiration indication for a particular timer (e.g., “Rereg timer”); Patil further teaches in [0084] that changes to Unstructured Data Management service operations may be made via a Nudsf interface (i.e. the UDSF interface)).
However, the Patil reference does not explicitly teach an apparatus wherein the request is received via an UDSF application programming interface (API).
In the same field of endeavor, 3GPP teaches a system in accordance with the present invention, the system comprising a data model for the Nudsf Service based interface, wherein the system executes services offered by the UDSF via a UDSF Application Programming Interface (API) (see Page 11 section 5.1 and Table 5.1-1: The UDSF offers the following services via the Nudsf service based interface: -Nudsf_DataRepository Service wherein Table 5.1-1 summarizes the corresponding APIs defined for this specification; see also Page 27, section 6.1.1. lines 4-6: The request URI used in HTTP requests from the NF service consumer towards the NF service producer shall have the Resource URI structure defined in clause 4.4.1 of 3GPP TS 29.501 [5], i.e.: {apiRoot}/<apiName>/<apiVersion>/<apiSpecificResourceUriPart>).
Accordingly, it would have been obvious for one of ordinary skill in the art before the effective filing date of the present invention, to incorporate the Nudsf API interface of 3GPP into the system taught by Patil such that instructions may be received and performed at the UDSF via an USDF API in order to arrive at the claimed invention. The motivation for such combination would have been to enable a set of software applications to communicate with one another using a set of protocols established by the system architecture and specificizing a particular API for rendering service offered by the UDSF.
Regarding claim 16, the claim limitations are substantially similar to claim 1. Please refer to claim 1 above.
Regarding claim 31, the claim limitations are substantially similar to claim 1. Please refer to claim 1 above.
Regarding claim 48, Patil in view of 3GPP is applied as disclosed in claim 1 examined above including utilizing UDSF API. The combination of Patil and 3GPP teaches a system comprising at least one processor causing the system to receive, from a stateless network function consumer or state efficient network function consumer, via an UDSF interface configured to enable access to a timer service provided by the UDSF, a request to create a timer. Furthermore, Patil teaches sending, to the stateless network function consumer or the state efficient network function consumer, via the UDSF interface, a response to the request to create the timer, the response indicating that the timer has been created in the timers store (see [0041]: Action manager 420 may also respond to queries from AMF set 225 to provide state information for a UE 180; see also [0071]: In response to receiving Nudsf_UDM_Query message 620, UDSF 230 may provide stored context information 625 for UE 180 to AMF instance 220-2; see also 3GPP – Page 47, Table 6.1.3.9.3.2-3: Data structures supported by the PUT Response Body on this resource: Response code – “201 Created” indicating successful creation of a schema is returned).
Regarding claim 49, Patil in view of 3GPP is applied as disclosed in claim 1 above. The combination of Patil and 3GPP teaches a system comprising at least one processor causing the system to receive, from a stateless network function consumer or state efficient network function consumer, via an UDSF interface configured to enable access to a timer service provided by the UDSF, a request to create a timer. Additionally, Patil teaches storing, in the timers store in the UDSF, an autonomous timer in the timers store (see [0040]: Context database 410 may receive and store context information and state maintenance parameters for UE 180 from AMF set 225 (e.g., one of AMF instances 220). The state maintenance parameters may include, for example, one or more timer values associated with UE 180).
Regarding claim 52, Patil in view of 3GPP is applied as disclosed in claim 1 as examined above including utilizing the USDF API. The combination of Patil and 3GPP teaches a system comprising at least one processor causing the system to receive, from a stateless network function consumer or state efficient network function consumer, via an UDSF interface configured to enable access to a timer service provided by the UDSF, a request to create a timer. Furthermore, 3GPP teaches : receiving, via the USDF API, a timer resource structure via the UDSF API (see Page 27 section 6.1.1, paragraph 4-11: The Nudsf_DataRepository service shall use the Nudsf_DataRepository API. The API URI of the Nudsf_DataRepository API shall be: {apiRoot}/<apiName>/<apiVersion>/. The request URI used in HTTP requests from the NF service consumer towards the NF service producer shall have the Resource URI structure defined in clause 4.4.1 of 3GPP TS 29.501 [5], i.e.: {apiRoot}/<apiName>/<apiVersion>/<apiSpecificResourceUriPart>)).
Regarding claim 53, Patil in view of 3GPP is applied as disclosed in claim 1 as examined above. The combination of Patil and 3GPP teaches a system comprising at least one processor causing the system to receive, from a stateless network function consumer or state efficient network function consumer, via an UDSF interface configured to enable access to a timer service provided by the UDSF, a request to create a timer. Furthermore, 3GPP teaches wherein the request comprises a filter query parameter, wherein the computer codes stored in the at least one memory, when executed by the at least one processor, further cause the apparatus to perform: searching, in the timers store of the UDSF, based on the filter query parameter provided by the stateless network function consumer or the state efficient network function consumer, for one or more timers that satisfy the filter query parameter provided by the stateless network function consumer or the state efficient network function consumer (see Page 12 section 5.2.2.2. and Fig. 5.2.2.2.2-1: Figure 5.2.2.2.2-1 shows a scenario where the NF service consumer sends a request to the UDSF to retrieve a record that matches the provided recordId and optionally includes the query parameter supported-features; see also Page 14 section 5.2.2.2.6: 1. The NF service consumer (any NF) sends a GET request to the Records resource with the filter query parameter indicating the search criteria, 2a. On success, the UDSF responds with "200 OK" with the message body containing the RecordSearchResult.).
Regarding claim 54, Patil in view of 3GPP is applied as disclosed in claim 1 as examined above. The combination of Patil and 3GPP teaches a system comprising at least one processor causing the system to receive a request to create a timer. Additionally, Patil teaches a system wherein the request comprises at least one of the timer identifier for the timer (see [0025]: The state maintenance parameters may include, for example, settings for an array of timers to be run on the context, an array of applicable context states, and/or access controls on the context. Settings for each timer may include, for example, a timer ID; see also [0048]: Identity: Rereg Timer”).
Regarding claim 57, Patil in view of 3GPP is applied as disclosed in claim 1 examined above. The Patil-3GPP further teaches a system wherein the computer code, when executed by the at least one processor, further causes the apparatus to monitor the timer (Patil – see [0082]: For example, UDSF 230 may start an array of timers (e.g., the “Rereg timer” and the “Purge timer”) from the state maintenance parameters and monitor the different timers for expiration).
Regarding claim 58, Patil in view of 3GPP is applied as disclosed in claim 1 examined above. The combination of Patil and 3GPP teaches a system comprising storing, in the UDSF, information regarding the timers that is stored and handled in the UDSF as a resource. Furthermore, 3GPP teaches wherein the information regarding the timer that is stored in the timers store and handled by the UDSF comprises at least one of: a mapping of tag names and value pairs, a call back reference that provides a universal resource identifier (URI) at which the network function consumer receives notification upon expiration of the timer, a delete after attribute defining a period following expiration of the timer after which the timer resource will be deleted, or a schema Office Action mailed July 25, 2025 identifier that provides a reference to an identifier of a meta schema with which meta tags of the timer comply (see Page 51 section 6.1.6.2.3: Attribute name “Tags” which maps tag name/values pairs, where the tag name is a unique string name that is the primary key of the map and is paired with an array of string values).
Regarding claims 59 and 70, they disclose the same limitations as claim 48 examined above. Therefore, the same rationale of rejection is applied.
Regarding claims 60 and 71, they disclose the same limitations as claim 49 examined above. Therefore, the same rationale of rejection is applied.
Regarding claims 63 and 74, they disclose the same limitations as claim 52 examined above. Therefore, the same rationale of rejection is applied.
Regarding claims 64 and 75, they disclose the same limitations as claim 53 examined above. Therefore, the same rationale of rejection is applied.
Regarding claims 65 and 76, they disclose the same limitations as claim 54 examined above. Therefore, the same rationale of rejection is applied.
Regarding claims 68 and 79, they disclose the same limitations as claim 57 examined above. Therefore, the same rationale of rejection is applied.
Regarding claims 69 and 80, they disclose the same limitations as claim 58 examined above. Therefore, the same rationale of rejection is applied.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ABDULKADER M ALRIYASHI whose telephone number is (313)446-6551. The examiner can normally be reached Monday - Friday, 8AM - 5PM Alt, Friday, 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, JOON HWANG can be reached at (571)272-4036. 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.
/Abdulkader M Alriyashi/Primary Examiner, Art Unit 2447 9/12/2026
Prosecution Insights