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 .
Election/Restrictions
Applicant’s election without traverse of claims 1-17 in the reply filed on 1/28/2026 is acknowledged.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim(s) 1, 2, and 4-7 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Reshef” (US 2022/0201468) in view of “Sievers” (US 8855620).
Regarding Claim 1:
Reshef teaches:
One or more computer storage media comprising computer-executable instructions that when executed by computing device performs a method of providing calibration data for a hardware component to a computing device (Abstract; Fig. 7), the method comprising:
…
reading, at the computing device, a unique identifier (UID) from a hardware component of a first hardware type installed in the computing device (Fig. 7, step 715; ¶0031, “In an exemplary aspect, on device boot, the platform (e.g. device 201) may be configured to scan/query for connected hardware devices and/or hardware devices (e.g. modules 109) implemented therein (operation 715)”; ¶0020, “… a unique identification (ID) is embedded in each module”; ¶0023, “The system 100 may be implemented by, for example, a manufacturer of modules 109 and used during production (operation 615) of the module (e.g. chip) 109 to configure the modules 109 with appropriate identification information 102”; ¶0024, “… the configuration device 101 is configured to generate or otherwise determine identification information 102 (e.g. a unique identification (ID) of the hardware device/module 109”; ¶0033, “In this example, following the hardware scan (e.g. on boot and/or at a periodic or predetermined time), the device 201 may be configured to compare the ID (e.g. identification information 102) to the IDs registered the memory 350”; i.e., querying for a module comprising a unique identifier (ID), where the module is of a plurality of modules corresponding to chips).
identifying, at the computing device, a mismatch between the UID and a stored UID for the first hardware type (Fig. 7, step 720; ¶0032, “For each of the discovered modules 109, the device 201 may check if the discovered module(s) are registered in the device 201 (operation 720). If the discovered module is not registered, the device 201 may then download the device information 103 (e.g. required firmware; including the default parameters) based on the identification information 102 (operation 725)”; i.e., determine a mismatch when an ID of a module is not found as a registered module ID within device 201);
upon detecting … the mismatch, authorizing a calibration data update (Fig. 7, step 725; ¶0032, “… the device 201 may then download the device information 103 (e.g. required firmware; including the default parameters) based on the identification information 102 (operation 725). For example, upon connection to the network 107 (e.g. internet), the device 201 (FIG. 2) may securely access the server 108 and provide the identification information 102 to the server 108. The component/device 102 may then download a set 204 of device information 103 from the server 108 based on the identification information 102 for any or all of the applicable, connected hardware devices/components in the platform”; i.e., authorizing the downloading of configuration information for the unregistered module); and
in response to authorizing, saving a calibration data (Fig. 7, step 730; ¶0032, “The hardware devices/components may then be securely updated (operation 730) based on the downloaded parameters (e.g. device information 103) to initialize the hardware devices/components. Updated module may then be registered and their associated identification information 102 (e.g. unique IDs)”) …, to a secure memory location on the computing device (¶0033, “… the device 201 may include a memory 350 (FIG. 3) that is configured to store a registry of the hardware components of the device 201 and one or more sets (e.g. a last) of the device information 103 downloaded from the server 108”; ¶0020, “The downloaded configuration information and/or parameters then then stored in a secure storage (e.g. any platform level secure NVM)…”)
Reshef does not disclose:
detecting, at a computing device, a calibration indicator with an active status;
…
upon detecting the calibration indicator has an active status and the mismatch, authorizing a calibration data update; and
in response to authorizing, saving a calibration data associated with the calibration indicator, to … memory location on the computing device.
Sievers teaches:
detecting, at a computing device, a calibration indicator with an active status (Col. 4, lines 61-66, “At a block 110, an update flag is sent to the mobile device. The block 110 is followed by a block 112 where a request for an updated software application is received from a mobile device based on the updated flag that had been sent in the block 110”);
…
upon detecting the calibration indicator has an active status and the mismatch, authorizing a calibration data update (Claim 1 - “transmitting an update flag to the mobile device responsive to a mismatch between said first version identifier and said updated version identifier; receiving a request for the updated software application from the mobile device based on the update flag”); and
in response to authorizing, saving a calibration data associated with the calibration indicator, to a … memory location on the computing device (Claim 1 - “and, transmitting the updated software application and the unique user ID associated with the first software application to the mobile device based on the received request”).
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to modify Reshef’s system for configuring modules on a computing device by enhancing Reshef’s computing device to utilize an indicator flag, in addition to detecting a mismatch, to update a configuration for a module of the computing device, as taught by Sievers, in order to automate tracking of unregistered modules.
The motivation is to utilize an update flag for modules that require updating in order for the system to automatically recognize those modules for updating. This provides an added convenience for both administrators and end-users of the system by providing a manner to update software without requiring explicit interactions from the end-users themselves (Sievers, Col. 4, lines 62-67 & Col. 5, lines 1-3).
Regarding Claim 2:
The media of claim 1, wherein Reshef in view of Sievers further teaches the method further comprises resetting the calibration indicator to an inactive status (Official Notice: The examiner contends that one of ordinary skill in the art, before the effective filing date of the claim invention, would have recognized that upon a software update occurring on Sievers’ mobile device (Fig. 4, step 114), responsive an update flag being active on Sievers’ mobile device (Fig. 4, step 112), the update flag would be deactivated as to prevent further software updates on the mobile device from repeatedly occurring).
The motivation to reject claim 2 by applying Sievers the same motivation applied in the rejection of claim 1 above.
Regarding Claim 4:
The media of claim 1, wherein Reshef in view of Sievers further teaches the secure memory location is readable by a firmware responsible for facilitating one or more functions of the hardware component (Reshef, ¶0024, “In some aspects, the memory 111 includes both non-volatile and volatile memories. In an exemplary aspect, the memory 111 (or the hardware/firmware) may also be configured to store device information 103. In some aspects, the memory 111 (and/or hardware/firmware) may store default parameters for the module 109, which may be overwritten or updated based on the device information 103 retrieved from server 108 (see FIG. 2)”).
Regarding Claim 5:
The media of claim 1, wherein Reshef in view of Sievers further teaches the method further comprises authenticating the calibration data prior to saving the calibration data (Reshef, Col. 8A, steps 825 & 835; ¶0046, “If the device information 103 is invalid (NO at operation 825) or if a new version of the device information 103 has not been downloaded (NO at operation 822), the device 201 may use the device information 103 of the respective module 109 stored in the platform (block 812) of the device 201 and discard the corresponding downloaded device information 103 (operation 835)”).
Regarding Claim 6:
The media of claim 1, wherein Reshef in view of Sievers further teaches the calibration data is generated from a field calibration (Reshef, ¶0018, “… aspects of the disclosure may be generally applied to remote in-field configuration updates for other platforms and/or modules within a connected platform…”).
Regarding Claim 7:
The media of claim 1, wherein Reshef in view of Sievers further teaches the secure memory is one of a non-volatile memory (Reshef, ¶0017, “In system for storing and managing module and platform level regulatory constraints and capabilities, parameters and other information (e.g. per-device parameters and configurations, such as regulatory information, SKU information, or the like) may be stored in … platform level non-volatile memory (NVM)…”), a flash memory, and a trusted platform module.
Claim(s) 8 is/are rejected under 35 U.S.C. 103 as being unpatentable over “Reshef” (US 2022/0201468) in view of “Sievers” (US 8855620) in further view of “Shih” (US 2010/0199078).
Regarding Claim 8:
Reshef in view of Sievers teaches:
The media of claim 1, …
Reshef in view of Sievers does not disclose:
… wherein the hardware component is one of a screen, a camera, a speaker, and a microphone.
Shih teaches:
… wherein the hardware component is one of a screen, a camera (Fig. 6, element 600 - “IP camera device”; ¶0064, “… upload the new firmware to the IP camera device 600 for executing the firmware update program. When the IP camera device 600 completes the firmware update…”), a speaker, and a microphone.
Before the effective filing date of the claimed invention, it would have been obvious to one with ordinary skill in the art to modify Reshef in view of Sievers’ system for configuring modules on a computing device by enhancing Reshef in view of Sievers’ modules to be implemented within an IP security camera, as taught by Shih, in order to ensure commercial devices related to physical security are maintained in an updated manner.
The motivation is to implement an automated system for configuring modules into a commercial product, such as an IP security camera, to provide increased security and end-user convenience for those products, leading to an increase of monetization opportunities.
Allowable Subject Matter
Claim 3 is objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter: The cited prior art of record does not teach or suggest, either alone or in combination, the subject matter recited by claim 3 when considered in view of the subject matter recited by claim 1.
Claims 9-17 and 21-23 allowed.
The following is an examiner’s statement of reasons for allowance: The closest prior art of record being “Reshef” (US 2022/0201468) and “Sievers” (US 8855620), neither, when considered alone or in combination, teach the subject matter recited within claims 9 and 21, and thus these claims are deemed allowable. The dependent claims which further limit claims 9 and 21 are also deemed allowable by virtue of their dependency.
Any comments considered necessary by applicant must be submitted no later than the payment of the issue fee and, to avoid processing delays, should preferably accompany the issue fee. Such submissions should be clearly labeled “Comments on Statement of Reasons for Allowance.”
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to DANIEL B POTRATZ whose telephone number is (571)270-5329. The examiner can normally be reached on M-F 10 A.M. - 6 P.M. CST.
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, William Korzuch can be reached on 571-272-7589. 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.
/DANIEL B POTRATZ/Primary Examiner, Art Unit 2491