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 .
DETAILED ACTION
The amendment filed 04/14/2026 has been entered. Claims 55-69 are pending. No claim is added, amended, and cancelled.
Response to Arguments
Applicant's arguments filed 04/14/2026 have been fully considered but they are not persuasive.
In that remark, the applicant argued in substance:
That: The combination of Gupta, CAUSHI, Kuchibhotla and Palat fails to disclose, teach or suggest “wherein the triggering event comprises a state transition of the communication device”
In response to the applicant’s argument Palat in [0036] teaches, the eNB 404 may send an RRCConnectionRelease message (MSG4) to the UE, and in [0063], the UE capability has the potential to change while the UE is INACTIVE state, the UE may ‘release’ the connection and establish a new one if the UE capabilities have changed while the UE is in connected mode. Based on this, if the UE's capability has changed during the RRC INACTIVE state, the UE can initiate a new RRC Setup Request.
In [0055] and [0056], the UE may be updated with the new capability ID as part of the software update and different software version may result in a different capability ID. So that the software update corresponds to the triggering event leads the UE to change the capability corresponds to state transition and the software update and the capability change can be performed while the UE is inactive state or offline.
Therefore, Palat clearly teaches a software update (triggering event) leads the UE to change a capability (state transition). The broadest interpretation of the “trigger event” can be any event that pushes the UE’s capability to change.
In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, the motivation is improving network processes and resource usage that is obtained from performing a software update and capability change while the UE is offline or inactive.
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.
Claim(s) 55-69 is/are rejected under 35 U.S.C. 103 as being unpatentable over Gupta (US 20200097277) hereinafter Gupta in view of CAUSHI et al. (US 20180024826) hereinafter CAUSHI and Kuchibhotla et al. (US 20160092196) hereinafter Kuchibhotla and further in view of Palat et al. (US 20210352467) hereinafter Palat.
Regarding claim 55, Gupta teaches a method performed by a communication device for managing a software, SW, version in the communication device (i.e. Software update manager 112 may determine whether a software update is needed for MTC device 100 based on software version information of MTC device 100 received from SCEF, [0045]), the method comprising: obtaining an indication of at least one network indicated SW version from a network node (i.e. determine whether there is a software version indicated by the database record for the hardware version of MTC device 100 that is more current than the software currently being used by MTC device. If AS 108 identifies a need for a software update, AS 108 may choose to deliver the software update to MTC device 100, [0058]).
However, Gupta does not explicitly disclose wherein at least two SW versions are stored in the communication device in relation to a same subscriber identity module, SIM.
However, CAUSHI teaches wherein at least two SW versions are stored in the communication device in relation to a same subscriber identity module, SIM (i.e. maintaining a data store of software (e.g., firmware, etc.) versions associated with a subscriber identity module (SIM) of the computing platform, [0030]).
Based on Gupta in view of CAUSHI, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of CAUSHI to the system of Gupta in order to increase capability of Gupta’s system.
However, Gupta in view of CAUSHI do not explicitly disclose obtaining an indication of an associated triggering event; upon obtaining an indication of an occurrence of the triggering event; activating or deactivating the indicated software version associated with the triggering event; and transmitting an acknowledgment message, acknowledging the activation or deactivation.
However, Kuchibhotla teaches obtaining an indication of an associated triggering event (i.e. scheduling logic 130 publishes a scheduled maintenance window to targets within a flocking group. The targets may be registered with specific time slots within the maintenance window, [0088] and update management system may trigger parallel update of targets 1, 3, and 5, [0091]); upon obtaining an indication of an occurrence of the triggering event; activating or deactivating the indicated software version associated with the triggering event (i.e. one or more targets are scheduled to be switched to an updated version of the software application. Once the scheduled time corresponding to time slot 910 arrives, the new version of the application is activated on each target registered, [0088] and once the update for target 1 is complete, the activation process may be performed on target 2, and once the update of target 3 is complete, the activation process may be performed on target 4, [0091]); and transmitting an acknowledgment message, acknowledging the activation or deactivation (i.e. If activation is successful for the threshold percentage of targets, feedback is received by update management system during the scheduled maintenance of the targets, [0093]-[0094]).
Based on Gupta in view of CAUSHI and further in view of Kuchibhotla, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Kuchibhotla to the system of Gupta and CAUSHI in order to have an update process that maintains target availability and performs software updated with zero or minimal downtime, (Kuchibhotla [0019]).
However, Gupta in view of CAUSHI and further in view of Kuchibhotla do not explicitly disclose wherein the triggering event comprises a state transition of the communication device.
However, Palat teaches wherein the triggering event comprises a state transition of the communication device (i.e. the eNB 404 may send an RRCConnectionRelease message (MSG4) to the UE, [0036] and the UE capability has the potential to change while the UE is INACTIVE state, the UE may ‘release’ the connection and establish a new one if the UE capabilities have changed while the UE is in connected mode. Based on this, if the UE's capability has changed during the RRC INACTIVE state, the UE can initiate a new RRC Setup Request, [0063]).
Based on Gupta in view of CAUSHI and Kuchibhotla and further in view of Palat, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to utilize the teaching of Palat to the system of Gupta, CAUSHI, and Kuchibhotla in order to improve network processes and resource usage.
Regarding 56, Gupta teaches the acknowledge message is transmitted using the network indicated SW version (i.e. After the software is installed, MTC device 100 reports the software update summary to the network. In line 9, MTC device 100 sends a NAS data transport message to MME 104. Then NAS data transport message indicates the status of the software update and acknowledges receipt of the software update, [0064]).
Regarding 57, Gupta teaches providing an indication, to a network node, of at least one available SW version stored in the communication device (i.e. MTC device 100 sends a NAS attach request message to MME 104. The NAS attach request message that carries an indication of the current software version used by MTC device, [0056]).
Regarding 58, Gupta teaches the obtaining the indication of at least one network indicated SW version (i.e. transmitting, by the control plane network node and via NIDD or NAS messaging, the software update to the MTC device, Abstract), is performed using any one of a Radio Resource Control (RRCJ message, a non-access stratum(NAS) message, a medium access control (MAC) (i.e. MTC device 100 sends a NAS attach request message to MME 104. The NAS attach request message that carries an indication of the current software version used by MTC device, [0056]), a MAC Control Element protocol message and an Over-the-Top application message.
Regarding 59, Gupta does not explicitly disclose the SW version comprises one or more of a protocol stack SW version, a specific protocol in a protocol stack SW version, a version of a specific function within a protocol, a version of a specific functionality within a protocol, a version of a specific protocol state, and a firmware version for the communication device.
However, CAUSHI teaches the SW version comprises one or more of a protocol stack SW version, a specific protocol in a protocol stack SW version, a version of a specific function within a protocol, a version of a specific functionality within a protocol, a version of a specific protocol state, and a firmware version for the communication device (i.e. The software updates 220 may include, updated versions of firmware to be installed, [0032] and the computing platform 104 may install the software updates 220, such as by executing or otherwise applying the firmware update to the installed firmware version to update the firmware version, [0066]). Therefore, the limitations of claim 59 are rejected in the analysis of claim 55 above, and the claim is rejected on that basis.
Regarding 60, Gupta does not explicitly disclose the indication of at least one network indicated SW version comprises an SW version identifier, indicating the associated network indicated SW version.
However, CAUSHI teaches the indication of at least one network indicated SW version comprises an SW version identifier, indicating the associated network indicated SW version (i.e. An instruction creator 224 may be configured to generate an instruction file (hereinafter, instructions) 216 using the interrogator log 212. To identify the software updates 220, the instruction creator 224 may be configured to compare the current software versions of controllers indicated in the interrogator log 212 with the latest version of the software compatible with the computing platform, [0037] and the instructions 216 may be a file or other data structure configured to identify binaries or other software updates 220 that should be installed, [0038]). Therefore, the limitations of claim 60 are rejected in the analysis of claim 55 above, and the claim is rejected on that basis.
Regarding 61, Gupta does not explicitly disclose the obtaining the indication of at least one network indicated SW version comprises obtaining a list, wherein an element of the list comprises a SW version identifier and an element of the list comprises an associated SW version or address location of at least one network indicated SW version.
However, CAUSHI teaches the obtaining the indication of at least one network indicated SW version comprises obtaining a list, wherein an element of the list comprises a SW version identifier (i.e. the instructions 216 may be a file or other data structure configured to identify binaries or other software updates 220 that should be installed, [0038])and an element of the list comprises an associated SW version or address location of at least one network indicated SW version (i.e. the computing platform may be configured to query for existence and version information for at least a portion of these software components. The computing platform may, for instance, reference an optimized data identifier list (ODL) file 214 that defines the specific information to query and where such information may be located. The ODL file 214 may, in some cases, be installed as part of an installation of software on the computing platform, [0027]). Therefore, the limitations of claim 61 are rejected in the analysis of claim 55 above, and the claim is rejected on that basis.
Regarding 62, Gupta teaches the SW versions are stored in the communication device in a chipset, or a SIM card (i.e. software update manager may also store MTC device hardware and software update information in a hardware/software information repository, [0071]).
Regarding claims 63-69, the limitations of claims 63-69 are similar to the limitations of claims 55 and 57-59, and 61-62. CAUSHI Further teaches a communication device comprises: a processor; a transceiver (i.e. the computing platform 104 may include a wireless transceiver, [0022]); and a memory storing instructions that, when executed by the processor (i.e. A computing platform 104 may include one or more processors 106 connected with both a memory 108 and a computer-readable storage medium 112 and configured to perform instructions, [0015]); a computer program product comprising a computer program comprising program code to be executed by at least one processor (i.e. providing instructions or other data that may be read by the processor. Computer-executable instructions may be compiled or interpreted from computer programs created using, [0015]); providing, to a communication device, an instruction comprising an indication of a least one network indicated SW version and an instruction for at least one action to be performed on at least one network indicated SW version (i.e. The instructions 216 may be a file or other data structure configured to identify binaries or other software updates 220 that should be installed to the vehicle 102. The instructions 216 may specify network locations at which each of the specified software updates 220 may be retrieved. As one example, the instructions 216 may specify the network locations as universal resource locators (URLs) served by web servers 218 of the one of the regional software delivery networks 204 in the region 210 associated with the vehicle, [0038]), providing, to the communication device, at least one SW version, and/or at least one parameter update for at least one network indicated SW version (i.e. The IVSU 202 sends the instructions 216 to the vehicle 102 at time index (E). In an example, the IVSU 202 may send the instructions 216 to the vehicle 102 via HTTPS (e.g., over the HTTPS connection to which the computing platform 104 sent the interrogator log 212 to the computing platform. Once received, the computing platform 104 may be configured to install the software updates 220 indicated by the instructions, [0050]). Therefore, the limitations of claims 63-69 are rejected in the analysis of claims 55 and 57-59, and 61-62 above, and the claims are rejected on that basis.
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 AYELE F WOLDEMARIAM whose telephone number is (571)270-5196. The examiner can normally be reached M_F 8:30AM-5:00PM.
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 H Hwang can be reached on 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.
/A W/
AYELE F. WOLDEMARIAM
Examiner
Art Unit 2447
5/8/2026
/SURAJ M JOSHI/Primary Examiner, Art Unit 2447
Prosecution Insights