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 .
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory obviousness-type double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); and In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on a nonstatutory double patenting ground provided the conflicting application or patent either is shown to be commonly owned with this application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement.
Effective January 1, 1994, a registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must fully comply with 37 CFR 3.73(b).
Claims 1-20 are rejected on the ground of nonstatutory obviousness-type double patenting as being unpatentable over claims 1-17 of patent 11356886 (application 16630689).
Although the conflicting claims are not identical, they are not patentably distinct from each other in light of the following evidences.
For double patenting to exist as between the rejected claims and patent claims, it must be determined that the rejected claims are not patentably distinct from the patent claims. In order to make this determination, it first must be determined whether there are any differences between the rejected claims and the patent claims and, if so, whether those differences render the claims patentably distinct.
The differences between the rejected claims and the patent claims don’t render the claims patentably distinct because the claims of the instant application merely broaden the scope of the claims of the patent. It had been held that the omission of an element and its function is an obvious expedient if the remaining elements perform the same function as before. In re Karlson,136 USQ 184 (CCPA). Also note Ex parte Rainu, 168 USPQ 375 (Bd.App.1969); omission of a reference element whose function is not needed would be obvious to one skilled in the art.
Also, the differences between the rejected claims and the patent claims don’t render the claims patentably distinct as can be seen from the art rejections in the current application and the patent.
Also, according to MPEP 804 under Anticipation Analysis, "The analysis required is different in situations where the claim in the application being examined (1) is directed to a species or sub-genus covered by a generic claim in a potentially conflicting patent or application, or (2) overlaps in scope with a claim in a potentially conflicting patent or application but the potentially conflicting claims cannot be said to anticipate the examined claims. Both of these situations require an obviousness analysis unless one of ordinary skill in the art would, on reading the potentially conflicting patent or application, at once envisage the invention claimed in the examined application. See AbbVie Inc. v. Kennedy Institute of Rheumatology Trust, 764 F.3d 1366, 112 USPQ2d 1001 (Fed. Cir. 2014)"
Clearly, "one of ordinary skill in the art would, on reading the potentially conflicting patent or application, at once envisage the invention claimed in the examined application".
In summary, as discussed in details above, clearly the differences between the rejected claims and the patent claims don’t render the claims patentably distinct.
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.
Claim 13 is 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 pre-AIA the applicant regards as the invention.
Claim 13 is indefinite because there is insufficient antecedent basis for the following limitation:
“the base station” (claim 13).
Claim Rejections - 35 USC § 102
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)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(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.
Claims 1-5, 7, 10-18, 20 are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Watfa, US 20190223093.
For claim 1. Watfa teaches: A method of processing a network slice based congestion, performed by a user terminal, and comprising: (Watfa, fig 6, paragraph 125-132)
sending a session modification request to an Authentication Management Function (AMF), wherein the session modification request is configured to request modifying a session connection of the user terminal in a target network slice; (Watfa, paragraph 72, “The AMF may host functions such as authentication and/or mobility management functions related to a network slice.”; fig 6, paragraph 125-132, “The AMF may send the back-off timer upon receiving a mobility management message from a WTRU. The mobility management message may be a service request message or a registration request message (e.g., a tracking area update (TAU) request), for example. The mobility management message may include a PDU session ID that may point to one or more established PDU sessions. The AMF may send the back-off timer in a mobility management (MM) accept NAS message to the WTRU, in a MM reject NAS message to the WTRU, and/or the like. The NAS message may include an indication that the back-off timer may apply to WTRU-originated signaling for a particular dedicated network slice or slice instance. Different back-off timer values may be set for different slices. The WTRU may be instructed to back-off from connecting to a first slice… A WTRU may receive an explicit indication of a back-off timer (e.g., from the network and/or an AMF). The indication may instruct the WTRU to deactivate an inactive PDU session associated with a congested slice. The indication may instruct the WTRU to deactivate active and/or inactive PDU sessions associated with a congested slice.”; the mobility management message is a session modification request because it’s a service request that includes a PDU session ID that points to one or more established PDU sessions and the message that WTRU receives in response to such service request includes a back-off timer which instruct the WTRU to deactivate active and/or inactive PDU sessions associated with a congested slice)
receiving a session modification reject message sent by the AMF, wherein the session modification reject message comprises indication information indicating that the target network slice is congested and a backoff parameter; (Watfa, fig 6, paragraph 125-132, “The AMF may send the back-off timer in a mobility management (MM) accept NAS message to the WTRU, in a MM reject NAS message to the WTRU, and/or the like. The NAS message may include an indication that the back-off timer may apply to WTRU-originated signaling for a particular dedicated network slice or slice instance. Different back-off timer values may be set for different slices. The WTRU may be instructed to back-off from connecting to a first slice… A WTRU may receive an explicit indication of a back-off timer (e.g., from the network and/or an AMF). The indication may instruct the WTRU to deactivate an inactive PDU session associated with a congested slice. The indication may instruct the WTRU to deactivate active and/or inactive PDU sessions associated with a congested slice.”)
and backing off the target network slice. (Watfa, fig 6, paragraph 125-132, “When a WTRU receives an indication of a back-off mechanism (e.g., a back-off timer) associated with a network slice and/or previously transmitted S-NSSAI, the WTRU may refrain from sending another session management message or S-NSSAI to the network for the duration of the back-off timer… Different back-off timer values may be set for different slices. The WTRU may be instructed to back-off from connecting to a first slice.”)
For claim 2. Watfa discloses all the limitations of claim 1, and Watfa further teaches: wherein the backing off the target network slice comprises: prohibiting the user terminal from initiating a session request to the target network slice. (Watfa, fig 6, paragraph 125-132, “When a WTRU receives an indication of a back-off mechanism (e.g., a back-off timer) associated with a network slice and/or previously transmitted S-NSSAI, the WTRU may refrain from sending another session management message or S-NSSAI to the network for the duration of the back-off timer… Different back-off timer values may be set for different slices. The WTRU may be instructed to back-off from connecting to a first slice… A WTRU may perform one or more actions upon receiving a back-off indication (e.g., a back-off timer) for a network slice. For example, upon receiving a back-off indication, the WTRU may cease sending session management requests for the slice that corresponds to the received back-off mechanism.”)
For claim 3. Watfa discloses all the limitations of claim 1, and Watfa further teaches: wherein the backoff parameter comprises a backoff time; the backing off the target network slice comprises: starting a backoff timer with a timing time being the backoff time, and prohibiting the user terminal from initiating a session request to the target network slice until the backoff timer expires or stops. (Watfa, fig 6, paragraph 125-132, “When a WTRU receives an indication of a back-off mechanism (e.g., a back-off timer) associated with a network slice and/or previously transmitted S-NSSAI, the WTRU may refrain from sending another session management message or S-NSSAI to the network for the duration of the back-off timer… Different back-off timer values may be set for different slices. The WTRU may be instructed to back-off from connecting to a first slice.”)
For claim 4. Watfa discloses all the limitations of claim 1, and Watfa further teaches: wherein the backing off the target network slice comprises: in the case that the user terminal is running a backoff timer corresponding to the target network slice and a value of a backoff time in a backoff parameter is not 0 and is not a deactive value, stopping the backoff timer, and starting the backoff timer after a timing time of the backoff timer is set to be the backoff time, and prohibiting the user terminal from initiating a session request to the target network slice, until the backoff timer expires, until the backoff timer stops, until a Public Land Mobile Network, PLMN, connected to the user terminal changes, or until a Universal Subscriber Identity Module, USIM, of the user terminal is removed; or in the case that the user terminal is running a backoff timer corresponding to the target network slice and a value of the backoff timer in a backoff parameter is a deactive value, stopping the backoff timer, and prohibiting the user terminal from initiating a session request to the target network slice, until the user terminal is powered off, until a PLMN connected to the user terminal changes, or until a USIM of the user terminal is removed. (Watfa, fig 6, paragraph 125-132, “When a WTRU receives an indication of a back-off mechanism (e.g., a back-off timer) associated with a network slice and/or previously transmitted S-NSSAI, the WTRU may refrain from sending another session management message or S-NSSAI to the network for the duration of the back-off timer… Different back-off timer values may be set for different slices. The WTRU may be instructed to back-off from connecting to a first slice. The WTRU may be allowed to establish a connection with a second slice during a back-off period associated with the first slice.”; clearly the back-off timer value for first slice is not zero and is not a deactive value; implicit that the back-off timer would be stopped and then started with the newly received back-off timer value; also implicit that if the backoff timer value is deactive, expires, the timer would be stopped)
For claim 5. Watfa discloses all the limitations of claim 4, and Watfa further teaches: further comprising: in the case that the user terminal is running the backoff timer corresponding to the target network slice and the backoff parameter comprises the backoff time with a value of 0, stopping the backoff timer. (Watfa, fig 6, paragraph 125-132, “When a WTRU receives an indication of a back-off mechanism (e.g., a back-off timer) associated with a network slice and/or previously transmitted S-NSSAI, the WTRU may refrain from sending another session management message or S-NSSAI to the network for the duration of the back-off timer… Different back-off timer values may be set for different slices. The WTRU may be instructed to back-off from connecting to a first slice. The WTRU may be allowed to establish a connection with a second slice during a back-off period associated with the first slice.”; clearly the back-off timer value for second slice is zero; implicit that the back-off timer is stopped, not used when the back-off value is zero)
For claim 7. Watfa discloses all the limitations of claim 2, and Watfa further teaches: wherein the session request comprises a packet data unit session connection establishment request or a packet data unit session connection modification request. (Watfa, fig 6, paragraph 125-132, “The AMF may send the back-off timer upon receiving a mobility management message from a WTRU. The mobility management message may be a service request message or a registration request message (e.g., a tracking area update (TAU) request), for example. The mobility management message may include a PDU session ID that may point to one or more established PDU sessions. The AMF may send the back-off timer in a mobility management (MM) accept NAS message to the WTRU, in a MM reject NAS message to the WTRU, and/or the like. The NAS message may include an indication that the back-off timer may apply to WTRU-originated signaling for a particular dedicated network slice or slice instance. Different back-off timer values may be set for different slices. The WTRU may be instructed to back-off from connecting to a first slice… A WTRU may receive an explicit indication of a back-off timer (e.g., from the network and/or an AMF). The indication may instruct the WTRU to deactivate an inactive PDU session associated with a congested slice. The indication may instruct the WTRU to deactivate active and/or inactive PDU sessions associated with a congested slice.”; the mobility management message is a PDU session connection, modification request because it’s a service request that includes a PDU session ID that points to one or more established PDU sessions and the message that WTRU receives in response to such service request includes a back-off timer which instruct the WTRU to deactivate active and/or inactive PDU sessions associated with a congested slice)
For claim 10. Watfa discloses all the limitations of claim 3, and Watfa further teaches: wherein subsequent to the backing off the target network slice, the method further comprises: receiving an NAS message sent by an AMF or a Session Management Function (SMF) of the target network slice, wherein the NAS message is configured to indicate that the target network slice is not congested; and stopping the backoff timer corresponding to the backoff time. (Watfa, paragraph 130, “The WTRU may stop the back-off timer when the WTRU receives an explicit indication informing the WTRU that a congestion situation no longer exists in the corresponding network slice. The explicit indication may be received from an AMF. The explicit indication may be received via mobility management signaling or session management signaling, for example.”)
For claim 11. Watfa teaches: A method of processing a network slice based congestion, performed by an Authentication Management Function (AMF), and comprising: (Watfa, fig 6, paragraph 125-132; paragraph 72, “The AMF may host functions such as authentication and/or mobility management functions related to a network slice.”)
receiving a session modification request sent by a user terminal, wherein the session modification request is configured to request modifying a session connection of the user terminal in a target network slice; (Watfa, fig 6, paragraph 125-132, “The AMF may send the back-off timer upon receiving a mobility management message from a WTRU. The mobility management message may be a service request message or a registration request message (e.g., a tracking area update (TAU) request), for example. The mobility management message may include a PDU session ID that may point to one or more established PDU sessions. The AMF may send the back-off timer in a mobility management (MM) accept NAS message to the WTRU, in a MM reject NAS message to the WTRU, and/or the like. The NAS message may include an indication that the back-off timer may apply to WTRU-originated signaling for a particular dedicated network slice or slice instance. Different back-off timer values may be set for different slices. The WTRU may be instructed to back-off from connecting to a first slice… A WTRU may receive an explicit indication of a back-off timer (e.g., from the network and/or an AMF). The indication may instruct the WTRU to deactivate an inactive PDU session associated with a congested slice. The indication may instruct the WTRU to deactivate active and/or inactive PDU sessions associated with a congested slice.”; the mobility management message is a session modification request because it’s a service request that includes a PDU session ID that points to one or more established PDU sessions and the message that WTRU receives in response to such service request includes a back-off timer which instruct the WTRU to deactivate active and/or inactive PDU sessions associated with a congested slice)
sending a session modification reject message to the user terminal, wherein the session modification reject message comprises indication information indicating that the target network slice is congested and a backoff parameter. (Watfa, fig 6, paragraph 125-132, “The AMF may send the back-off timer in a mobility management (MM) accept NAS message to the WTRU, in a MM reject NAS message to the WTRU, and/or the like. The NAS message may include an indication that the back-off timer may apply to WTRU-originated signaling for a particular dedicated network slice or slice instance. Different back-off timer values may be set for different slices. The WTRU may be instructed to back-off from connecting to a first slice… A WTRU may receive an explicit indication of a back-off timer (e.g., from the network and/or an AMF). The indication may instruct the WTRU to deactivate an inactive PDU session associated with a congested slice. The indication may instruct the WTRU to deactivate active and/or inactive PDU sessions associated with a congested slice.”)
For claim 12. Watfa discloses all the limitations of claim 11, and Watfa further teaches: wherein prior to the sending the session modification reject message to the user terminal, the method further comprises: receiving slice congestion information sent by a Session Management Function (SMF) or a Policy Control Function (PCF) of a target network slice, wherein the slice congestion information is configured to indicating that the target network slice is congested. (Watfa, fig 6, paragraph 125-132, “An AMF serving the WTRU may be aware that connections to the particular slice may not be established (e.g., due to a congestion situation at the slice)... The AMF may become cognizant of the congestion situation based on interaction with other network functions including but not limited to a network slice selection function (NSSF), a network repository function (NRF), a session management function (SMF), and/or other operation and maintenance (O&M) network functions.”)
For claim 13. Watfa discloses all the limitations of claim 11, and Watfa further teaches: further comprising: sending a congestion start message to the base station, wherein the congestion start message is configured to indicate that the target network slice is congested, and the congestion start message comprises a backoff parameter; (Watfa, fig 6, paragraph 125-132, “The AMF may send the back-off timer in a mobility management (MM) accept NAS message to the WTRU, in a MM reject NAS message to the WTRU, and/or the like. The NAS message may include an indication that the back-off timer may apply to WTRU-originated signaling for a particular dedicated network slice or slice instance. Different back-off timer values may be set for different slices. The WTRU may be instructed to back-off from connecting to a first slice… A WTRU may receive an explicit indication of a back-off timer (e.g., from the network and/or an AMF). The indication may instruct the WTRU to deactivate an inactive PDU session associated with a congested slice. The indication may instruct the WTRU to deactivate active and/or inactive PDU sessions associated with a congested slice.”; fig 1D, paragraph 58-68, AMF and WTRU communicates with each other via gNB)
and sending a congestion stop message to the base station, wherein the congestion stop message is configured to indicate that the target network slice is not congested. (Watfa, paragraph 130, “The WTRU may stop the back-off timer when the WTRU receives an explicit indication informing the WTRU that a congestion situation no longer exists in the corresponding network slice. The explicit indication may be received from an AMF. The explicit indication may be received via mobility management signaling or session management signaling, for example.”; fig 1D, paragraph 58-68, AMF and WTRU communicates with each other via gNB)
For claim 14. Watfa teaches: A user terminal, characterized by comprising: a memory, a processor and a program for processing a network slice based congestion stored in the memory and executable on the processor, wherein the program for processing the network slice based congestion is executed by the processor to perform: (Watfa, fig 1B, paragraph 31-40, 140)
sending a session modification request to an Authentication Management Function (AMF), wherein the session modification request is configured to request modifying a session connection of the user terminal in a target network slice; (Watfa, paragraph 72, “The AMF may host functions such as authentication and/or mobility management functions related to a network slice.”; fig 6, paragraph 125-132, “The AMF may send the back-off timer upon receiving a mobility management message from a WTRU. The mobility management message may be a service request message or a registration request message (e.g., a tracking area update (TAU) request), for example. The mobility management message may include a PDU session ID that may point to one or more established PDU sessions. The AMF may send the back-off timer in a mobility management (MM) accept NAS message to the WTRU, in a MM reject NAS message to the WTRU, and/or the like. The NAS message may include an indication that the back-off timer may apply to WTRU-originated signaling for a particular dedicated network slice or slice instance. Different back-off timer values may be set for different slices. The WTRU may be instructed to back-off from connecting to a first slice… A WTRU may receive an explicit indication of a back-off timer (e.g., from the network and/or an AMF). The indication may instruct the WTRU to deactivate an inactive PDU session associated with a congested slice. The indication may instruct the WTRU to deactivate active and/or inactive PDU sessions associated with a congested slice.”; the mobility management message is a session modification request because it’s a service request that includes a PDU session ID that points to one or more established PDU sessions and the message that WTRU receives in response to such service request includes a back-off timer which instruct the WTRU to deactivate active and/or inactive PDU sessions associated with a congested slice)
receiving a session modification reject message sent by the AMF, wherein the session modification reject message comprises indication information indicating that the target network slice is congested and a backoff parameter; (Watfa, fig 6, paragraph 125-132, “The AMF may send the back-off timer in a mobility management (MM) accept NAS message to the WTRU, in a MM reject NAS message to the WTRU, and/or the like. The NAS message may include an indication that the back-off timer may apply to WTRU-originated signaling for a particular dedicated network slice or slice instance. Different back-off timer values may be set for different slices. The WTRU may be instructed to back-off from connecting to a first slice… A WTRU may receive an explicit indication of a back-off timer (e.g., from the network and/or an AMF). The indication may instruct the WTRU to deactivate an inactive PDU session associated with a congested slice. The indication may instruct the WTRU to deactivate active and/or inactive PDU sessions associated with a congested slice.”)
and backing off the target network slice. (Watfa, fig 6, paragraph 125-132, “When a WTRU receives an indication of a back-off mechanism (e.g., a back-off timer) associated with a network slice and/or previously transmitted S-NSSAI, the WTRU may refrain from sending another session management message or S-NSSAI to the network for the duration of the back-off timer… Different back-off timer values may be set for different slices. The WTRU may be instructed to back-off from connecting to a first slice.”)
For claim 15. Watfa discloses all the limitations of claim 14, and Watfa further teaches: wherein the backing off the target network slice comprises: prohibiting the user terminal from initiating a session request to the target network slice. (Watfa, fig 6, paragraph 125-132, “When a WTRU receives an indication of a back-off mechanism (e.g., a back-off timer) associated with a network slice and/or previously transmitted S-NSSAI, the WTRU may refrain from sending another session management message or S-NSSAI to the network for the duration of the back-off timer… Different back-off timer values may be set for different slices. The WTRU may be instructed to back-off from connecting to a first slice… A WTRU may perform one or more actions upon receiving a back-off indication (e.g., a back-off timer) for a network slice. For example, upon receiving a back-off indication, the WTRU may cease sending session management requests for the slice that corresponds to the received back-off mechanism.”)
For claim 16. Watfa discloses all the limitations of claim 14, and Watfa further teaches: wherein the backoff parameter comprises a backoff time; the backing off the target network slice comprises: starting a backoff timer with a timing time being the backoff time, and prohibiting the user terminal from initiating a session request to the target network slice until the backoff timer expires or stops. (Watfa, fig 6, paragraph 125-132, “When a WTRU receives an indication of a back-off mechanism (e.g., a back-off timer) associated with a network slice and/or previously transmitted S-NSSAI, the WTRU may refrain from sending another session management message or S-NSSAI to the network for the duration of the back-off timer… Different back-off timer values may be set for different slices. The WTRU may be instructed to back-off from connecting to a first slice.”)
For claim 17. Watfa discloses all the limitations of claim 14, and Watfa further teaches: wherein the backing off the target network slice comprises: in the case that the user terminal is running a backoff timer corresponding to the target network slice and a value of a backoff time in a backoff parameter is not 0 and is not a deactive value, stopping the backoff timer, and starting the backoff timer after a timing time of the backoff timer is set to be the backoff time, and prohibiting the user terminal from initiating a session request to the target network slice, until the backoff timer expires, until the backoff timer stops, until a Public Land Mobile Network, PLMN, connected to the user terminal changes, or until a Universal Subscriber Identity Module, USIM, of the user terminal is removed; or in the case that the user terminal is running a backoff timer corresponding to the target network slice and a value of the backoff timer in a backoff parameter is a deactive value, stopping the backoff timer, and prohibiting the user terminal from initiating a session request to the target network slice, until the user terminal is powered off, until a PLMN connected to the user terminal changes, or until a USIM of the user terminal is removed. (Watfa, fig 6, paragraph 125-132, “When a WTRU receives an indication of a back-off mechanism (e.g., a back-off timer) associated with a network slice and/or previously transmitted S-NSSAI, the WTRU may refrain from sending another session management message or S-NSSAI to the network for the duration of the back-off timer… Different back-off timer values may be set for different slices. The WTRU may be instructed to back-off from connecting to a first slice. The WTRU may be allowed to establish a connection with a second slice during a back-off period associated with the first slice.”; clearly the back-off timer value for first slice is not zero and is not a deactive value; implicit that the back-off timer would be stopped and then started with the newly received back-off timer value; also implicit that if the backoff timer value is deactive, expires, the timer would be stopped)
For claim 18. Watfa discloses all the limitations of claim 17, and Watfa further teaches: further comprising: in the case that the user terminal is running the backoff timer corresponding to the target network slice and the backoff parameter comprises the backoff time with a value of 0, stopping the backoff timer. (Watfa, fig 6, paragraph 125-132, “When a WTRU receives an indication of a back-off mechanism (e.g., a back-off timer) associated with a network slice and/or previously transmitted S-NSSAI, the WTRU may refrain from sending another session management message or S-NSSAI to the network for the duration of the back-off timer… Different back-off timer values may be set for different slices. The WTRU may be instructed to back-off from connecting to a first slice. The WTRU may be allowed to establish a connection with a second slice during a back-off period associated with the first slice.”; clearly the back-off timer value for second slice is zero; implicit that the back-off timer is stopped, not used when the back-off value is zero)
For claim 20. Watfa discloses all the limiations of claim 11, and Watfa further teaches: An Authentication Management Function (AMF), comprising: a memory, a processor and a program for processing a network slice based congestion stored in the memory and executable on the processor, wherein the program for processing the network slice based congestion is executed by the processor to perform the method of processing a network slice based congestion according to claim 11. (Watfa, fig 1D, paragraph 140; fig 6, paragraph 125-132; paragraph 72, “The AMF may host functions such as authentication and/or mobility management functions related to a network slice.”)
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.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Watfa, US 20190223093 in view of Sahu, US 20130258925.
For claim 6. Watfa discloses all the limitations of claim 3, however Watfa doesn’t teach: wherein in the case that the user terminal is powered off, the backoff timer continues to run during the user terminal is powered off.
Sahu from the same or similar fields of endeavor teaches: wherein in the case that the user terminal is powered off, the backoff timer continues to run during the user terminal is powered off. (Sahu, paragraph 7, “The method may include entering a sleep state, upon determining that the first communication channel is not available, and determining whether the first communication channel has become available during a subsequent awake period. In an example, entering a sleep state and determining whether the first communication channel has become available during a subsequent awake period may occur until the first communication channel becomes available or until the expiration of a back-off timer.”; clearly the back-off timer continues to run during the sleep, powered off period since device wake up when the back-off timer expires; please notes we have to interpret powered off as a sleep state here because if the device is fully powered off, nothing would be running, including the back-off timer)
Thus it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to implement the teachings of Sahu into Watfa, since Watfa suggests a technique for implementing a back-off timer, and Sahu suggests the beneficial way of running such back-off timer during a sleep period to optimize data transmission and conserve power (Sahu, paragraph 7) in the analogous art of communication.
Allowable Subject Matter
Claims 8-9, 19 would be allowable if a Terminal Disclaimer is submitted to overcome the rejection(s) under Double Patenting, set forth in this Office action and rewritten to include all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KHOA B HUYNH whose telephone number is (571)270-7185. The examiner can normally be reached Monday - Friday 1:00 PM - 9:35 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, Yemane Mesfin can be reached at (571) 272-3927. 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.
/KHOA HUYNH/Primary Examiner, Art Unit 2462
Prosecution Insights