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 .
This office action is in response to applicant’s amendment filed on 06/29/2026.
Claims 1-20 are pending and examined.
Response to Amendment
Applicant's arguments filed 06/29/2026 with regards to 35 U.S.C. 112 have been fully considered and are persuasive, as
The amendments to claim 1 and 10 reciting, “wherein the target update data has an association relationship with the update information”, are sufficient to overcome the rejection on stating that it is “unclear as how and why the first component is needed as the first component is not related to the other limitations of the claim ”.
The language in claim 14 resulting in a lack of antecedent basis has been removed. The rejections under 35 U.S.C. 112(b) have been withdrawn.
The language of claim 10 invoking 35 U.S.C. 112(f) has been removed. The rejections under 35 U.S.C. 112(b) have been withdrawn.
Applicant's arguments filed 06/29/2026 with regards to 35 U.S.C. 101 have been fully
considered but they are not persuasive.
Applicant argues with respect to Step 2A prong 2 the mental process cited by the Examiner in clam 1 is integrated into a practical application stating, “ Amended claim 1 recites a specific improvement to the operation of the electronic device” , “The recited operations include detecting that update information exists for a first component or a second component, obtaining target update data that has an association relationship with the update information, and updating the second component so that a target function affected by the update information is restored. This ordered combination is a particular way of maintaining the functions of an electronic device across an update of a component of the electronic device, and it is not a recitation of generic computer operations performed for their conventional purposes.”
Examiner respectfully disagrees. The recited abstract ideas remain as the mental process of determining that update information exists for a first and/or second component and identifying a target function associated with that update are determinations that a person can make with a pen and paper by simply looking at information. The elements that the applicant relies on for integration do not integrate the exception into a practical application because they are extra solution activity as analyzed below. For example “updating the second component based on the target update data” is a generic implementation of a well-known process in software development. Furthermore the amended claims recite a restore limitation as the result of the process however the claims do not recite any particular technical means of achieving that restoration beyond conventional update and install functionality. Because the additional elements, whether considered individually or as an ordered combination, remain well understood, routine, and conventional, they do not amount to significantly more under step 2B. Claims 10 and 14 are argued as allowable for reasons similar to claim 1 and thus rejected for the same reasons as outlined.
Applicant's arguments filed 06/29/2026 with regards to 35 U.S.C. 103 have been fully
considered but they are not persuasive. Applicant argued “to the extent Mitra discloses an update scheduling system, Mitra fails to disclose or suggest: obtaining update data based on the update information; the association between the update data and the target function; or restoring the target function by means of the update. In other words, Mitra fails to disclose or suggest the above-quoted claim elements recited in amended claim 1”, Examiner respectfully disagrees. The update data in Mitra is obtained based on the compatibility between pending upgrades of the OS and software components which corresponds to an association relationship. With regards to the amended claim limitation reciting “wherein the target function is affected by the update information, such that the target function is restored by updating the second component based on the target update data.” This is the exact problem that Mitra seeks to solve through automation. [Mitra, Summary] “An automated remediation and restoration system” See 35 U.S.C. 103 rejections below for a detailed analysis.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-20 are rejected under 35 U.S.C. 101 because the claimed invention recites a judicial exception, is directed to that judicial exception, an abstract idea, it has not been integrated into practical application and the claims further do not recite significantly more than the judicial exception. Examiner has evaluated the claims under the framework provided in the 2019 Patent Eligibility Guidance published in the Federal Register 01/07/2019 and has provided such analysis below.
Regarding claims 1,10 and 14, the similarly recited limitations, “determining that update information exists for a first component and/or a second component of an electronic device,” as drafted, are functions that, under their broadest reasonable interpretation, recite the abstract idea of a mental process. These limitations encompass a human mind carrying out these functions through observation, evaluation judgment and /or opinion, or even with the aid of pen and paper. For example, a user can observe and record the existence of an available software firmware update by looking at information such as available firmware versioning and update information and record the information based on the user’s understanding using pen and paper.
Under Prong 2, the judicial exception is not integrated into a practical application. The additional elements, “obtaining target update data for the second component of the electronic device, wherein the target update data has an association relationship with the update information”, do nothing more than add insignificant extra solution activity to the judicial exception of merely gathering and outputting data.
The additional elements, “and updating the second component based on the target update data to cause the second component to provide a target function or realize the target function through the second component” and “wherein the target function is affected by the update information, such that the target function is restored by updating the second component based on the target update data”, can be classified as mere instructions to apply an exception. The routine act of initiating the installation of a software update and settings merely invokes a computer in its ordinary capacity as a tool to perform a well-understood existing process. Accordingly, the additional elements do not integrate the recited judicial exception into a practical application and the claim is therefore directed to the judicial exception. See MPEP §2106.05(g) and §2106.05(d) respectively.
Under Step 2B, the claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As stated above in prong 2, the additional elements, “obtaining target update data for the second component of the electronic device, wherein the target update data has an association relationship with the update information”, is merely gathering data which the courts have identified as well-understood, routine conventional activity. See for example Symantec, 838 F.3d at 1321, 120 USPQ2d at 1362, MPEP 2106.05(d). The additional elements, “and updating the second component based on the target update data to cause the second component to provide a target function or realize the target function through the second component” and “wherein the target function is affected by the update information, such that the target function is restored by updating the second component based on the target update data”, can be classified as mere instructions to apply an exception because they merely invoke a computer in its ordinary capacity as a tool to perform a well-understood existing process. Therefore, the additional elements do not amount to significantly more, thus, cannot provide an inventive concept. Accordingly, the claims are not patent eligible under 35 USC 101.
Claim 10 recites further additional element “ a processor; and a memory storing instructions that, when executed by the processor, cause the update device to”. Claim 14 recites further additional element “A non-transitory computer-readable storage medium containing computer-executable instructions for, when executed by one or more processors”. These additional elements are recited at a high-level of generality such that they amount no more than mere instructions to apply the exception using generic computer, and/or generic computer components. See MPEP 2106.05(f). Therefore, the additional elements recited in claims 10 and 14 do not integrate the judicial exception into a practical application under prong 2, nor amount to significantly more under step 2B.
Regarding claim 6 and 19, the similarly recited limitations,” determining the target function to be set in the second component of the electronic device based on flag bit information in the first component”, recite additional mental process under Prong 1. For example, the above limitations can be achieved by a user looking at a Boolean table of configuration information and making determinations about correlations in the information . The additional elements, “obtaining the target update data for setting the target function”, are analyzed under Prong 2 as mere data gathering which does not integrate the judicial exception into a practical application, nor amount to significantly more under Step 2B for the reasons provided in the rejection of claim 1. The additional elements, “the flag bit information being used to record at least one function that the second component can have, the target function belonging to the at least one function recorded in the flag bit information”, can be classified Field of Use and Technological Environment, as restricting the type of information in the flag bit data does not provide any meaningful limits on the claim, see MPEP 2106.05(h).
Having concluded analysis within the provided framework, independent claims 1, 10 and 14 are rejected as they do not recite patent eligible subject matter under 35 U.S.C. § 101. Dependent claims 2-9, 11-13, and 15-20 recite similar limitations to those analyzed above and thus are rejected under the same rationale above because they do not recite patent eligible subject matter under 35 U.S.C. § 101 or do not include additional elements that are sufficient to amount to significantly more than the judicial exception. These claims merely further elaborate on the mental process itself or provide additional definition of insignificant processes which do not impose any meaningful limits on practicing the abstract idea. Accordingly, the claims are not patent eligible under 35 USC 101.
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.
Claim 1-5, 10-18 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by MITRA (US10936296B2), hereafter MITRA.
Regarding claim 1, MITRA discloses: an update method comprising: In response to determining that update information exists for a first component and/or a second component of an electronic device.
([Col. 2, lines 2-7] “an operating system of the computing device is scheduled for upgrade from a first configuration to a second configuration via a first upgrade package during an upcoming first upgrade event, as well as determine that an initial version of a first software component currently stored on the computing device is incompatible with the second configuration.”)
The operating system corresponds to a first component and the first software component corresponds to a second component. Determining that a first upgrade package exist for the operating system corresponds to, an update method comprising: In response to determining that update information exists for a first component of an electronic device.
obtaining target update data for the second component of the electronic device, wherein the target update data has an association relationship with the update information ([Col. 2, lines 2-20] “an operating system of the computing device is scheduled for upgrade from a first configuration to a second configuration…as well as determine that an initial version of a first software component currently stored on the computing device is incompatible with the second configuration. …the instructions cause the processor to submit a first update query to an online software repository regarding the first software component , and receive, from the online software repository, a first status indicating that a first content is available to update the first software component from the initial version to an updated version, wherein the updated version is compatible with the second configuration … the instructions also cause the processor to selectively download the first content from the online software repository to the computing device during the first upgrade event.”)
The first content to update the first software component corresponds to , obtaining target update data for the second component of the electronic device. The updated software version of the first software component is determined to be version compatible with the second configuration of the OS based on the update information. The compatibility between the upgrade for the OS and the upgrade for the first software component corresponds to, wherein the target update data has an association relationship with the update information.
and updating the second component based on the target update data. ([col.2, line 17-20] "the instructions also cause the processor to selectively download the first content from the online software repository to the computing device during the first upgrade event, and automatically update the first software component from the initial version to the updated version during the first upgrade event.“) Updating the first software component using the first content corresponds to updating the second component based on the target data.
to cause the second component to provide a target function or realize the target function through the second component, ( [Col. 4, line 12-40] “When an operating system for a client computing device is upgraded to a new configuration, previous software programs and/or components thereof that were stored on the client computing device can become incompatible with the new operating system configuration. In other words, performance of previously functional software components may become disrupted following an OS upgrade…. the system can determine if the client device includes versions of the various software items that are incompatible with the OS upgrade. If any of these software items correspond to versions that are not compatible, the system will automatically execute an update retrieval and deployment process to increase the likelihood that full array of software items stored the computing device will perform as expected by the user at the time the upgrade occurs, or soon thereafter” [Col 12, Lines 44-47] “For example, an older version of a language-related software that will be affected by the new OS to the extent that the user may be subjected to miscommunications or communications in other languages would be classified as high-priority.”)
The update to the OS may cause disruptions in the functionality of system components. The components such as the first software component can be updated in response to determining the incompatibility to ensure functionality, which corresponds to, to cause the second component to provide a target function or realize the target function through the second component,
wherein the target function is affected by the update information, such that the target function is restored by updating the second component based on the target update data.([Col 1, Line 64 - Col 2, Line 20] “An automated remediation and restoration system…determine that an initial version of a first software component currently stored on the computing device is incompatible with the second configuration. In addition, the instructions cause the processor to submit a first update query to an online software repository regarding the 10 first software component, and receive, from the online software repository, a first status indicating that a first content is available to update the first software component from the initial version to an updated version, wherein the updated version is compatible with the second configuration. 15 Furthermore, the instructions also cause the processor to selectively download the first content from the online software repository to the computing device during the first upgrade event, and automatically update the first software component from the initial version to the updated version 20 during the first upgrade event. [Col 4, Lines 18-26]” performance of previously functional software components may become disrupted following an OS upgrade. Users must then determine which software programs are affected and initiate a series of updates that restore or otherwise provide the desired performance by the software…. The following description discloses systems and methods25 for automated software update management in conjunction with OS upgrade events.”)
Automatically downloading software for the software component to ensure functionality after the OS upgrade corresponds to a restoration operation and thus corresponds to, wherein the target function is affected by the update information, such that the target function is restored by updating the second component based on the target update data.
Regarding claim 2, MITRA teaches the method of claim 1. Mitra further teaches: determining that the update information exists for the first component and/or the second component of the electronic device includes at least one of:
determining that first update information exists for the first component and/or second update information exists for the second component in response to determining that correspondence information between the first component and the second component of the electronic device does not match.
determining that the first update information exists for the first component in response to determining that current information of the first component of the electronic device does not match corresponding historical information; or,
determining that the second update information exists for the second component in response to determining that current information of the second component of the electronic device does not match corresponding historical information
( [Col 4, lines 24-42] “An automated software update management system (“automated update system”) is configured to receive information about the upcoming OS upgrade and verify whether one or more of the software items on a client computing device will be impacted as a result of the upgrade…. the system can determine if the client device includes versions of the various software items that are incompatible with the OS upgrade. If any of these software items correspond to versions that are not compatible, the system will automatically execute an update retrieval and deployment process.”)
Regarding limitation ‘a’. As stated by the applicant spec [0036] “the mismatch in correspondence information between the first component and the second component may be that the version information between the first component and the second component does not match.“ The software item as component 2 may be version incompatible with the OS version which correlates to the correspondence information between the first and second component that does not match. The update retrieval obtained for the software item corresponds to the second update information that exists for the second component in response to determining that correspondence information between the first component and the second component of the electronic device does not match.
Regarding claim 3, MITRA teaches the method of claim 2. Mitra further teaches: wherein determining that the first update information exists for the first component includes that:
version update information exists for the second component;
flag bit update information exists for the first component, the flag bit update information being at least used to characterize function item update information of the second component of the electronic device; or
a replacement record exists for a third component of the electronic device, the third component being used for the second component of the electronic device to achieve the target function; or,
determining that the second update information exists for the second component includes that: the version update information exists for the second component; loading information exists for the second component;
or the replacement record exists for the third component, the third component being used by the second component to achieve the target function.
( [Col 4, lines 24-42] “An automated software update management system (“automated update system”) is configured to receive information about the upcoming OS upgrade and verify whether one or more of the software items on a client computing device will be impacted as a result of the upgrade…. the system can determine if the client device includes versions of the various software items that are incompatible with the OS upgrade. If any of these software items correspond to versions that are not compatible, the system will automatically execute an update retrieval and deployment process.”)
Regarding limitation ‘c’ , as stated in the applicant spec [0047] ” loading information may include… downloading or uninstalling of software programs in the second component; or software reinstallation in the second component.” Update retrieval for the software item corresponds to the version update information of the second component, and the deployment process of installing the update corresponds to loading information as downloading of software programs in the second component.
Regarding claim 4, MITRA teaches the method of claim 1. Mitra further teaches: further comprising at least one of:
outputting target prompt information, and obtaining the target update data after obtaining target feedback information from a target user;
outputting the target prompt information, and updating the second component based on the target update data after obtaining the target feedback information from the target user; or
outputting the target prompt information in a target manner, and obtaining the target update data or updating the second component based on the target update data after obtaining the target feedback information from the target user, the target manner being determined based on the update information
([Col. 11, lines 3-18] “a determination is made that an operating system of a first configuration 310 is scheduled for an upgrade. The system presents an optional first message 312 via a device display 320 to notify the user of the pending upgrade and to provide an opportunity for the user to modify the scheduled event. In some implementations, the first message 312 may also include information related to the update of software referenced by the upgrade. Generally, software referenced by the upgrade will be affected by the new OS configuration and older versions of said software will require an update… a user may first receive an automated request from the system that informs the user of the planned upgrade event and corresponding software update session and asks the user to provide authorization, approval, or acknowledgement in order to proceed.”)
Regarding limitation ‘b’, the message pertaining to the pending upgrade presented via a display device corresponds to the outputting the target prompt information. The user approval to proceed with the update on the software referenced by the upgrade corresponds to updating the second component based on the target update data after obtaining the target feedback information from the target user.
Regarding claim 5, MITRA teaches the method of claim 1. Mitra further teaches: wherein obtaining the target update data of the second component of the electronic device includes at least one of:
requesting target update data matching the update information from a target server;
obtaining an acquisition path of the target update data based on release information of the target update data to obtain the target update data based on the acquisition path;
obtaining the target update data of the second component pushed by the target server to the electronic device; or
obtaining the target update data of the second component from an edge device that has established a target communication connection with the electronic device.
([Col 2, lines 48-64] “the instructions cause the processor to submit a first update query to an online software repository regarding the first software , and receive, from the online software repository, a first status indicating that a first content is available to update the first software component from the initial version to an updated version, wherein the updated version is compatible with the second configuration. Furthermore, the instructions also cause the processor to selectively download the first content from the online software repository to the computing device during the first upgrade event, and automatically update the first software component from the initial version to the updated version during the first upgrade event. “)
Regarding limitation ‘a’, submitting a query to the online software repository to get first content for the software component corresponds to requesting target update data matching the update information from a target server.
Regarding claim 10, it is a device claim having similar limitations cited in the rejection of claim 1. Thus claim 10 is also rejected under the same rationale as cited in the rejection of claim 1 above.
Regarding claim 11, it is a device claim having similar limitations cited in the rejection of claim 2. Thus claim 11 is also rejected under the same rationale as cited in the rejection of claim 2 above.
Regarding claim 12, it is a device claim having similar limitations cited in the rejection of claim 3. Thus claim 12 is also rejected under the same rationale as cited in the rejection of claim 3 above.
Regarding claim 13, it is a device claim having similar limitations cited in the rejection of claim 5. Thus claim 13 is also rejected under the same rationale as cited in the rejection of claim 5 above.
Regarding claim 14, it is a medium claim having similar limitations cited in the rejection of claim 1. Thus claim 14 is also rejected under the same rationale as cited in the rejection of claim 1 above.
Regarding claim 15, it is a medium claim having similar limitations cited in the rejection of claim 2. Thus claim 15 is also rejected under the same rationale as cited in the rejection of claim 2 above.
Regarding claim 16, it is a medium claim having similar limitations cited in the rejection of claim 3. Thus claim 16 is also rejected under the same rationale as cited in the rejection of claim 3 above.
Regarding claim 17, it is a medium claim having similar limitations cited in the rejection of claim 4. Thus claim 17 is also rejected under the same rationale as cited in the rejection of claim 4 above.
Regarding claim 18, it is a medium claim having similar imitations cited in the rejection of claim 5. Thus claim 18 is also rejected under the same rationale as cited in the rejection of claim 5 above.
Claim Rejections - 35 USC § 103
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 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 6-8, 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over MITRA (US10936296B2), in view of ASAHARA (US20180285091A1) hereafter ASAHARA.
Regarding claim 6, MITRA teaches the elements of claim 1 as outlined above.
MITRA does not appear to explicitly teach: wherein obtaining the target update data of the second component includes: determining the target function to be set in the second component of the electronic device based on flag bit information in the first component, the flag bit information being used to record at least one function that the second component can have, the target function belonging to the at least one function recorded in the flag bit information; and obtaining the target update data for setting the target function.
However ASAHARA teaches: wherein obtaining the target update data of the second component includes: determining the target function to be set in the second component of the electronic device based on flag bit information in the first component, the flag bit information being used to record at least one function that the second component can have, the target function belonging to the at least one function recorded in the flag bit information; and obtaining the target update data for setting the target function. ([0032-0035] “The setting storage unit 201 stores, in the secondary storage device 104, a setting for switching the behavior of each function of the image forming apparatus 100…. In the example shown in Table 1, a state is indicated in which there are two setting items, namely, setting A and setting B, and both the values are 0. … setting items may include a setting for any function among a plurality of functions included in one piece of firmware, or may include a setting for a function that is shared by a plurality of pieces of firmware. ... The firmware version storage unit 202 stores, in the secondary storage device 104, the versions of firmware pieces that are being operated in the image forming apparatus 100. In the example shown in Table 2, a state is indicated in which there are four pieces of firmware in total consisting of three pieces of firmware, namely, firmware 1, firmware 2 and firmware 3, and firmware for holding customized data, “)
The settings in the setting storage unit which have an active state represented by 0 or 1 and represent functions shared by a plurality of pieces of firmware such as Firmware 1 and Firmware 2, correlate to determining the target function to be set in the second component of the electronic device based on flag bit information in the first component, the flag bit information being used to record at least one function that the second component can have, the target function belonging to the at least one function recorded in the flag bit information.
and obtaining the target update data for setting the target function. ([0010]“ the method comprising: obtaining, from an external apparatus, a data set which includes firmware and customized data indicating a setting value for a function of the firmware; performing firmware update using the firmware included in the obtained data set; and applying the customized data indicating the setting value for the function of the firmware included in the obtained data set to the firmware provided in the information processing apparatus.”)
The obtained dataset which contains firmware and customized data indicating a setting value for a function of the firmware corresponds to obtaining the target update data for setting the target function.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of claimed invention to combine MITRA with, wherein obtaining the target update data of the second component includes: determining the target function to be set in the second component of the electronic device based on flag bit information in the first component, the flag bit information being used to record at least one function that the second component can have, the target function belonging to the at least one function recorded in the flag bit information; and obtaining the target update data for setting the target function, as taught by ASAHARA; Because customized data in the form of a configuration file used in synchronizing application features between multiple software components is a well understood method in software development. Using customized data ensures that the correct product firmware is obtained when updating software components and allows for the activation of required features without error/disruption as evidenced by, [ASAHARA, 0004] ”if the combination of product firmware and customized data is wrong, there is an issue of the occurrence of a problem in that functions in the product firmware cannot be appropriately activated.“ Additionally, MITRA provides a framework for modifying applications through updating to preserve functionality at [col 8 , lines 24-43] “sync management module 240 can begin to collect and coordinate current information regarding the various software items,… to determine whether the pending OS upgrade 260 will require modifications to any of the software programs (e.g., call for the installation of an update) in order to perform normally following the OS upgrade event.” Implementing custom data taught by ASAHARA into the information collected in MITRA would improve the likelihood of the correct update packages being selected and the settings accurately restored.
Regarding claim 7, MITRA in view of ASAHARA teaches the elements of claim 6 as outlined above. Mitra does not explicitly teach: wherein determining the target function to be set in the second component of the electronic device based on the flag bit information in the first component include:
determining the target function to be set in the second component of the electronic device based on the flag bit information and the update information.
However ASAHARA teaches: wherein determining the target function to be set in the second component of the electronic device based on the flag bit information in the first component include: determining the target function to be set in the second component of the electronic device based on the flag bit information and the update information. [0050] “In step S701, the firmware update determination unit 205 detects a firmware update request.”[0051]” In step S702, the firmware update determination unit 205 reads the firmware list file 304 that is included in the firmware set 301 to be updated, and obtains a firmware list.” [0053]”In step S704, the firmware update determination unit 205 determines whether or not it is necessary to update the firmware to be processed. The determination here is performed by comparing the firmware versions stored in the firmware version storage unit 202 to the versions of the firmware written in the firmware list obtained in step S702. Here, a case in which it is attempted to update firmware on the firmware list in FIG. 5 for the image forming apparatus 100 that is in the state of Table 2 will be described as an example. It is determined that the firmware 1 and customized data, whose versions are to be upgraded from a version “1.0” to a version “1.1”, need to be updated.” [0055] “In step S706, the customized data application unit 207 determines whether or not the firmware extracted in step S705 includes the customized data 303. In the case where the customized data 303 is included (step S706: YES), the procedure advances to step S707, [0056] In step S707, the customized data application unit 207 applies the customized data 303. Here, a case in which the customized data 303 shown in FIG. 4 is applied to the image forming apparatus 100 that is in the state of Table 1 will be described as an example. Customization for setting a setting value “1” to the setting B is written in the customized data 303. When the customized data 303 is applied, settings stored in the setting storage unit 201 become as indicated in Table 4 “)
When an update for Firmware 1 containing customized data changes the setting B , this value may be stored as a shared setting in the customized data of the setting storage unit and referenced by other Firmware for example Firmware 2 in figure 3.The updated setting such as setting B in the shared setting corresponds to the at least one target function to be set in the second component of the electronic device, the flag bit information corresponds to the existing setting in the setting storage unit which can be shared between the different firmware, and the update information is the new customized data that updates setting B.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of claimed invention to combine MITRA with, wherein determining the target function to be set in the second component of the electronic device based on the flag bit information in the first component include: determining the target function to be set in the second component of the electronic device based on the flag bit information and the update information, as taught by ASAHARA; Because using customized data ensures that the correct product firmware is obtained when updating software components and allows for the activation of required features without error/disruption as evidenced by [ASAHARA, 0004].
Regarding claim 8, MITRA in view of ASAHARA teaches the elements of claim 7 outlined above. Mitra does not explicitly teach: : wherein determining the target function to be set in the second component of the electronic device based on the flag bit information and the update information includes:
determining at least one new function added in the flag bit information of the first component, and determining the at least one new function as the target function to be set in the second component when the update information is that the first update information exists for the first component and determining at least one function recorded in the flag bit information of the first component as the target function to be set by the second component when the update information comprises second update information exists for the second component.
However ASAHARA teaches: wherein determining the target function to be set in the second component of the electronic device based on the flag bit information and the update information includes:
determining at least one new function added in the flag bit information of the first component, and determining the at least one new function as the target function to be set in the second component when the update information is that the first update information exists for the first component; ([0042]” The firmware update determination unit 205 compares the version of each firmware stored in the firmware version storage unit 202 to the version of the firmware saved in the firmware list file 304, and determines whether or not the firmware needs to be updated. For example, assume that the version of the firmware 1 is “1.0” as indicated in Table 2, and the version of the firmware 1 included in the firmware set 301 is “1.1” as shown in FIG. 5. At this time, the firmware update determination unit 205 detects that the version has been upgraded, and determines that the firmware 1 needs to be updated. Also, assume that the version of the firmware 2 is “1.0” as indicated in Table 2, and the version of the firmware 2 included in the firmware set 301 is “1.0” as indicated in FIG. 5. At this time, the firmware update determination unit 205 detects that the version has not been changed, and determines that the firmware 2 does not need to be updated. “[0044]The customized data application unit 207 applies a custom switch held by the customized data 303 to a setting value stored in the setting storage unit 201.”)
When update information exists for firmware 1 which corresponds to a first component, this update may still be paired with customized data which can store shared settings for other components on the device and thus can contain at least one new function as the at least one target function to be set in a second component when applied.
and determining at least one function recorded in the flag bit information of the first component as the target function to be set by the second component when the update information comprises second update information exists for the second component. As stated previously , because the customized data is shared between device components, an update indicating a firmware update for firmware 2 corresponding to the second component may include customized data to update a function required by firmware 2 that already exists in the customized data located in the firmware storage area and a shared reference for other firmware such as Firmware 1 which corresponds to at least one function recorded in the flag bit information of the first component as the at least one target function to be set by the second component.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of claimed invention to combine MITRA with, wherein determining the target function to be set in the second component of the electronic device based on the flag bit information and the update information includes: determining at least one new function added in the flag bit information of the first component, and determining the at least one new function as the target function to be set in the second component when the update information is that the first update information exists for the first component; and determining at least one function recorded in the flag bit information of the first component as the target function to be set by the second component when the update information comprises second update information exists for the second component, as taught by ASAHARA for similar reasons as those stated in the rejection of claim 6 above.
Regarding claim 19, it is a medium claim having similar limitations cited in the rejection of claim 6. Thus claim 19 is also rejected under the same rationale as cited in the rejection of claim 6 above.
Regarding claim 20, it is a medium claim having similar limitations cited in the rejection of claim 7. Thus claim 20 is also rejected under the same rationale as cited in the rejection of claim 7 above.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over MITRA (US10936296B2), in view of ASAHARA (US20180285091A1) hereafter ASAHARA and in further view of FISHMAN (US 20110041124 A1) hereafter FISHMAN.
Regarding claim 9, MITRA teaches the elements of claim 1 as outlined above.
MITRA does not appear to explicitly teach: , after updating the second component based on the target update data further comprising: obtaining a functional state configuration table configured by a user for the second component, the functional state configuration table including at least one candidate function that the second component needs to activate; setting the at least one candidate function in the second component to an activate state based on the functional state configuration table to cause the second component to provide or realize the target function if the at least one candidate function includes the target function storing the functional state configuration table in a storage area of the first component; in response to
However ASAHARA teaches, after updating the second component based on the target update data further comprising: obtaining a functional state configuration table configured by a user for the second component, the functional state configuration table including at least one candidate function that the second component needs to activate;
See par [0089-0091] and ( FIG.10, S1011 – S1014). ASAHARA teaches that following a firmware update, during step S1012 if the customized data application unit detects a customized data table, it is acquired by that unit. After obtaining the customized data table it is applied to the settings of the device. The customized data table contains entries which can be shared settings configured by a user within the electronic device for example, [0040] “Specific examples of the customized data include a setting for activating a function of displaying a company name and a logo on a default screen, and the like”.
setting the at least one candidate function in the second component to an activate state based on the functional state configuration table to cause the second component to provide or realize the target function if the at least one candidate function includes the target function; ([0091] “In step S1014, the customized data application unit 207 applies the customized data” ) Applying the customized data sets the feature/function to enabled to or disabled.
storing the functional state configuration table in a storage area of the first component;
([0028“The secondary storage device 104 is constituted by a large capacity storage device such as a hard disk or a RAM drive, and saves a large volume of data, holds program execution codes, and holds setting values of the image forming apparatus 100. “)
See Figures 1 and 2, The storage device of the Image apparatus holds the settings values i.e. the customized data in a shared storage area on the device which corresponds to, storing the functional state configuration table in a storage area of the first component;
in response to ([0088-0091] “In step S1011, the firmware update mode start control unit 903 changes the start mode of the image forming apparatus 100 to the normal start mode. This releases restriction on applying customized data in the image forming apparatus. In step S1012, the customized data application unit 207 detects the customized data copied in step… In step S1014, the customized data application unit 207 applies the customized data” ) See (FIG.10 step S1011 – S1014). Following the change to start mode the customized data is applied which corresponds to, in response to an instruction of the electronic device, activating the at least one candidate function in the second component through the first component based on the functional state configuration table stored in the storage area of the first component to cause the second component to provide or realize the target function and the at least one candidate function includes the target function.
Therefore, it would have been obvious to a person having ordinary skill in the art before the effective filing date of claimed invention to combine MITRA with, setting the at least one candidate function in the second component to an activate state based on the functional state configuration table to cause the second component to provide or realize the target function if the at least one candidate function includes the target function; storing the functional state configuration table in a storage area of the first component; in response to a instruction of the electronic device, activating the at least one candidate function in the second component through the first component based on the functional state configuration table stored in the storage area of the first component to cause the second component to provide or realize the target function and the at least one candidate function includes the target function; as taught by ASAHARA for similar reasons as those stated in the rejection of claim 6 above.
MITRA and ASAHARA do not explicitly teach that activating the at least one candidate function is in response to restart instruction.
However FISHMAN teaches a restart instruction and activating configurations after a restart ([0045] “The update system 116 may receive updates to a software system and may apply the updates. In some cases, the update system 116 may cause the software system to restart, the hardware system 104 to reboot, or perform other functions to complete the update.” [0048] ’’An update to the operating system may include adding new files, updating existing files, replacing existing files, or performing various configuration changes. “) Performing various configuration changes following restart serve to make applications function as intended and allow the device to apply these configurations all at once.
Thus, it would have been obvious to a person having ordinary skill in the art before the effective filing date of claimed invention to combine MITRA with after updating the second component based on the target update data further comprising: obtaining a functional state configuration table configured by a user for the second component, the functional state configuration table including at least one candidate function that the second component needs to activate; setting the at least one candidate function in the second component to an activate state based on the functional state configuration table to cause the second component to provide or realize the target function if the at least one candidate function includes the target function; storing the functional state configuration table in a storage area of the first component; in response to a restart instruction of the electronic device, activating the at least one candidate function in the second component through the first component based on the functional state configuration table stored in the storage area of the first component to cause the second component to provide or realize the target function after the electronic device is restarted and the at least one candidate function includes the target function, As taught by ASAHARA and in further view of FISHMAN because storing application settings, and activating settings within a software application following an update serves to ensure that desired user settings are implemented and persisted. In cases where a restart is required to complete an update, setting the configuration for affected programs following a restart reduces the manual effort on the user by automatically storing and activating the customized data settings. Furthermore MITRA provides motivation for a restart in Figure 3 , an available upgrade screen indicating that updates may require a restart of the device to proceed with the update.
Prior Art Made of Record
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
(US 20130254756 A1 ) METHOD AND DEVICE TO AUTOMATICALLY UPDATE A COMPUTER SYSTEM; Teaches a method for updating codependent software applications within a computer system.
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 LAWRENCE O'CONNOR EMANUEL whose telephone number is (571)272-8975. The examiner can normally be reached M-F 7:30 - 5:00 pm ( Alternate Fridays off).
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, Chat Do can be reached at (571) 272-3721. 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.
/L.S.O./Examiner, Art Unit 2193
/Chat C Do/Supervisory Patent Examiner, Art Unit 2193
