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 .
Claims 1 and 15 have been amended. Claims 1-2, 4, 7-10 and 12-16 remain pending and have been examined.
Response to Arguments/Amendments
Applicant's arguments, see pp. 8-10 filed 5/21/2026, have been fully considered but they are not persuasive.
On p. 8 of the 5/21/2026 remarks, Applicant argues that cited art of record Kazmi “does not, however, disclose or suggest use of semantic based descriptions of a training context with matchmaking against a target context to select a pre-trained control model in the manner recited in amended claim 1.” This point is agreed, as indicated in the claim rejection below.
On p. 8 of the remarks, Applicant argues that cited art of record Ranganathan “does not disclose or suggest using semantic descriptions for the context in which a model was trained, much less matching such semantic descriptions of models with semantic descriptions of a context of a building automation system to select a model to apply to the building automation system.” In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). While the rejection notes that Ranganathan teaches elements of a “context,” the reference was not fully relied upon to teach description of a “context in which the model was trained.” Instead, the rejection cites Kazmi for this limitation (e.g. see Kazmi ¶ 0053). The rejection is based upon the combination of references.
On p. 9 of the remarks, Applicant argues that cited art of record Nookula “does not describe semantic descriptions of the aspects in which ML models were trained” and “does not disclose semantic matchmaking between "aspects" of a target model deployment and "aspects" in which an existing model was trained to choose a model to upload for use in the target deployment context.” Applicant also argues that Nookula teaches away from “a system that determines which existing model will work in a new context in the manner claimed.” However, Nookula allows users to specify use case characteristics to search for a matching pre-trained model (e.g. see col. 6 lines 8-19) which applies to a broad but reasonable interpretation of the claimed limitations. Applicant’s argument is not persuasive.
On p. 9 of the remarks, Applicant argues that cited art of record Chen provides “dataset-characteristics matching” but “does not disclose or suggest using semantic descriptions of the operational context of the model (e.g., sensors/actuators/automation systems) or semantic matchmaking between a target building context and a model-training context.” In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). It should be noted that the rejection relies upon the combination of Kazmi, Ranganathan and Nookula to teach elements of semantic context matching. Chen is relied upon to teach display of a list models along with a matching score in association with a context of the model. Chen is not strictly relied upon to teach semantic matching, although Chen does generally teach matching using a “model description.” Nonetheless, the rejection does not rely upon Chen in isolation but is based upon the combination of Chen with Kazmi, Renganathan and Nookula.
Applicant continues and argues that “Chen teaches away from the claimed approach because Chen teaches a method for generating a new ML model, not an approach for selecting and uploading an existing model in a target building automation system in the manner claimed.” However, Chen teaches “Based on matching the test interaction dataset to the historical interaction datasets, the computer system selects historical machine-learning models , …” (see ¶ 0004). Chen does not teach away from the claimed limitations. Applicant’s argument is not persuasive.
On pp. 9-10 of the remarks, Applicant argues that cited art of record Summers “does not disclose or suggest creating semantic based descriptions of the training context of pre-trained evaluation/control ML models or semantic based matching of those descriptions against a target automation context to select/upload a pre-trained model for deployment.” In response to applicant's arguments against the references individually, one cannot show nonobviousness by attacking references individually where the rejections are based on combinations of references. See In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981); In re Merck & Co., 800 F.2d 1091, 231 USPQ 375 (Fed. Cir. 1986). Summers was not relied upon to teach these limitations. Instead, Kazmi, Ranganathan and Nookula were cited in support of such limitations. The rejection is based upon the combination of references.
On p. 10 of the response, Applicant argues that “it is unclear why one of ordinary skill in the art would modify the water heater system of base reference Kazmi in view of Summers to use "models are trained for controlling the brightness of a room." In response to applicant’s argument that there is no teaching, suggestion, or motivation to combine the references, the examiner recognizes that obviousness may be established by combining or modifying the teachings of the prior art to produce the claimed invention where there is some teaching, suggestion, or motivation to do so found either in the references themselves or in the knowledge generally available to one of ordinary skill in the art. See In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 1988), In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992), and KSR International Co. v. Teleflex, Inc., 550 U.S. 398, 82 USPQ2d 1385 (2007). In this case, Summer teaches that improved service and user experience extends to control of room brightness (see col. 1, lines 40-44 and col. 7, lines 13-15). Applicant’s argument is not persuasive.
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.
Claims 1-2, 4, 7-10 and 12-15 are rejected under 35 U.S.C. 103 as being unpatentable over EP Patent EP3291030 to Kazmi et al. (hereinafter "Kazmi") in view of U.S. Patent 11853401 to Nookula et al. (hereinafter "Nookula"), “Olympus: A High-Level Programming Model for Pervasive Computing Environments” by Ranganathan et al. (hereinafter “Ranganathan”), U.S. Patent Application 20190362222 by Chen et al. ("Chen") and US Patent 10/980,096 to Summers et al. (hereinafter “Summers”).
In regard to claim 1, Kazmi discloses:
A method for providing an evaluation and control model (Kazmi:¶[0047]: hot water vessel model) for controlling target building automation devices ( Kazmi:¶[0047]: hot water vessels) of a target building automation system, comprising: (Kazmi:¶[0047] This model of a hot water system can be used to simulate the state of the hot water vessel]
providing a plurality of pre-trained source evaluation and control models (Kazmi: previously learnt hot water vessel models) for controlling source building automation devices of a source building automation system (Kazmi:¶[0053] As an example, if the model for a particular type of hot water system has been learnt, then in new buildings equipped with the type of hot water system can be operated… In this case the previously learnt hot water vessel model and the temperature sensor data observed in the new building can be used to estimate the flow of hot water)
Kazmi does not expressly disclose: wherein the plurality of pre-trained source evaluation and control models are trained for controlling the brightness of a room. However, this is taught by Summers. (Summers col. 6, lines 55-63, “… the lighting configuration includes the one or more lights (or types of lights) at predefined or predetermined locations in the environment, and an initial lighting state of a given light includes an intensity and a color of the given light.” Col. 8, lines 21-30, e.g. “… lighting states for particular environments (such as a room) …”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to use Summers’ room brightness control with Kazmi’s models in order to facilitate improved service and enhance user experience as suggested by Summer (see col. 1, lines 40-44 and col. 7, lines 13-15).
Kazmi also discloses:
generating for each pre-trained source evaluation and control model (learnt model) a (semantic based) description of a context (Kazmi: operation by type of device) in which the model was trained (Kazmi:¶[0053] As an example, if the model for a particular type of hot water system has been learnt, then in new buildings equipped with the type of hot water system can be operated…) ;
generating a … description of the context (operation by type) of the target building automation system; (Kazmi: ¶[0042] the behavior of the hot water system 2 can be estimated by aggregating information from across all hot water systems of the same type);
Kazmi does not expressly disclose semantic based descriptions. Ranganathan, however, discloses using semantic based descriptions of context of entities (e.g., target automation systems, pre-trained models), and matching the “best” entity available for performing the task: (Ranganathan: section 4.4 at Page 2, Col. 1, ¶[2]: The framework makes use of ontological hierarchies and descriptions of entities to allow semantic discovery of appropriate entities. The ontological hierarchies of entities also aids the development process since developers can now browse the ontologies to see what kinds of entities are available and what kinds of constraints they can specify on these entities. Finally, the framework makes use of a utility model in order to choose the "best" entity available in a space for performing a certain kind of task, in case there are many choices.). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the method of selecting models for a building automation system of Kazmi with the semantic based description of entities of Ranganathan in order to simplify model development as disclosed e.g. at Page 2, Col. 1, ¶[2] of Ranganathan, e.g. “it takes care of resolving these virtual entities into actual Active Space entities based on constraints specified by the developer, the resources available in the current space, space level policies and the current context of the space.”
Kazmi does not expressly disclose the following limitations. However, they are taught by Summers:
wherein the context of the pre-trained source evaluation and control models includes information about a type and a placement of sensors and/or (Summers col. 7, lines 60-62, “Then, the computer may receive sensor data associated with the environment. Moreover, the computer may analyze the sensor data to determine a context associated with the environment.” Also col. 8, lines 21-30, e.g. “lighting configurations.” Also col. 23, lines 1-6, “In some embodiments, the sensor data may include: sound, sensor data associated with a wearable device, temperature measurements from a thermal sensor, a Lidar measurement, a measurement from another connected or Internet-of-things device, etc.” ) actuators and/or light sources in the room, and/or (Summers col. 6, lines 59-61, “… where the lighting configuration may include the one or more lights (or types of lights) at predefined or predetermined locations in the environment, …”) a function of the room and/or (Summers col. 27, lines 29-35, “These factors may be combined to determine activities in the environment, which in turn can trigger external connected systems and be further analyzed for patterns against time and other internal and external environmental factors. ¶ Furthermore, the identified activities and patterns can be used to train models to identify activities in the future, …”) an orientation of the room, and/or information about pre-processing of the sensor data comprising averaging or data type conversion; (Summers col. 33, lines 44-46, “This natural language feedback may be converted to numerical values before processing occurs.”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to use Summers’ context information with Kazmi’s control automation in order to facilitate improved service and enhance user experience while using a lighting system as suggested by Summers (see col. 7, lines 13-15).
Kazmi does not expressly disclose the subsequent limitations which are taught by Nookula as follows:
Nookula, also in the field of selecting machine learning models, discloses that each of the machine learning models has associated ‘aspects’ , (including as described at col. 3 lines 15-31, a type of model, a construction of the model (e.g. a number of layers) , a classifier, etc., ) the examiner interprets the ‘aspects’ of Nookula to correspond to the context of the machine learning models/ systems of the claimed invention.
Nookula further teaches:
retrieving the semantic based description of the context ( aspects) of each pre-trained source evaluation and control model of the plurality of pre-trained source evaluation and control models ; (Nookula Col. 2, lines 56-60: some embodiments provide users the ability to select machine learning “aspects” using a GUI, which can be identifiers of pre-trained learning models, identifiers of model types, individual “blocks” of ML model components such as neural network layers or nodes, hyperparameter values, etc.); and
matching the generated semantic based description of the context of the target building automation system and the description of the context in which the pretrained source evaluation and control models were trained by using a semantic matchmaking concept. (Nookula Col. 4, lines 49-57: For example, the model construction service 110 may identify the identifiers of the one or more aspects in the request, and obtain code/logic for the corresponding ML models (e.g., from a block library 112, which could store pre-trained models 113A, model portions 114A), ML model portions, etc., and configure the ML models(s) and/or model portions based on the other aspects/information – e.g., orderings, settings, hyperparameter values, etc. Also col. 6, lines 8-19, “For example, in some embodiments, a user 111 may provide use case characteristics 204 such as a type of ML model that is desired (e.g., object detection), a desired accuracy level of a resultant model, etc., which can be provided in the request issued at circle (1), allowing the model construction service 110 to identify one or multiple models (e.g., pre-trained models) meeting the use case characteristics 204 available in the block library 112 (e.g., in a collection of pre-trained models 113), and cause these matching models to be trained (and/or determine whether the trained models meet a desired output characteristic such as the accuracy).”
It would have been obvious to one of skill in the art before the effective date of the claimed invention to have combined the use of ‘aspects’ as disclosed in Nookula in the building automation system of Kazmi because it is merely use of a known technique to improve similar methods in the same way. One would be motivated to make this modification because, as disclosed at Col. 2, lines 44-48 of Nookula, it can provide users with a relatively simple yet extremely powerful GUI that allows users to construct, train, verify, examine and deploy various machine learning models, and as described at col. 3, lines 12-15, the aspects can be ordered/arranged to indicate what type of machine learning model is to be constructed.
Kazmi does not expressly disclose the following limitations. However, they are taught by Chen as follows:
wherein the pre-trained source evaluation and control models are displayed as a list on a mobile device and/or display screen, (Chen: (¶[0067] At operation 710, the computer system ranks the candidate models by performance metrics…¶[0068] At operation 712, the computer system outputs the model rankings to the GUI 201. For instance, the ML services 306 may output the ranking generated at operation 710).
wherein the list includes a matching score which corresponds to a confidence measure of the semantic matchmaking together with the context associated to the pre-trained source evaluation and control model, (Chen teaches use of a projected performance metric which can apply to a broad but reasonable interpretation of a matching score. The performance metric is presented along with a “context” including type and hyperparameters. See ¶ [0036] “The per model output fields 210 include a model description 212, a projected performance 214, and a selection option 216. The model description 212 describes the ML model and the feature-extraction rule. The ML model description identifies the type of the ML model and its hyperparameters. The projected performance 214 is the performance metric of the ML model measured by applying the ML model to the test interaction dataset uploaded via the dataset upload 204 according to the feature-extraction rule.” Also ¶ [0044] “The model ranking module 310 estimates the performance metric of this combination and compares to the performance metrics of the other combinations. The different combinations are then ranked based on their performance metrics. The model ranking module 310 outputs an output ranked model 322 of these combinations.” Also ¶[0067] At operation 710, the computer system ranks the candidate models by performance metrics…¶[0068] At operation 712, the computer system outputs the model rankings to the GUI 201. For instance, the ML services 306 may output the ranking generated at operation 710).
wherein a model displayed on the list is manually selectable or automatically selected on a basis of the matching score. (Chen: ¶ 0036, “The selection option 216 can be a button, or check box, or other field that allows for user selection of the ML model and the feature-extraction rule.” [0038] Additionally, the GUI 201 presents a run selected model(s) 230 option. This option, when selected, allows the client 103 to run the selected ML modes and feature-extraction rules on the ML server 104 for the dataset upload 204 (or another dataset upload 204) and receive the output of performing the task (e.g., predictions about whether users will open the email links or not) back from the ML server 104.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the model ranking system of Chen with the building automation method of Kazmi, Nookula and Ranganathan because as described at ¶[0062] of Chen, it helps to quickly identify the model with the best predictive performance.
Kazmi does not expressly disclose:
wherein the target building automation devices of the target building automation system comprise devices for controlling a brightness in the room. However, this is taught by Summers. (Summers: Col. 3, lines 33-39: Control hub 110 and/or the one or more lighting devices 112 may include one or more sensors … that perform measurements of sensor data in environment 100, such as acquiring or measuring: …, brightness, light color, locations of one or more objects in environment 100, etc. Also see col. 11, lines 40-48: “More generally, the information and/or the additional information may be used to control the one or more lighting devices 112, such as: which of the one or more lighting devices 112 are turned on or off, setting the brightness or intensity of the one or more lighting devices 112, setting the color (in a color space, e.g., RGB) or color temperature of the one or more lighting devices 112, creating temporal and/or spatial patterns of light, etc.”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the lighting control capabilities of Summers with the building automation method of Kazmi, Nookula and Ranganathan because as described at Col. 7, lines 6-11 of Summers, “By dynamically learning the lighting preference of the individual, these lighting techniques allow a lighting system that includes the one or more lights to appropriately adapt to and to anticipate or predict a future instance of the lighting state”.
Kazmi does not expressly disclose:
uploading the selected pre-trained source evaluation and control model, without retraining the selected model, to the target building automation system to control the target building automation devices with the selected model. This is taught by Chen. (Chen: ¶ 0038, “Additionally, the GUI 201 presents a run selected model(s) 230 option. This option, when selected, allows the client 103 to run the selected ML modes and feature-extraction rules on the ML server 104 for the dataset upload 204 (or another dataset upload 204) and receive the output of performing the task (e.g., predictions about whether users will open the email links or not) back from the ML server 104.”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to use Chen’s model upload with Kazmi’s control models in order to allow for execution of a desired performance model as suggested by Chen (see ¶ 0036).
In regard to claim 2, Kazmi discloses:
2. the method according to claim 1, wherein at least one pre-trained source evaluation and control models (Kazmi: learnt models) are obtained by training an associated source building automation system on basis of machine learning (Kazmi:¶[0053] once a model has been trained for the hot water system, it is possible to optimize the hot water system operation.) (Kazmi:¶[0022] The predetermined adaptive hot water system model is preferably formed by a general non-linear function approximation method. Sensor data is aggregated from all hot water systems belonging to the same family, and fed to the function approximation method. Optionally, real sensor data can be supplemented with data sampled from a thermodynamic model, if available.)
In regard to claim 4, Kazmi discloses:
4, the combination of Kazmi, Nookula, Ranganathan and Chen disclose the method according to claim 1, wherein differences in the context in which the pre-trained source evaluation and control model (Ranganathan: existing, pre-trained model entities) was trained and the context of the target building automation device ( Ranganathan : virtual entities defined by developer) are determined and are displayed on the mobile device and/or the display screen. (Ranganathan, Page 11, Col. 2, Sec. 4.3, ¶[1]: Developers can specify constraints that the classes and instances of the virtual entities in their program must satisfy. The constraints take the form of triples {i.e.<entity> <property> <value>). Depending on the kind of property, the constraints may be on the classes of entities or on the instances. Developers can browse the ontologies to discover ,which properties can be specified for different kinds of entities.) The examiner interprets enabling a developer to browse ontologies as requiring display of the available entities on a device. The examiner interprets the entities satisfying the triples as being those pre-trained models having a context (as defined by triples) that correspond to the context of the target entity (target building automation system) of the developer.
In regard to claim 7, Kazmi discloses:
7. the combination of Kazmi, Nookula and Ranganathan disclose the method according to claim 1, wherein a recommended modification (e.g., sensors added) of the context of the target building automation system is determined so as to improve the matching with at least one of the pre-trained source evaluation and control model of the plurality of pre-trained source evaluation and control models. (Kazmi: ¶[0009] Another consequence is accelerated learning by making diverse aspects of the HW system operation visible, i.e. a substantial reduction in time required for learning the model to estimate the behavior of this system. Therefore less sensors are required and additional or extra or specific sensors can be added to each building based on opportunity.)
In regard to claim 8, Kazmi discloses:
8. the combination of Kazmi, Nookula and Ranganathan disclose the method according to claim 1, wherein the semantic based description of the context (location) in which the pre-trained source evaluation and control model was trained is based on a graph database. ( Ranganathan, Section 4.1, Ontological hierarchies of entities: Each type of entity is associated with a hierarchy defined in an ontology) (Sec. 3.1, Ranganathan, entity types include Location) . (Ranganathan, section 8, The operator graph model [ 14] uses a programming model where services to be composed are specified as descriptions and interactions among services are defined using operators. The operator graph model [ 14] uses a programming model where services to be composed are specified as descriptions and interactions among services are defined using operators.)
In regard to claim 9, Kazmi discloses:
9. the combination of Kazmi, Nookula and Ranganathan disclose the method according to claim 1, wherein the semantic based description of the context (Location) of the target building automation system is based on a graph database. (Ranganathan page 11, Section 4.1, Ontological hierarchies of entities: Each type of entity is associated with a hierarchy defined in an ontology) (Sec. 3.1, Ranganathan, entity types include Location ) ( Ranganathan, section 8, The operator graph model [ 14] uses a programming model where services to be composed are specified as descriptions and interactions among services are defined using operators. The operator graph model [ 14] uses a programming model where services to be composed are specified as descriptions and interactions among services are defined using operators.)
In regard to claim 10, Kazmi discloses:
10. the combination of Kazmi, Nookula and Ranganathan disclose the method according to claim 1, wherein the context in which the pre-trained source evaluation and control model was trained includes user specific information comprising identification information and personal preferences. (Kazmi: ¶[0051]: In this context, the skilled person will recognize that the optimization goals can be prioritized based on user preferences and/or characteristics of the energy grid used by the hot water system.)
In regard to claim 12, Kazmi discloses:
12. The method according to claim 2, wherein all pre-trained source evaluation and control models are obtained by training an associated source building automation system on basis of machine learning. (Kazmi:¶[0022] The predetermined adaptive hot water system model is preferably formed by a general non-linear function approximation method. Sensor data is aggregated from all hot water systems belonging to the same family, and fed to the function approximation method.)
In regard to claim 13, Kazmi discloses:
13, The method according to claim 8, wherein the graph database comprises a resource description framework (RDF) or web ontology language (OWL). (Ranganathan, page 11, Sec. 4.2, “all application component classes have an OWL description that describes various semantic properties of the component such as the tasks it can perform, the classes of devices that can host it and the data-formats it can understand)
In regard to claim 14, Kazmi discloses:
14, The method according to claim 9, wherein the graph database comprises a resource description framework (RDF) or web ontology language (OWL). (Ranganathan, page 11, Sec. 4.2, “all application component classes have an OWL description that describes various semantic properties of the component such as the tasks it can perform, the classes of devices that can host it and the data-formats it can understand)
In regard to claim 15, Kazmi does not expressly disclose:
selecting one of the pre-trained source evaluation and control models based on a matching score; and However, this is taught by Chen. (Chen: ¶ 0036, “The selection option 216 can be a button, or check box, or other field that allows for user selection of the ML model and the feature-extraction rule.” [0038] Additionally, the GUI 201 presents a run selected model(s) 230 option. This option, when selected, allows the client 103 to run the selected ML modes and feature-extraction rules on the ML server 104 for the dataset upload 204 (or another dataset upload 204) and receive the output of performing the task (e.g., predictions about whether users will open the email links or not) back from the ML server 104.)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have combined the model selection of Chen with the building automation method of Kazmi, Nookula and Ranganathan because as described at ¶[0033]- [0034] of Chen, it helps to quickly identify the model with the best predictive performance.
All further limitations of claim 15 have been addressed in the rejection of claim 1 above.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Kazmi in view of Nookula, Ranganathan, Chen and Summers as applied above, and further in view of U.S. Patent Application Publication 20130063065 by Berman et al. ("Berman").
In regard to claim 16, Kazmi as modified above does not expressly disclose the claimed limitations. However, they are taught by Berman:
16. The method of claim 1, wherein pre-processing of the sensor data further comprises computing separated averaging of brightness sensors inside the room and outside a target building. (Berman: ¶ 0062, “Averaging algorithms may be employed to minimize overcompensation.” ¶ 0096, “In another aspect, one or more optical photo sensors may be located in the interior, exterior or within a structure. The photo sensors may facilitate daylight/brightness sensing and averaging for reactive protection of excessive brightness and veiling glare due to reflecting surfaces from the surrounding cityscape or urban landscape.” ¶ 0102, “The sensors may detect interior illuminance and compare this value with the average illuminance of one or more sensors looking at the window wall.” ¶ 0104, “In another embodiment, ASC 100 may employ any combination of photo sensors located on the exterior of the building and/or the interior space to detect uncomfortable light levels.” ¶ 0105, “In another embodiment, ASC 100 may be configured to detect bright overcast days and establish the appropriate window covering settings under these conditions. … Exterior sensors 125, such as photo sensors and/or radiometers, may be configured to detect these conditions. … internal photo sensors may also be helpful in determining this condition and may allow the window coverings to come down to only 50% and yet preserve the brightness and veiling glare comfort derived by illuminance ratios in the space.”). It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to use Berman’s averaging with Kazmi and Summers’ brightness sensors in order to minimize overcompensation, detect uncomfortable light levels and establish appropriate window covering settings as suggested by Berman.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 James D Rutten whose telephone number is (571)272-3703. The examiner can normally be reached M-F 9:00-5:30 ET.
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, Li B Zhen can be reached on (571)272-3768. 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.
/James D. Rutten/ Primary Examiner, Art Unit 2121
Prosecution Insights