DETAILED ACTION
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
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 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.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 07/21/2026 has been entered.
Status of claims
Claims 1, 10, 16 have been amended
Claims 1-20 are pending in the instant application
Claims 1-20 are rejected in the instant application
Response to Arguments
Applicant’s arguments with respect to claims 1-20 have been considered but are not persuasive. Please see examiners response below:
Applicants Arguments:
a) “The cited portions of Poonamalli do not teach or suggest "a capability classification”… Poonamalli provides specific examples of profile information such as "manufacturer, make, model, component device profile, and SO on" that do not teach or suggest a "capability classification," as recited in claim 1. As described in the specification, the "capability classification" refers to the different levels or tiers of a particular device. Applicant respectfully submits that the profile information in the cited portions of Poonamlli is not equivalent to the levels or tiers of the instant application.
b) Applicant respectfully submits the cited references are not contended to, and do not, teach or suggest at least "populate one or more supplemental update entries for the component corresponding to at least one of a secondary component or secondary information used, by the component, to implement one or more updates, wherein the combination of the component and the at least one of the secondary component or the secondary information has a classification that is fully sufficient"…. Office Action contends that Poiesz, at paragraph 7, cures the deficiencies of Poonamalli. See id. Applicant respectfully disagrees at least because the cited portions of Poiesz are directed toward using sensor information to determine whether to implement an update, such as correlating updates with idle times or certain times of day. The use of sensor information for update installation cannot reasonably be described as using combinations of components to meet a fully sufficient classification
Examiners Response:
a) Examiner respectfully disagrees with the applicants narrowed view of the capability classification. Applicant is reminded that examiner may utilize the broadest reasonable interpretation in light of specification without bringing in the limitations from the specification. Applicant broadly states that the specification specifies tier levels, the claims however are silent on this feature. Examiner maintains his interpretation as classification of components within a device or device capabilities. Poonamalli further goes into details of how these capabilities are separate and how they are updated. Applicant is invited to clarify the claims by defining the capability classification clearly. For clarity of the record as well, the terms less than fully sufficient and fully sufficient are broad and are being interpreted by the examiner as ‘requires updates’ ie not fully sufficient and ‘updated’ ie fully sufficient.
b) Examiner again respectfully disagrees with the applicants arguments with regards to supplementing updates for secondary components for fully sufficiency. Poiesz is utilized to highlight clearly updating components of a computing device based on a weighted combination of inputs [secondary component or secondary information used, by the component, to implement one or more updates]. These updates are carried out until successfully implemented ie fully sufficient components on the device per the update ¶0046. As such examiner asks again for clarity/scope from the applicant in how they would define ‘fully sufficient’ ‘not fully sufficient’ without utilizing broad terminology claims and arguing a limited scope. Examiner maintains his rejection and has updated the rejection based on the amendments filed 7/21/2026. Claims 10, 16 and dependent claims remain rejected per the same responses highlighted above.
USC 112(b) rejections regarding claims 16-20 regarding 112(b) have been withdrawn per the amendments and arguments filed in the instant application.
Examiner kindly suggests prior to filing a response, the applicant set up a formal interview with the examiner such that details about specific limitations can be clarified and the inventive concept clearly defined.
Claim Rejections - 35 USC § 103
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.
Claims 1-6, 9-13, 15-20 are rejected under 35 U.S.C. 103 as being unpatentable over Poonamalli et al. (US20150339117A1) hereinafter Poonamalli in view of Poiesz et al. (US20150248284A1) hereinafter Poiesz.
Regarding claim 1. Poonamalli teaches a processor comprising:
one or more circuits to:
identify a component installed within a platform (¶0033 device profile module 118 can include a variety of other information, such as identifiers for the component devices 104);
determine, based on one or more component properties, a capability classification for the component (¶0036 the computing device authorities 126 can tailor the update targeting information 128 to specify custom update configurations for various types and/or classifications of computing devices and ¶0038 the computing device authority 200 is the manufacturer “Acme,” which manufactures several models of a “Dale” computer, including the model “XC1101.” For this particular device profile, the update targeting information 202 specifies particular mappings of component devices to device driver versions);
generate an index entry for the component, including at least an identifier and the capability classification (Fig.2 and ¶0038 mapping of update targeting information to the update groups 1 and ¶0051 profile information can be considered as well, such as component device identifiers, software identifiers, firmware identifiers, basic input/output system (BIOS) identifiers, and so forth);
determine the capability classification is less than fully sufficient (¶0057 changes in computing device profile information associated with particular updates can be changed in the update targeting information.);
and
store the index entry and one or more supplemental update entries for the component (Fig.2 and ¶0038 mapping of update targeting information to the update groups 1)
Poonamalli teaches populate one or more supplemental update entries for the component (¶0057 The changes in the update targeting information 128 can be propagated to the update service 112, which can make corresponding changes to the update groups 1. Thus, when a computing device affected by the changes in the device profile information queries for updates, the computing device may be reassigned to a different update group 1)
Poonamalli however does not explicitly teach component corresponding to at least one of a secondary component or secondary information used, by the component, to implement or more updates, wherein the combination of the component and the at least one of the secondary component or the secondary information has a classification that is fully sufficient
Poiesz however in the same field of computer networking teaches component corresponding to at least one of a secondary component or secondary information used, by the component, to implement or more updates (¶0007 see updating components on a computing device. The system may include a means for receiving, at a computing device, a notification of an update corresponding to an existing component on the computing device. Additionally, the system may further include a means for, responsive to receiving the notification, receiving inputs from a plurality of sensors of the computing device, and the inputs provide information indicative of a given state of use, time of day, and location associated with the computing device. The system may also include a means for, based on a weighted combination of the inputs, determining whether to update the existing component on the computing device, and based on the determination, a means for updating the existing component) wherein the combination of the component and the at least one of the secondary component or the secondary information has a classification that is fully sufficient (¶0060 parameters may be utilized by a computing device for determining when to initiate an update and/or complete the update process. For example, the computing device may determine based on some parameters that initiating an update process is proper at a given time, but may further determine stopping the update process temporarily based on other parameters [parameters determine if the updates are complete ie fully sufficient]);
Accordingly, it would have been obvious to one of ordinary skill in the art of computer networking at the effective filing date of the claimed invention given the updates of Poonamalli and the teachings of Poiesz for using component corresponding to at least one of a secondary component or secondary for updates to combine the teachings such that Poonamalli utilizes the components prior to updating software. One of ordinary skill in the art would recognize that the results of the combination are predictable because each element in the combination is merely performing the same function it would perform separately. One would be motivated to combine these teachings because doing so will automate component update process (¶0018 Poiesz).
Regarding claim 2. Poonamalli teaches the processor of claim 1, wherein the capability classification includes at least one of partially sufficient, supplicant, fully dependent, or virtual (Poonamalli ¶0035 see the update service 112 can coordinate propagation of an update (e.g., via upload and/or download) directly from an update authority 120 to the computing device 102. Thus, the update service 112 can store drivers and/or updates locally on the service for propagation to various computing devices, and/or the update service 112 can serve as a broker for enabling appropriate updates to be propagated to various computing devices, e.g., directly from the update authorities 120).
Regarding claim 3. Poonamalli teaches the processor of claim 1, wherein the one or more circuits are further to:
receive a firmware update request for the component (Poonamalli ¶0006 see computing device can provide profile information for the computing device, such as an identifier of a manufacturer for the computing device, a make identifier for the computing device, a model identifier, and so forth. The update service can inspect the profile information, and can match the profile information to a corresponding update group.);
determine, using the index entry, the capability classification (Poonamalli Fig 2 ¶0038 see a mapping of update targeting information to the update groups 116, generally at 200. In the upper portion, a computing device authority 200 specifies update targeting information 202. For example, the computing device authority 200 is the manufacturer “Acme,” which manufactures several models of a “Dale” computer, including the model “XC1101.” For this particular device profile, the update targeting information 202 specifies particular mappings of component devices to device driver versions, e.g., Device1 corresponds to a Driver version);
determine, based at least on the capability classification, that the firmware update will use the one or more supplemental update entries (Poonamalli ¶0051 see matches the profile information to an update group. For example, a manufacturer, make, and/or model indicated by the profile information can be matched to one of the update groups 116 that specifies the same manufacturer, make, and/or model. Other profile information can be considered as well, such as component device identifiers, software identifiers, firmware identifiers, basic input/output system (BIOS) identifiers); and
cause the firmware update to execute using the one or more supplemental update entries (Poonamalli ¶0048 see If an update is available (“Yes”), step 304 receives the update).
Regarding claim 4. Poonamalli teaches the processor of claim 1, wherein the capability classification is associated with an on-component capability to perform at least one of a protection operation, a detection operation, or a recovery operation (Poonamalli ¶0034 see Update authorities 120 are further illustrated, which are representative of entities that can issue various types of updates. Examples of the update authorities [capability class] 120 include device manufacturers (e.g., for the component devices 104), software developers (e.g., for the applications 108), and/or other entities that can develop and/or issue updates for various components and functionalities. For example, the update authorities 120 can generate driver updates 122, which are representative of drivers that can be used to update the device drivers 106. The update authorities 120 can also generate software updates 124, which are representative of updates for the applications 108 and/or other software).
Regarding claim 5. Poonamalli teaches the processor of claim 1, wherein the one or more circuits are further to:
receive a firmware update request for the component (Poonamalli ¶0050 see Step 400 receives a query for updates that includes profile information for a computing device);
determine the capability classification corresponds to a partially sufficient component (Poonamalli ¶0050 see update service 112, for instance, can receive a query from the update module 110 asking whether updates to various functionalities of the computing device 102 are available. The query can include profile information for the computing device 102, such as a manufacturer, make, model, and so forth); and
retrieve update information from one or more off-component memory locations (Poonamalli Fig 4 element 406 ¶0054 see step 406 causes the update to be propagated to the computing device.).
Regarding claim 6. Poonamalli further teaches the processor of claim 1,
wherein the one or more circuits are further to:
receive a firmware update request for the component (Poonamalli Fig 4. - ¶0050 see receives a query for updates that includes profile information for a computing device);
determine the capability classification corresponds to a supplicant component (Poonamalli ¶0051 see Step 402 matches the profile information to an update group. For example, a manufacturer, make, and/or model indicated by the profile information can be matched to one of the update groups 116 that specifies the same manufacturer, make, and/or model);
validate the firmware update using one or more off-component services (Poonamalli ¶0053 see Step 404 ascertains whether an update is available for the update group. The update service 112, for instance, can ascertain that an update has been made available to the update group subsequent to a previous update session between the update service and the computing device 102); and
retrieve update information from one or more off-component memory locations (Poonamalli ¶0054 see If an update is available (“Yes”), step 406 causes the update to be propagated to the computing device. The update, for instance, can be downloaded to the computing device 102 from the update service 112 and/or one of the update authorities 120).
Regarding claim 9. Poonamalli teaches the processor of claim 1, wherein the processor is comprised in at least one of:
a system for performing simulation operations; a system for performing simulation operations to test or validate autonomous machine applications; a system for performing digital twin operations; a system for performing light transport simulation; a system for rendering graphical output; a system for performing deep learning operations; a system implemented using an edge device; a system for generating or presenting virtual reality (VR) content; a system for generating or presenting augmented reality (AR) content; a system for generating or presenting mixed reality (MR) content; a system incorporating one or more Virtual Machines (VMs); a system for performing operations for a conversational AI application; a system for performing operations for a generative AI application; a system for performing operations using a language model; a system for performing one or more generative content operations using a large language model (LLM); a system implemented at least partially in a data center; a system for performing hardware testing using simulation; a system for performing one or more generative content operations using a language model; a system for synthetic data generation; a collaborative content creation platform for 3D assets; or a system implemented at least partially using cloud computing resources (Poonamalli ¶0080 see the central computing device may be a cloud of one or more server computers that are connected to the multiple devices through a network).
Regarding claim 10. Poonamalli teaches a computer-implemented method (¶0087: methods that may be implemented to perform techniques discussed herein), comprising:
receiving a firmware (FW) update request associated with a component forming at least part of a platform (¶0006: a computing device can query an update service for available updates. and ¶0005: firmware updates);
determining one or more capabilities associated with the component (¶0036: the computing device authorities 126 can tailor the update targeting information 128 to specify custom update configurations for various types and/or classifications of computing devices and ¶0038: the computing device authority 200 is the manufacturer “Acme,” which manufactures several models of a “Dale” computer, including the model “XC1101.” For this particular device profile, the update targeting information 202 specifies particular mappings of component devices to device driver versions);
obtaining, based at least on an identifier associated with the component, the supplemental update information (¶0057: The changes in the update targeting information 128 can be propagated to the update service 112, which can make corresponding changes to the update groups 116. Thus, when a computing device affected by the changes in the device profile information queries for updates, the computing device may be reassigned to a different update group 116. And Fig.2 and ¶0038: mapping of update targeting information to the update groups 116 and ¶0051: profile information can be considered as well, such as component device identifiers, software identifiers, firmware identifiers, basic input/output system (BIOS) identifiers, and so forth.); and
causing a FW update associated with the FW update request to be installed for the component using, at least, a combination of the one or more capabilities associated with the component and the supplemental update information (¶0036: the computing device authorities 126 can tailor the update targeting information 128 to specify custom update configurations for various types and/or classifications of computing devices..¶0082 see Each of these configurations includes devices that may have generally different constructs and capabilities, and thus the computing device 702 may be configured according to one or more of the different device classes…¶0057: changes in computing device profile information associated with particular updates can be changed in the update targeting information).
Poonamalli teaches determining, based at least on the one or more capabilities, supplemental update information for the component and the FW update request (¶0057: changes in computing device profile information associated with particular updates can be changed in the update targeting information.)
Poonamalli however does not explicitly teach component including to at least one of a secondary component or secondary information associated with the request
Poiesz however in the same field of computer networking teaches component including to at least one of a secondary component or secondary information associated with the request (¶0007 see updating components on a computing device. The system may include a means for receiving, at a computing device, a notification of an update corresponding to an existing component on the computing device. Additionally, the system may further include a means for, responsive to receiving the notification, receiving inputs from a plurality of sensors of the computing device, and the inputs provide information indicative of a given state of use, time of day, and location associated with the computing device. The system may also include a means for, based on a weighted combination of the inputs, determining whether to update the existing component on the computing device, and based on the determination, a means for updating the existing component)
Accordingly, it would have been obvious to one of ordinary skill in the art of computer networking at the effective filing date of the claimed invention given the updates of Poonamalli and the teachings of Poiesz for using component corresponding to at least one of a secondary component or secondary for updates to combine the teachings such that Poonamalli utilizes the components prior to updating software. One of ordinary skill in the art would recognize that the results of the combination are predictable because each element in the combination is merely performing the same function it would perform separately. One would be motivated to combine these teachings because doing so will automate component update process (¶0018 Poiesz).
Regarding claim 11. Poonamalli further teaches the computer-implemented method of claim 10, further comprising:
receiving a second FW update request for a second component forming at least part of the platform (Poonamalli ¶0050 see Step 400 receives a query for updates that includes profile information for a computing device. The update service 112, for instance, can receive a query from the update module 110 asking whether updates to various functionalities of the computing device 102 are available. The query can include profile information for the computing device 102, such as a manufacturer, make, model, and so forth [process works on multiple computing devices as can be seen in Fig 2]);
determining one or more second capabilities associated with the second component (Poonamalli ¶0051 see Step 402 matches the profile information to an update group. For example, a manufacturer, make, and/or model indicated by the profile information can be matched to one of the update groups 116 that specifies the same manufacturer, make, and/or model. Other profile information can be considered as well, such as component device identifiers, software identifiers, firmware identifiers, basic input/output system (BIOS) identifiers, and so forth); and
determining the one or more second capabilities define the second component as a fully sufficient component (Poonamalli ¶0053 see Step 404 ascertains whether an update is available for the update group. The update service 112, for instance, can ascertain that an update has been made available to the update group subsequent to a previous update session between the update service and the computing device 102); and
causing the FW update to be installed for the component (Poonamalli ¶0054 see If an update is available (“Yes”), step 406 causes the update to be propagated to the computing device. The update, for instance, can be downloaded to the computing device 102 from the update service 112 and/or one of the update authorities 120).
Regarding claim 12. Poonamalli teaches the computer-implemented method of claim 10,
wherein the one or more capabilities are associated with at least a protection operation, a detection operation, or a recovery operation (Poonamalli ¶0034 see Update authorities 120 are further illustrated, which are representative of entities that can issue various types of updates. Examples of the update authorities [capability class] 120 include device manufacturers (e.g., for the component devices 104), software developers (e.g., for the applications 108), and/or other entities that can develop and/or issue updates for various components and functionalities. For example, the update authorities 120 can generate driver updates 122, which are representative of drivers that can be used to update the device drivers 106. The update authorities 120 can also generate software updates 124, which are representative of updates for the applications 108 and/or other software)
Regarding claim 13. Poonamalli further teaches computer-implemented method of claim 10, further comprising:
defining a capability level for the component, the capability level including at least one of fully sufficient, partially sufficient, supplicant, fully dependent, and virtual (Poonamalli ¶0035 see the update service 112 can coordinate propagation of an update (e.g., via upload and/or download) directly from an update authority 120 to the computing device 102. Thus, the update service 112 can store drivers and/or updates locally on the service for propagation to various computing devices, and/or the update service 112 can serve as a broker for enabling appropriate updates to be propagated to various computing devices, e.g., directly from the update authorities 120).
Regarding claim 15. Poonamalli further teaches the computer-implemented method of claim 10, further comprising:
identifying a new component associated with the platform; receiving validation information associated with the new component; and generating an index entry for the new component, including at least an identifier and a new component capability classification (Poonamalli ¶0046 see update module 110 can query the device profile module 118 for profile information for the computing device 102. As referenced above, the profile information can include a manufacturer, make, and/or model of a computing device. The profile information can also include other information, such as identifiers for the component devices 104, identifiers for the applications 108, identifiers for other functionalities of the computing device 102 (e.g., a firmware version), and so on – see Fig 2 as well – [examiners note: adding data/entries into authorities is commonly understood feature to add data into tables]).
Regarding claim 16. Poonamalli teaches a system, comprising:
one or more processing units (¶0070: processing system 704 is illustrated as including hardware element 710 that may be configured as processors) to determine a component capability level responsive to receiving an update request for a component (¶0006 : a computing device can query an update service for available updates and ¶0005: firmware updates and ¶0081: Each of the multiple devices may have different physical requirements and capabilities and Fig.2 and ¶0038: mapping of update targeting information to the update groups 116 and ¶0051: profile information can be considered as well, such as component device identifiers, software identifiers, firmware identifiers, basic input/output system (BIOS) identifiers, and so forth.) and to obtain, based at least on the component capability level and index information for the component, supplemental update information to perform the update (¶0057: changes in computing device profile information associated with particular updates can be changed in the update targeting information.)
Poonamalli does not explicitly teach including at least one of a secondary component or secondary information used, wherein the combination of the component and the at least one of the secondary component or the secondary information has a classification that is fully sufficient
Poiesz however in the same field of computer networking teaches including at least one of a secondary component or secondary information used (¶0007 see updating components on a computing device. The system may include a means for receiving, at a computing device, a notification of an update corresponding to an existing component on the computing device. Additionally, the system may further include a means for, responsive to receiving the notification, receiving inputs from a plurality of sensors of the computing device, and the inputs provide information indicative of a given state of use, time of day, and location associated with the computing device. The system may also include a means for, based on a weighted combination of the inputs, determining whether to update the existing component on the computing device, and based on the determination, a means for updating the existing component) wherein the combination of the component and the at least one of the secondary component or the secondary information has a classification that is fully sufficient (¶0060 parameters may be utilized by a computing device for determining when to initiate an update and/or complete the update process. For example, the computing device may determine based on some parameters that initiating an update process is proper at a given time, but may further determine stopping the update process temporarily based on other parameters [parameters determine if the updates are complete ie fully sufficient]);
Accordingly, it would have been obvious to one of ordinary skill in the art of computer networking at the effective filing date of the claimed invention given the updates of Poonamalli and the teachings of Poiesz for using component corresponding to at least one of a secondary component or secondary for updates to combine the teachings such that Poonamalli utilizes the components prior to updating software. One of ordinary skill in the art would recognize that the results of the combination are predictable because each element in the combination is merely performing the same function it would perform separately. One would be motivated to combine these teachings because doing so will automate component update process (¶0018 Poiesz).
Regarding claim 17. Poonamalli further teaches system of claim 16,
wherein the component capability level corresponds to an ability of the component to execute at least one of a protection operation, a detection operation, or a recovery operation using on-component resources (Poonamalli ¶0034 see Update authorities 120 are further illustrated, which are representative of entities that can issue various types of updates. Examples of the update authorities [capability class] 120 include device manufacturers (e.g., for the component devices 104), software developers (e.g., for the applications 108), and/or other entities that can develop and/or issue updates for various components and functionalities. For example, the update authorities 120 can generate driver updates 122, which are representative of drivers that can be used to update the device drivers 106. The update authorities 120 can also generate software updates 124, which are representative of updates for the applications 108 and/or other software)
Regarding claim 18. Poonamalli further teaches system of claim 16,
wherein the component capability level corresponds to one of fully sufficient, partially sufficient, supplicant, fully dependent, and virtual (Poonamalli ¶0035 see the update service 112 can coordinate propagation of an update (e.g., via upload and/or download) directly from an update authority 120 to the computing device 102. Thus, the update service 112 can store drivers and/or updates locally on the service for propagation to various computing devices, and/or the update service 112 can serve as a broker for enabling appropriate updates to be propagated to various computing devices, e.g., directly from the update authorities 120).
Regarding claim 19. Poonamalli further teaches system of claim 16,
wherein the index information is populated by a platform manufacturer and is rooted within a resilience engine of a platform including the component (Poonamalli ¶0036 see computing device authorities 126, which are representative of entities that can make various update decisions for computing devices. For example, the computing device authorities 126 can include an OEM for the computing device 102. The computing device authorities 126 maintain update targeting information 128, which specifies update information and statuses for particular classes and/or categories of computing devices. For instance, the computing device authority 126 can generate update targeting information 128 that specifies that computing devices that meet a particular profile (e.g., manufacturer, make, model, component device profile, and so on) are to receive particular updates, and/or are not to receive other updates. Thus, the computing device authorities).
Regarding claim 20. Poonamalli further teaches the system of claim 16,
wherein supplemental update information includes at least one of a validation key, a measurement operation, or an off-component storage location (Poonamalli ¶0085 see The cloud 720 includes and/or is representative of a platform 722 for resources 724. The platform 722 abstracts underlying functionality of hardware (e.g., servers) and software resources of the cloud 720. The resources 724 may include applications and/or data that can be utilized while computer processing is executed on servers that are remote from the computing device 702)
Claims 7, 8, 14 are rejected under 35 U.S.C. 103 as being unpatentable over Poonamalli-Poiesz in view of Klische (US2018/0336024A1) Klische.
Regarding claim 7. Poonamalli-Poiesz teaches the processor of claim 1,
wherein the one or more circuits are further to:
receive, from an authority associated with the platform, updated parameters for the component (Poonamalli Fig 6 element 600 | ¶0034 see Update authorities 120 are further illustrated, which are representative of entities that can issue various types of updates. Examples of the update authorities 120 include device manufacturers (e.g., for the component devices 104), software developers (e.g., for the applications 108), and/or other entities that can develop and/or issue updates for various components and functionalities);
update the index entry based on the updated parameters for the component (Poonamalli ¶0007 see Update information associated with the corresponding update group can be synchronized with the computing device. For instance, updates associated with the corresponding update group can be propagated to the computing device).
Poonamalli-Poiesz does not explicitly teach authenticate the authority
Klische however in the same field of computer networking teaches authenticate the authority (¶0049 see Before the software is placed into each update package, in accordance with one embodiment of the present disclosure the software update packager 210 may authenticate the provider of the software update. This may be done by verifying the signing certificate associated with the software update to ensure it was signed by the expected entity)
Accordingly, it would have been obvious to one of ordinary skill in the art of computer networking at the effective filing date of the claimed invention given the computing authority of Poonamalli and the teachings of Klische for authenticating the computing authority to combine the teachings such that Poonamalli authenticates the computing authority prior to updating software. One of ordinary skill in the art would recognize that the results of the combination are predictable because each element in the combination is merely performing the same function it would perform separately. One would be motivated to combine these teachings to ensure the proper functioning of the components (¶0027 Klische).
Regarding claim 8. The already combined references teach the processor of claim 7,
Poonamalli further teaches wherein the authority is at least one of a manufacturer of the platform or an owner of the platform (Poonamalli ¶0034 see Update authorities 120 are further illustrated, which are representative of entities that can issue various types of updates. Examples of the update authorities 120 include device manufacturers (e.g., for the component devices 104), software developers (e.g., for the applications 108), and/or other entities that can develop and/or issue updates for various components and functionalities)
Regarding claim 14. Poonamalli-Poiesz teaches the computer-implemented method of claim 10, further comprising:
receiving, from an authority associated with the platform, updated parameters for the component (Poonamalli Fig 6 element 600 | ¶0034 see Update authorities 120 are further illustrated, which are representative of entities that can issue various types of updates. Examples of the update authorities 120 include device manufacturers (e.g., for the component devices 104), software developers (e.g., for the applications 108), and/or other entities that can develop and/or issue updates for various components and functionalities);
updating an index entry corresponding to the component based on the updated parameters for the component (Poonamalli ¶0007 see Update information associated with the corresponding update group can be synchronized with the computing device. For instance, updates associated with the corresponding update group can be propagated to the computing device).
Poonamalli-Poiesz does not explicitly teach authenticate the authority
Klische however in the same field of computer networking teaches authenticate the authority (¶0049 see Before the software is placed into each update package, in accordance with one embodiment of the present disclosure the software update packager 210 may authenticate the provider of the software update. This may be done by verifying the signing certificate associated with the software update to ensure it was signed by the expected entity)
Accordingly, it would have been obvious to one of ordinary skill in the art of computer networking at the effective filing date of the claimed invention given the computing authority of Poonamalli and the teachings of Klische for authenticating the computing authority to combine the teachings such that Poonamalli authenticates the computing authority prior to updating software. One of ordinary skill in the art would recognize that the results of the combination are predictable because each element in the combination is merely performing the same function it would perform separately. One would be motivated to combine these teachings to ensure the proper functioning of the components (¶0027 Klische).
Conclusion
.
References are cited not only for their quoted language but for all that they teach.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Atta Khan whose telephone number is 571-270-7364. The examiner can normally be reached on M-F 09:00-6:00.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Vivek Srivastava can be reached on (571) 272-7304. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/ATTA KHAN/
Examiner, Art Unit 2449
Prosecution Insights