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 Final Office Action is responsive to Applicant's amendment filed on 12 December 2025. Applicant’s amendment on 12 December 2025 amended Claims 6, and 18-20. Currently Claims 1-20 are pending and have been examined. The Examiner notes that the 101 rejection has been maintained.
Response to Arguments
Applicant's arguments filed 12 December 2025 have been fully considered but they are not persuasive.
The Applicant argues on pages 8 and 10 that with respect to claims 18 and 20 “Page 4 of the Office Action states "The claim recites the additional element(s): receiving data, and providing a timeline." Page 4 of the Office Action also indicates that, on the other hand, it was the "aggregating, filtering, and generating steps" which recite the alleged abstract idea to which the "receiving" and "providing" steps were additional. The Office Action therefore explicitly acknowledges that the "receiving" and "providing" are not themselves mental processes. Applicant agrees with that treatment, at least on the grounds that such steps cannot be practically performed in the human mind. For example, a human cannot mentally provide a timeline on a graphical user interface and or other details of such a graphical user interface, because a person does not have the mental ability to control a graphical user interface. The human mind is also not capable of receiving data from a plurality of separate building applications, and data gathering steps have conventionally been treated as additional to any abstract idea shown in a claim. For example, MPEP 2106.05(g) lays out reasons to find data gathering steps to be insignificant additions to judicial exceptions because such data gathering cannot itself to be treated as recitation of a judicial exception. Therefore, neither the "receiving" nor the "providing" steps remaining in amended Claim 18 recites an abstract idea and only features that the Office Action characterized as not themselves being abstract ideas remaining in Claim 18.
Claim 18 therefore does not recite a judicial exception under Step 2A, Prong 1.
In view of questions in the interview and because MPEP 2106.05(g) is mentioned above, Applicant reminds the Examiner that a finding that no judicial exception is recited in a claim under Step 2A, Prong 1 means that the subject-matter eligibility analysis ends there with a finding of eligibility. There is no need to move on to the tests under Step 2A, Prong 2 or Step 2B with respect to whether a limitation is mere data gathering, "apply it," or a generic computer, etc. If a claim does not recite a judicial exception under Step 2A, Prong 1, it is patent-eligible.
Lastly, Applicant points the Examiner to guidance confirming that Examiners should assess only the features that are actually recited in a claim when assessing whether the claim recites a judicial exception, as set out in the August 4, 2025 memo with the subject line "Reminders on evaluating subject matter eligibility of claims under 35 U.S.C. 101." Accordingly, here, even if a mental process could hypothetically be used in some way together with the claim limitations of Claim 18 so as to "involve" an exception, the guidance is clear that the claim remains patent-eligible. Independent Claim 18 is therefore patent-eligible. Withdrawal of the rejection of Claim 18 is respectfully requested.
The Examiner respectfully disagrees.
In response to the arguments the Examiner notes that the Applicant's argument that amended Claim 18 does not recite a judicial exception under Step 2A, Prong One is not persuasive. Applicant's argument rests on the premise that because the previous Office Action characterized the "receiving" and "providing" steps as additional elements rather than part of the abstract idea, and because amended Claim 18 has purportedly removed the "aggregating, filtering, and generating steps," the claim no longer recites a judicial exception. This characterization misapprehends both the scope of amended Claim 18 and the proper application of the eligibility analysis.
Turning to the actual language of amended Claim 18, the claim recites "receiving from a plurality of separate building applications; a data represent a plurality of events associated with a building site over a lifecycle of the building site; providing on a graphical user interface, a timeline comprising event markers representing a plurality of isolated events filtered from the data, the event markers spatially arranged along the timeline based on times associated with the isolated events." The claim explicitly recites that the timeline comprises event markers representing "isolated events filtered from the data" and that the event markers are "spatially arranged along the timeline based on times associated with the isolated events." These limitations necessarily encompass the mental processes of filtering data to identify isolated events and arranging or organizing those events based on their associated times. The filtering and arranging concepts have not been removed from Claim 18; rather, they have been incorporated into the "providing" limitation in a different grammatical form. A claim does not avoid reciting an abstract idea merely by expressing mental process steps as characteristics of the output rather than as discrete method steps.
Applicant's reliance on Example 39 from the USPTO's Subject Matter Eligibility Examples is misplaced. In Example 39, the claim limitation "training the neural network in a first stage using the first training set" was found not to recite a judicial exception because it did not set forth or describe any mathematical relationships, calculations, formulas, or equations. The analysis turned on the fact that "training a neural network," while it may involve mathematical concepts in its implementation, does not itself recite those mathematical concepts. Here, by contrast, Claim 18 does recite the abstract concepts at issue. The claim explicitly recites that events are "filtered from the data" and that event markers are "spatially arranged along the timeline based on times associated with the isolated events." These are not limitations that merely involve abstract ideas in their implementation while reciting something else; these limitations directly recite the concepts of filtering data and arranging information based on temporal criteria, which are mental processes that can be performed in the human mind with the aid of pen and paper.
Applicant's citation to the August 4, 2025 memorandum regarding the distinction between claims that "recite" an exception versus claims that merely "involve" an exception does not change this analysis. The memorandum instructs examiners to assess the features actually recited in a claim. As set forth above, Claim 18 actually recites filtering and arranging operations within its limitations. The claim does not merely involve these concepts in some unstated implementation detail; it expressly claims them as part of what is provided on the graphical user interface.
Furthermore, Applicant's assertion that a human cannot mentally "provide a timeline on a graphical user interface" conflates the abstract idea analysis with the additional elements analysis. The Examiner does not contend that displaying information on a GUI is itself an abstract idea. Rather, the underlying concepts of filtering data to identify relevant events and organizing those events chronologically are mental processes. The fact that these mental processes are ultimately displayed on a GUI does not negate the recitation of the abstract idea; it merely reflects how the results of the mental process are output. Under Applicant's reasoning, any abstract idea could be rendered patent-eligible simply by reciting that its results are displayed on a screen, which is contrary to established precedent.
For the foregoing reasons, Claim 18 recites an abstract idea under Step 2A, Prong One, and the eligibility analysis must proceed to Step 2A, Prong Two. The rejection of Claim 18 is maintained.
The Applicant argues on page 11 " Page 6 of the Office Action states that Claim 19 recites "claim language viewed as insignificant extra solution activity," which is an acknowledgement that Claim 19 does not itself recite a judicial exception. Claim 19 is therefore patent-eligible under Step 2A, Prong 1 for the same reasons as discussed above with respect to Claim 18”.
The Examiner respectfully disagrees.
In response to the arguments in the Examiner notes that the Applicant's argument that claim 19 does not recite a judicial exception under Step 2A, Prong One is not persuasive. As an initial matter, Claim 19 depends from Claim 18 and therefore incorporates all limitations of Claim 18. As set forth in the response to Argument 1, Claim 18 recites an abstract idea in the form of mental processes, specifically the filtering of data to identify isolated events and the arranging of those events based on their associated times. Because Claim 19 incorporates these limitations by dependency, claim 19 also recites a judicial exception under Step 2A, Prong One.
Applicant mischaracterizes the Office Action's treatment of Claim 19. The Office Action's statement that claim 19 recites "claim language viewed as insignificant extra solution activity" is not an acknowledgement that Claim 19 does not recite a judicial exception. Rather, this statement addresses the additional limitation recited in Claim 19 beyond those inherited from Claim 18. The proper analytical framework requires first identifying whether a claim recites a judicial exception (Step 2A, Prong One), then evaluating whether any additional elements integrate the exception into a practical application (Step 2A, Prong Two), and if not, whether the additional elements provide an inventive concept (Step 2B). The characterization of a limitation as "insignificant extra-solution activity" pertains to the Step 2A, Prong Two and Step 2B analyses regarding additional elements, not to the Step 2A, Prong One inquiry regarding whether a judicial exception is recited.
The additional limitation of Claim 19 recites "automatically causing, based on the data relating to the building site, an intervention at the building site to affect building health and adding the intervention to the timeline on the graphical user interface." The Office Action's characterization of this limitation as insignificant extra-solution activity reflects an evaluation of whether this additional element integrates the abstract idea into a practical application or provides significantly more than the abstract idea. It does not constitute a finding that the claim as a whole fails to recite a judicial exception. A dependent claim that adds additional elements to a claim reciting a judicial exception still recites that judicial exception by virtue of its dependency.
Applicant's assertion that claim 19 is patent-eligible under Step 2A, Prong One "for the same reasons as discussed above with respect to Claim 18" is unavailing because, as explained in response to Argument 1, Claim 18 does recite a judicial exception. The same conclusion applies to Claim 19.
For the foregoing reasons, Claim 19 recites an abstract idea under Step 2A, Prong One through its incorporation of the limitations of Claim 18, and the rejection of Claim 19 is maintained.
The Applicant argues on page 11 "Page 3 of the Office Action states that "as drafted, the claim recites the limitation of determining a timeline that includes installation and service activities." However, none of the words "determining," "includes," "installation," "service," or "activities" appear in Claim 1. Page 3 also states that "other than reciting a processor…", but Claim 1 does not recite a "processor." It therefore appears that something other than what is actually recited in Claim 1 was examined and rejected in the Office Action. The rejection of Claim 1 is therefore erroneous and should be withdrawn.
Similar errors of paraphrasing, re-drafting, or selectively ignoring claim limitations are repeated throughout the § 101 portion of the Office Action. For example, Page 4 of the Office Action states that "The claim recites the additional element(s): receiving data, and providing a timeline performs the aggregating, filtering, and generating steps." In this regard, it is not clear how Claim 1 is being read such that receiving data and providing a timeline "performs" the other claim steps. Furthermore, a combination of substantial technical detail is ignored which combines to provide Claim 1 with novel/nonobvious (i.e., inventive) features of Claim 1 such as receiving data relating to a building site from a plurality of separate building applications; providing the timeline on a graphical user interface, wherein each of the plurality of isolated events includes an event marker on the timeline representative of the isolated event. The 101-analysis presented in the Office Action is entirely silent as to the text in italics in the preceding sentence. Because the § 101 rationale in the Office Action fails to address the language actually recited in Claim 1, no prima facie case of patent ineligibility is presented and the rejection should be withdrawn.”
The Examiner respectfully disagrees.
In response to the arguments in the Examiner notes that the Applicant's argument that the rejection of Claim 1 should be withdrawn due to alleged errors in the Office Action's characterization of the claim language is not persuasive. The Examiner acknowledges that certain language in the Office Action, such as references to "determining a timeline that includes installation and service activities" and "a processor," may not correspond verbatim to the specific terminology recited in Claim 1. However, any such imprecision in paraphrasing does not render the rejection erroneous or negate the prima facie case of patent ineligibility. The substance of the rejection remains sound. The Office Action identified that the claimed method involves aggregating data, filtering that data to identify isolated events, and generating a timeline concept that fall within the abstract idea grouping of mental processes. The use of different terminology to summarize or characterize claim limitations does not constitute a failure to examine the actual claim, provided the substantive analysis correctly identifies the nature of the claimed subject matter. Here, the core analysis remains applicable to the limitations actually recited in Claim 1.
Applicant contends that the Office Action ignored "substantial technical detail" and "novel/nonobvious (i.e., inventive) features" of Claim 1, specifically citing the limitations of "receiving data relating to a building site from a plurality of separate building applications" and "providing the timeline on a graphical user interface, wherein each of the plurality of isolated events includes an event marker on the timeline representative of the isolated event." This argument conflates the eligibility analysis under 101 with the novelty and non-obviousness analyses under 102 and 103.
As set forth in the August 4, 2025 memorandum referenced by Applicant, the eligibility inquiry under 101 is distinct from the novelty and non-obviousness inquiries. A claim may recite novel and nonobvious subject matter yet still be directed to a judicial exception without integrating that exception into a practical application or providing an inventive concept sufficient to satisfy 101. The fact that Claim 1 recites specific data sources (a plurality of separate building applications) and specific display features (event markers on a timeline in a graphical user interface) does not automatically render the claim patent-eligible. Under Step 2A, Prong Two, the relevant inquiry is whether these additional elements integrate the judicial exception into a practical application, not whether they are novel or nonobvious.
The limitations Applicant highlights receiving data from building applications and displaying a timeline with event markers on a GUI were considered in the Office Action's analysis. Receiving data from multiple sources constitutes data gathering activity, which under MPEP § 2106.05(g) is generally considered insignificant extra-solution activity that does not integrate an abstract idea into a practical application. Providing output on a graphical user interface with event markers amounts to outputting the results of the abstract mental process in a visual format, which does not impose meaningful limits on the judicial exception. The specificity that the data relates to "a building site" and comes from "separate building applications," or that the display includes "event markers," does not transform the fundamental nature of these steps from data gathering and data display into something that integrates the abstract idea into a practical application. These limitations merely narrow the field of use to building management and specify conventional display elements.
Applicant's assertion that "no prima facie case of patent ineligibility is presented" because the Office Action did not address every word of the claim is not consistent with USPTO practice. An Office Action is not required to reproduce and individually analyze each claim term to establish a prima facie rejection. Rather, the Office Action must identify the judicial exception recited in the claim and explain why the additional elements do not integrate the exception into a practical application or provide an inventive concept. The Office Action satisfied this standard with respect to Claim 1. For the foregoing reasons, the rejection of Claim 1 is maintained.
The Applicant argues on pages 12-13 "When read for the features actually recited in Claim 1, which include technical details not addressed in the Office Action's § 101 analysis, such as "aggregating the received data from the plurality of separate building applications in accordance with a predetermined format", "a plurality of isolated events associated with the building site over the lifecycle of the building site, wherein each of the plurality of isolated events includes a time associated with the isolated event," "wherein the timeline is arranged based on the time associated with each isolated event," and "providing the timeline on a graphical user interface, wherein each of the plurality of isolated events includes an event marker on the timeline representative of the isolated event," one of skill in the art would appreciate technical advantages provided by the combination of claimed features. For example, paragraph [0125] of the present application describes: In this regard, the teachings herein also advantageously reduce computational complexity, computational complexity, and network bandwidth associated with digital display of information relating to multiple building applications spanning a building site lifecycle.
Without the teachings herein, a user computing device would need to separate launch and/or access multiple separate building applications (consuming computer-short term memory, network bandwidth, etc.), provide, for each separate application, interactions (e.g., displaying multiple user interfaces for the multiple applications) capable of navigating to a system of interest, providing separate queries for and loading of relevant data in the different application systems (e.g., from cloud services provided for the different applications), etc. If such information is to be presented simultaneous, as contemplated by the solutions herein, a need would exist for a large display and/or multiple displays or user devices to display the multiple different applications simultaneously (e.g., different windows, different apps, different display screens, etc.).
All such operations are eliminated by the teachings herein which provide for an efficient aggregation and filtering of events from multiple separate applications such that a unified timeline showing relevant events for a building site is provided via an interface.
Computer operations for providing such a unified timeline are thus greatly reduced in complexity, memory requirements, computational load, computing time, etc. as compared to the scenario described above without the teachings herein, where many separate applications much be launched to even approximate the information delivery of the present application. In this regard, it should also be understood that the aggregation and processing of data into a predetermined data format from separate applications that use different formats and using a table of site directory associations contributes to the computational and data storage efficiencies of the teachings here as compared to alternative approaches. Because such technical improvements are provided by features recited in Claim 1, Claim 1 is patent eligible.”
The Examiner respectfully disagrees.
In response to the arguments in the Examiner notes that the Applicant's argument that Claim 1 is patent-eligible because it provides technical improvements as described in par. [0125] of the specification is not persuasive. The Examiner has considered the technical advantages described in the specification, including the assertions regarding reduced computational complexity, reduced network bandwidth, and reduced memory requirements. However, for a claim to integrate a judicial exception into a practical application based on an improvement to computer functionality or technology, the improvement must be reflected in the claim itself, not merely described in the specification. As set forth in MPEP 2106.04(d)(1) and 2106.05(a), the relevant inquiry is whether the claim reflects the alleged improvement in technology. A specification that describes advantages of an invention is not sufficient if the claims are drafted broadly enough to encompass embodiments that do not achieve those improvements, or if the claims do not recite the specific features that produce the improvement.
Examining the limitations Applicant identifies as providing technical advantages, the claim recites "aggregating the received data from the plurality of separate building applications in accordance with a predetermined format." This limitation describes collecting and organizing data according to some unspecified format. The claim does not recite any particular data structure, algorithm, or processing technique that would yield the computational efficiencies described in the specification. The claim recites filtering the aggregated data to identify "a plurality of isolated events" with associated times. This describes the abstract concept of selecting relevant information from a larger data set based on some unspecified criteria. The claim does not recite how the filtering achieves any computational improvement over prior approaches. The claim recites generating and providing a timeline with event markers on a graphical user interface. This describes displaying information in a visual format, which is a conventional computer function.
The technical improvements described in par. [0125] of the specification—eliminating the need to launch multiple separate applications, reducing memory consumption, reducing network bandwidth usage, and reducing computational load—are not captured in the claim language. The specification explains that these benefits arise from "efficient aggregation and filtering of events" and "aggregation and processing of data into a predetermined data format from separate applications that use different formats and using a table of site directory associations." However, Claim 1 does not recite any specific aggregation technique, any specific filtering algorithm, any specific data format or structure, or any table of site directory associations. The claim merely recites aggregating data "in accordance with a predetermined format" without specifying what that format is or how it contributes to computational efficiency. The claim recites filtering to identify "isolated events" without specifying any filtering criteria or mechanism that would reduce computational complexity.
Furthermore, the improvements described in the specification appear to be improvements in the efficiency of presenting building management information to a user, rather than improvements to computer functionality itself. The specification describes that without the claimed invention, a user would need to launch multiple applications and potentially use multiple displays. This describes a user experience improvement and a consolidation of information presentation. While such improvements may have practical value, they do not constitute improvements to the functioning of a computer or to any other technology or technical field within the meaning of the eligibility analysis. Consolidating information from multiple sources into a single display is the automation of a task that could otherwise be performed by a human reviewing multiple applications, which is the hallmark of an abstract idea implemented on a generic computer.
The cases finding eligibility based on improvements to computer functionality have involved claims that recite specific technical implementations achieving specific technical results. For example, in Enfish, LLC v. Microsoft Corp., the claims recited a specific data structure (a self-referential table) that improved how data was stored and retrieved in computer memory. Here, Claim 1 does not recite any analogous specific technical implementation. The claim is drafted at a high level of generality that encompasses any method of aggregating data from building applications and displaying a timeline, without requiring the specific features that allegedly produce the technical improvements described in the specification.
Applicant's reliance on the disclosure in par. [0125] does not demonstrate that Claim 1 is directed to a technological improvement rather than an abstract idea. The claim as written does not capture the allegedly inventive technical features that produce the described benefits. For the foregoing reasons, the rejection of Claim 1 is maintained.
The Applicant argues on page 14 "The Applicant on page 14 of argues that “Claim 1 recites "receiving data relating to a building site from a plurality of separate building applications." Page 3 of the Office Action addresses this feature by saying that "Abstract of Zhang teaches receiving data from a building site from one of multiple buildings," which is erroneous for several reasons. First, the Abstract of Zhang is entirely silent as to "multiple buildings." Second, what the language of Claim 1 recites is that data relating to a building site is received from a plurality of separate building applications. The characterization of what is taught in Zhang refers to multiple buildings, not to a plurality of building applications as claimed. Third, if data were for "multiple buildings" as stated in the Office Action, it would be related to the different sites of those buildings and thus it does not make sense to map such data relating to different building sites to the language of the "receiving" step of Claim 1. The rejection of Claim 1 is therefore erroneous and should be withdrawn.”
The Examiner respectfully disagrees.
In response to the arguments in the Examiner notes that with respect to the argument the Examiner respectfully disagrees with Applicant's characterization of the rejection and the teachings of Zhang. First, while Applicant correctly notes that the Abstract may not explicitly use the phrase "multiple buildings," the Examiner directs Applicant's attention to the full scope of the citation provided in the Office Action, which included par. [0141]-[0144]. Specifically, par. [0141] of Zhang explicitly teaches: "The integrated control layer 418 allows building operators to implement cross-system constraints and/or control logic across multiple building subsystems including different buildings of a building campus..." This passage directly establishes that Zhang contemplates receiving data from multiple building subsystems and multiple buildings within a campus environment.
Second, and more critically, Applicant's argument that Zhang does not teach receiving data from "a plurality of separate building applications" mischaracterizes both the claim language and the teachings of Zhang. The Examiner notes that Zhang teaches a building management system architecture with multiple distinct functional layers and subsystems that constitute separate "building applications" under the broadest reasonable interpretation of the claim term. Specifically, noting art that was previously provided in the Office Action Zhang at par. [0092] teaches "application services" (i.e., service applications). Zhang at FIG. 7 and par. [0148] teaches a CAP dashboard that receives data from multiple distinct workflow activities including: Engineering/design activities, fulfillment activities, Installation activities, verification/commissioning activities, Switchover activities, and Service activities. Each of these represents a separate building application that provides data to the system. Furthermore, Zhang at par. [0127] teaches "external applications monitoring events (performance monitoring)" which constitutes yet another separate building application.
Finally, Applicant's argument regarding "different building sites" conflates the source of data with the subject of the data. The claim recites receiving data "relating to a building site" from a plurality of separate building applications. Zhang's system receives data relating to a building site (or sites) from multiple separate applications/subsystems. The fact that Zhang's system may aggregate data across multiple buildings does not negate the teaching it actually strengthens it by demonstrating the system's capability to receive data from multiple sources relating to building sites.
For Additional Clarification: The Examiner notes that Zhang provides even more explicit support for this limitation at the following paragraphs: par. [0086]: Teaches "filtering by various attributes of events from multiple systems" establishing that data is received from multiple separate systems (applications). Paragraph [0166]: Teaches "receiving data in multiple data formats" which inherently implies data is being received from multiple separate sources/applications, as different applications typically generate data in different formats and par. [0143]-[0144]: Teaches aggregating data representing events of building resources, where the integrated control layer receives data from multiple building subsystems including "HVAC 440, lighting 442, security 438, fire safety 430, building electrical 434, ICT 436, lift/escalators 432" (see also FIGS. 1A-4). Each of these subsystems operates as a separate building application providing data to the BMS.
The rejection is viewed as proper. Zhang teaches receiving data relating to a building site from a plurality of separate building applications, including but not limited to: service applications (par. 0092]), commissioning applications (FIG. 7), performance monitoring applications (par. [0127]), and multiple building subsystem applications (HVAC, lighting, security, fire safety, etc.) as detailed in par. [0143]-[0144] and FIGS. 1A. Applicant's argument have been considered are viewed as unpersuasive, and the rejection is therefore maintained.
The Applicant argues on pages 14-15 that "With respect to the Argument the Examiner respectfully disagrees with the Applicant on pages 14-15 of argues that “Claim 1 recites "providing the timeline on a graphical user interface, wherein each of the plurality of isolated events includes an event marker on the timeline representative of the isolated event." With respect to the claimed "timeline," the Examiner confirmed in the interview that page 10 of the Office Action cites to disclosure of "timeseries data" at par. [0145] in Zhang. Taking that mapping at face value for the sake of argument, a proper prima facie case of anticipation would then require Zhang to specifically disclose that the timeseries data from par. [0145] is provided on a graphical user interface. However, with respect to the graphical user interface, the Office Action cites paragraph par. [0148] which is entirely silent with respect to the cited "timeseries data." Because the cited "timeseries data" is not disclosed as being provided on the cited user interface, the cited disclosure of Zhang does not anticipate "providing the timeline on a graphical user interface… The rejection of Claim 1 is therefore erroneous and should be withdrawn”. Applicant argues that the rejection is erroneous because the "timeseries data" cited at par. [0145] is not explicitly disclosed as being provided on the graphical user interface cited at par. [0148]. Applicant contends that because these two paragraphs do not expressly link the timeseries data to the GUI, Zhang cannot anticipate the claimed limitation of "providing the timeline on a graphical user interface…”
The Examiner respectfully disagrees.
In response to the arguments in the Examiner notes that with respect to the argument the Examiner respectfully disagrees with Applicant's narrow reading of Zhang and the standard for anticipation. First, Applicant's argument improperly requires that a single paragraph or sentence explicitly recite every element in combination. This is not the standard for anticipation. Under MPEP 2131, a reference anticipates a claim if it discloses every element of the claimed invention, either explicitly or inherently. The disclosure need not be in a single passage, so long as a person of ordinary skill in the art ("POSITA") would understand the reference to teach the claimed combination. See In re Paulsen).
Second, Zhang at par. [0145] explicitly teaches that the time series data is "viewable on display": "Time series data showing performance of events, data generated by building system providing information about system and specific processes/operations viewable on display, including faults and communication with time series data, providing alerts for repair and faults."
This passage directly contradicts Applicant's assertion that par. [0145] is silent regarding display of the timeseries data on a user interface. Zhang explicitly teaches that the time series data, which includes information about faults, communications, and events, is viewable on a display, which constitutes a graphical user interface.
Third, par. [0148] of Zhang further reinforces this teaching by describing the graphical user interface capabilities of the system: "Graphical user interface display, project workflows indicating services to track project statuses (timeline), tracking project statuses and updating schedules including financial forecasting providing ongoing status of equipment."
The Examiner notes that par. [0148] explicitly uses the term "timeline" in the context of tracking project statuses on a graphical user interface display. This directly teaches the claimed "providing the timeline on a graphical user interface.” Finally, Zhang's disclosure must be read as a whole, not as isolated, disconnected paragraphs. Zhang describes an integrated building management system where data flows through various layers and is ultimately presented to users through interfaces. The FDD layer (par. [0141]-[0145]) generates time series data regarding faults and events, and this data is presented through the CAP dashboard and GUI (FIG. 7, par. [0148]). A POSITA would understand that the time series data described in par. [0145] as being "viewable on display" is presented through the graphical user interface described in par. [0148].
For Additional Clarification the Examiner further directs Applicant's attention to: par. [0145]: This paragraph itself states the time series data is "viewable on display" directly teaching that this data is presented on a graphical user interface. Figure. 7 and par. [0148]: The CAP dashboard view, displays commissioning workflow activities, with activity completion status, and showing percentage completion. These workflow activities are organized temporally (engineering/design - fulfillment - installation - verification/commissioning - switchover - service), constituting a timeline representation with markers for each activity/event. Paragraph [0106]: Teaches "visualization of equipment (icons), equipment selection, adding/removing/changing points for machines to modify events" establishing that events are visualized with graphical elements (icons serving as markers) on the user interface, and par. [0143]: Teaches "providing alerts related to events" where alerts are inherently displayed to users through a graphical interface.
The claim further requires that "each of the plurality of isolated events includes an event marker on the timeline representative of the isolated event." Zhang teaches this at: figure. 7: Shows workflow activities (712-730) displayed as distinct visual elements (markers) on the dashboard, each representing a separate event/activity in the project timeline, par. [0106]: Teaches visualization using "icons" for equipment and events and par. [0148]: The tasks (714) with associated bill of materials, schedules, and information repository represent distinct event markers within the project workflow timeline. Zhang explicitly teaches at par. [0145] that time series data is "viewable on display" and at par. [0148] that a graphical user interface displays a "timeline" for tracking project statuses. Reading Zhang as a whole, as required under proper claim construction principles, a POSITA would understand that Zhang teaches providing timeline data on a graphical user interface with event markers representative of isolated events. Applicant's argument is therefore unpersuasive, and the rejection has been maintained.
The Applicant argues on page 15 that " Claim 1 recites "an event marker on the timeline representative of the isolated event." In the Interview, the Examiner was unable to answer Applicant's question about what exactly from Zhang was being mapped to the claimed event marker on the timeline. Page 10 of the Office Action also does not appear to specifically address the claimed event marker on the timeline. Given that Zhang's "timeseries data" is being cited for the "timeline," a proper case of anticipation would require Zhang to disclose "an event marker on the [timeseries data] representative of the isolated event." However, it does not make sense that an event marker would be "on" the timeseries data (reflecting the Examiner's misinterpretation of "timeline"). Further, separate disclosure of timeseries data and a user interface from different paragraphs of Zhang as cited at page 10 of the Office Action cannot plausibly be read as disclosing "an event marker on the [timeseries data] representative of the isolated event." Zhang therefore does not meet the high standard for a proper finding of anticipation, which requires that "The identical invention must be shown in as complete detail as claimed... The elements must be arranged as required by the claim." MPEP 2131. The rejection of Claim 1 is therefore erroneous and should be withdrawn”.
The Examiner respectfully disagrees.
In response to the arguments in the Examiner notes that the Applicant argues that: (1) the Examiner was unable to identify what in Zhang corresponds to the claimed "event marker on the timeline"; (2) it does not make sense for an event marker to be "on" timeseries data; and (3) the separate disclosure of timeseries data and a user interface from different paragraphs cannot meet the anticipation standard requiring that "identical invention must be shown in as complete detail as claimed."
The Examiner respectfully disagrees with Applicant's arguments and provides the following clarification regarding the mapping of Zhang's teachings to the claimed "event marker on the timeline." First, the Examiner clarifies that "timeseries data" and "timeline" are not being equated in the manner Applicant suggests. Rather, Zhang teaches multiple aspects that collectively teach the claimed timeline with event markers: Time series data (par. [0145]) teaches data arranged chronologically over time the underlying temporal organization of events and the graphical user interface/CAP dashboard (FIG. 7, par. [0148]) teaches the visual presentation of this temporally-organized information with distinct visual elements representing events. The claimed "timeline" is the visual representation of temporally-arranged events on a GUI, and Zhang teaches exactly this. Second, Applicant's assertion that the Examiner could not identify the event markers is addressed directly here. Zhang explicitly teaches event markers on the timeline at multiple locations: FIG. 7 and par. [0148]: The CAP dashboard view (704) displays commissioning workflow activities (712-730) as distinct visual elements arranged in a temporal/sequential workflow. Specifically: Engineering/design, Fulfillment, Installation, Verification/commissioning, Switchover, and Service.
Each of these workflow activities (712-730) constitutes an event marker on the timeline (the project workflow display). They are visually distinct elements that represent isolated events in the building's lifecycle, arranged according to their temporal sequence. The activity completion status (710) showing percentage completion further demonstrates that these are discrete, trackable events displayed on the interface. Paragraph [0106]: Zhang teaches "visualization of equipment (icons), equipment selection, adding/removing/changing points for machines to modify events." The "icons" explicitly constitute graphical markers representing events on the display. This directly teaches event markers representative of isolated events. Paragraph [0143]: Zhang teaches "providing alerts related to events." Alerts are inherently displayed as discrete visual indicators (markers) on a user interface to notify users of specific events.
Third, Applicant's argument that separate paragraphs cannot collectively teach a single limitation mischaracterizes the anticipation standard. MPEP 2131 states that anticipation requires that the reference discloses every element of the claimed invention, but does not require that every element appear in a single sentence or paragraph. The Federal Circuit has consistently held that a reference must be read as a whole. See In re Paulsen; Net MoneyIN, Inc. v. VeriSign, Inc., ("the reference must be considered as a whole").
Zhang's disclosure, read as a whole, teaches a building management system that:
Collects time-series data regarding building events (par. [0145])
Displays this information on a graphical user interface (par. [0145] "viewable on display"; par. [0148])
Presents workflow activities as discrete visual elements (Figure. 7, items 712-730)
Uses icons and visual indicators to represent events (par. [0106])
Tracks project statuses on a timeline (par. [0148] explicitly uses the term "timeline")
A POSITA would understand this integrated disclosure to teach event markers on a timeline.
For the additional clarification the Examiner provides the following additional citations demonstrating event markers on a timeline in Zhang: fig. 7: This figure explicitly shows the CAP dashboard with: Tasks (714) displayed as individual elements with associated information, Workflow activities (712-730) shown as distinct boxes/markers in a sequential arrangement, and Activity completion status (710) providing visual indication of event progress. Each task and workflow activity is a discrete visual element (marker) representing an isolated event, arranged in temporal/sequential order (timeline) on the graphical user interface. Paragraph [0097]: Teaches "tables providing equipment data" where table entries serve as markers identifying discrete equipment-related events, par. [0111]: Teaches "discovery tables storing data variables related to equipment, equipment identifiers for specific buildings." Equipment identifiers serve as markers for equipment-related events in the system's data displays, and par. [0145]: Teaches that the time series data includes "faults and communication with time series data, providing alerts for repair and faults." Faults and alerts are discrete events that are displayed (viewable on display) as distinct markers indicating specific occurrences requiring attention.
Applicant cites MPEP 2131 for the proposition that "elements must be arranged as required by the claim." Zhang satisfies this requirement:
Claim Element
Zhang Teaching
Timeline
Paragraph [0148]: "project workflows indicating services to track project statuses (timeline)"
Provided on GUI
Paragraph [0145]: "viewable on display"; Paragraph [0148]: "Graphical user interface display"
Event marker on the timeline
FIG. 7: Workflow activities (712-730) as visual elements; Paragraph [0106]: "icons" for events
Representative of isolated event
FIG. 7: Each workflow activity (engineering, installation, commissioning, service) represents a distinct/isolated event
The elements are arranged exactly as claimed: event markers (workflow activities, icons, alerts) are displayed on a timeline (project workflow tracking statuses over time) on a graphical user interface.
Zhang explicitly teaches event markers on a timeline through: (1) the workflow activities (712-730) displayed as discrete visual elements in FIG. 7; (2) icons representing events (par. [0106]); (3) alerts for faults and repairs (par. [0145]); and (4) tasks with associated tracking information (par. [0148]). These are displayed on a graphical user interface that tracks project statuses on a "timeline" (par. [0148]). Applicant's argument is therefore unpersuasive, and the has been maintained.
The Applicant argues on pages 15-16 " The rejections of Claims 18 and 20 are erroneous for similar reasons as discussed above, plus additional reasons in view of the amendments submitted herewith. Amended Claim 10 recites "providing, on a graphical user interface, a timeline comprising event markers representing a plurality of isolated events filtered from the data, the event markers spatially arranged along the timeline based on times associated with the isolated events." No such event markers spatially arranged along a timeline are disclosed in the cited passages of Zhang. Claim 20 recites "provide a graphical user interface comprising a line representing time and event markers positioned along the line." No such line is cited form Zhang, nor does Zhang disclose any such event markers positioned along the line, for the reason discussed above. Independent Claims 18 and 20 are therefore not anticipated by Zhang. Applicant argues that: (1) amended Claim 18 recites event markers "spatially arranged along the timeline based on times associated with the isolated events," which is not disclosed in Zhang; (2) Claim 20 recites "a line representing time and event markers positioned along the line," and no such line is cited from Zhang; and (3) the amendments to Claims 18 and 20 overcome the rejection”.
The Examiner respectfully disagrees.
In response to the arguments in the Examiner notes that the Examiner has carefully considered the amendments to Claims 18 and 20 and respectfully disagrees that the amendments overcome the rejection. Zhang teaches the limitations as amended.
Regarding claim 18 now recites "providing, on a graphical user interface, a timeline comprising event markers representing a plurality of isolated events filtered from the data, the event markers spatially arranged along the timeline based on times associated with the isolated events." Figure 7 and par. [0148]: The CAP dashboard displays workflow activities (712-730) that are spatially arranged in a sequential/temporal order representing the project lifecycle: Engineering/design (734) - 2. Fulfillment (742) - 3. Installation (736) - 4. Verification/commissioning (738) - 5. Switchover (739) - 6. Service (740). These workflow activities are displayed as discrete visual elements (event markers) that are spatially arranged along the project workflow (timeline) based on when they occur in the building's lifecycle. The spatial arrangement from left to right (or sequential ordering) directly corresponds to the temporal sequence of these events—engineering/design occurs before installation, which occurs before commissioning, which occurs before service. Paragraph [0148]: Explicitly teaches "tracking project statuses and updating schedules" demonstrating that the events are arranged according to their associated times/schedules and par. [0145]: Teaches "time series data showing performance of events" where "time series" inherently means data arranged according to time. This time series data is "viewable on display," meaning the temporal arrangement is visually presented. The term "spatially arranged along the timeline based on times" simply requires that event markers be positioned on the display according to their temporal occurrence. Zhang's workflow activities (FIG. 7) are positioned in sequence based on when they occur in the project lifecycle, satisfying this limitation.
Regarding Claim 20 recites "provide a graphical user interface comprising a line representing time and event markers positioned along the line." Zhang teaches this limitation: First, the Examiner notes that under the broadest reasonable interpretation, "a line representing time" encompasses any visual element that depicts temporal progression, including workflow timelines, project schedules, and sequential process flows.
Figure 7 discloses the CAP dashboard (704) displays a project workflow that constitutes a visual representation of temporal progression. The workflow activities (712-730) are arranged in a sequential manner that inherently represents the passage of time through the project lifecycle. The horizontal arrangement of workflow phases (engineering - fulfillment - installation - commissioning - switchover - service) constitutes a line representing time, with each phase positioned along this progression. Paragraph [0148]: Teaches "project workflows indicating services to track project statuses (timeline), tracking project statuses and updating schedules." The explicit use of "timeline" and "schedules" demonstrates that Zhang presents a temporal representation with project events positioned according to their occurrence in time. Paragraph [0145]: Teaches "time series data...viewable on display." Time series data, by definition, is data arranged along a temporal axis—i.e., a line representing time. When displayed, this temporal axis constitutes "a line representing time" with data points (event markers) positioned along it.
For additional clarification the Examiner provides additional support from Zhang: Paragraph [0141]-[0142]: Teaches that the FDD layer (416) performs fault detection and diagnostics, generating data regarding building events over time. This data is organized temporally and presented through the system's interfaces. Paragraph [0127]: Teaches "report interface showing data regarding building subsystems"—where reports inherently organize data temporally, often along a timeline or temporal axis. General knowledge in the art: a POSITA would understand that building management system dashboards displaying project workflows, schedules, and time series data necessarily include visual representations of time (whether as explicit axis lines, Gantt charts, sequential flow diagrams, or other temporal visualizations) with events positioned according to their temporal occurrence.
Regarding the amendments generally: The Examiner notes that the amendments to Claims 18 and 20 clarify the spatial/temporal arrangement of event markers but do not introduce limitations that distinguish over Zhang. Zhang's CAP dashboard (FIG. 7) and time series displays (par. [0145]) inherently present events in temporal arrangement: Claim 18: "event markers spatially arranged along the timeline based on times associated with the isolated events": Zhang teaches FIG. 7: Workflow activities (712-730) arranged sequentially according to project phase timing; par. [0148]: "timeline," "tracking project statuses and updating schedules”. Claim 20: "a line representing time": FIG. 7: Sequential workflow arrangement; par. [0145]: "time series data...viewable on display"; par. [0148]: "timeline". "event markers positioned along the line": Zhang teaches FIG. 7: Workflow activities (712-730), tasks (714) positioned in sequential/temporal order; par. [0106]: icons representing events.
With regard to the Applicant's Assertion That "No Such Line Is Cited from Zhang": The Examiner respectfully notes that Applicant's specification does not provide a special definition for "a line representing time." Under the broadest reasonable interpretation consistent with the specification, this term encompasses any visual representation of temporal progression, including: A horizontal or vertical axis representing time, a sequential workflow diagram, Gantt chart or project timeline, and any linear visual arrangement depicting temporal sequence. Zhang's CAP dashboard (FIG. 7) displays workflow activities in a sequential arrangement representing the temporal progression of project phases. This constitutes "a line representing time" under the broadest reasonable interpretation. The workflow activities (event markers) are "positioned along" this temporal representation according to when they occur in the project lifecycle.
Event markers spatially arranged along a timeline based on times (FIG. 7: workflow activities arranged in temporal sequence; par. [0148]: "timeline," "schedules")
A line representing time (FIG. 7: sequential workflow representation; par. [0145]: time series data display; par. [0148]: "timeline")
Event markers positioned along the line (FIG. 7: workflow activities 712-730; par. [0106]: icons; par. [0145]: faults and alerts in time series display)
The amendments to Claims 18 and 20 do not overcome the rejection. Applicant's arguments are therefore unpersuasive, and the rejections of Claims 18 and 20 have been maintained.
The Applicant argues on pages 15-16 " Claim 3 recites "receiving data arranged in one or more different data formats." Page 11 of the Office Action cites par. [0166] of Zhang which discloses "activities, tasks, and status indication presented in the CAP dashboard view 704 are rendered in one or more formats," i.e., presenting information on a dashboard in one or more formats, not receiving data arranged in one or more different data formats. Claim 3 is therefore not anticipated by the cited disclosure of Zhang, especially when read in context of Claim 1”.
The Examiner respectfully disagrees.
In response to the arguments in the Examiner notes that the Examiner respectfully disagrees with Applicant's narrow interpretation of Zhang's teachings and provides clarification regarding the citation and additional supporting disclosure. First, the Examiner acknowledges that par. [0166] as cited addresses the presentation of data in various formats. However, Zhang's disclosure, read as a whole, explicitly teaches receiving data in multiple different data formats. Second, Zhang at par. [0166] must be read in its complete context. The full teaching at par. [0166] includes "receiving data in multiple data formats": This directly teaches the claimed limitation of "receiving data arranged in one or more different data formats." The fact that Zhang also discusses presenting data in various formats does not negate the explicit teaching of receiving data in multiple formats.
Third, even if Applicant's characterization of par. [0166] were accurate, Zhang teaches receiving data in different formats at multiple other locations: par. [0086]: Teaches "filtering by various attributes of events from multiple systems." A POSITA would understand that data received from multiple different systems inherently arrives in different data formats, as different systems typically generate data according to their own format specifications. Paragraphs [0141]-[0144]: Teaches receiving and aggregating data from multiple building subsystems including: HVAC (440), Lighting (442), Security (438), Fire safety (430), Building electrical (434), ICT (436), and Lift/escalators (432). Each of these distinct building subsystems generates data in its own native format. The integrated control layer (418) receives this data from disparate subsystems, necessarily receiving data arranged in different data formats. Paragraph [0012]: Zhang teaches receiving "configuration, status, state, connectivity, self-test, operational data." These different categories of data are inherently arranged in different formats—configuration data has a different structure than status data, which differs from self-test data, etc.
For additional clarification: The Examiner provides the following additional support demonstrating that Zhang teaches receiving data in different formats: par. [0028] and FIG. 5: Zhang teaches that the virtual server receives data from multiple sources including: product installation data from BMS controller, commissioning data from remote commissioning system, and Data via VPN/secure connections (508, 538). Data from these different sources (BMS controller, remote commissioning system, external connections) would inherently be arranged in different data formats according to their respective source systems. Paragraph [0038]: Teaches connections between multiple different system components, each of which communicates data in its native format. The system necessarily receives data in these multiple different formats, par. [0097]: Teaches "tables providing equipment data" demonstrating that data is received and organized in tabular format, which is one data format among several used in the system, and par. [0111]: Teaches "discovery tables storing data variables related to equipment" another data format (tabular/discovery format) distinct from other formats in the system.
In view of claim construction under the broadest reasonable interpretation, "receiving data arranged in one or more different data formats" requires that the system receive data that is structured or organized in more than one format. Zhang's building management system receives data from: Multiple building subsystems (HVAC, lighting, security, fire safety, etc.) each with its own data format, Multiple functional layers (FDD layer, integrated control layer, enterprise integration layer) - each processing data in different formats, and Multiple external sources (BMS controller, remote commissioning system, external applications) each providing data in native formats. This satisfies the claim limitation.
Reading Claim 3 in Context of Claim 1: Applicant suggests that Claim 3 should be read "in context of Claim 1." The Examiner agrees. Claim 1 recites receiving data from "a plurality of separate building applications." Claim 3 depends from Claim 1 and further specifies that this data is "arranged in one or more different data formats." Zhang teaches both: Claim 1: Receiving data from a plurality of separate building applications (subsystems, service applications, commissioning tools, performance monitoring applications see Examiner's Response to Argument 1), and Claim 3: This data being arranged in different data formats (because each separate application/subsystem generates data in its own native format, per par. [0086], par. [0141]-[0144], and par. [0166]). The teachings are entirely consistent. When a system receives data from multiple separate applications/subsystems (Claim 1), that data is inherently arranged in different formats (Claim 3) because different applications use different data structures and formats. Zhang explicitly teaches "receiving data in multiple data formats" at par. [0166]. Additionally, Zhang's disclosure of receiving data from multiple building subsystems (par. [0141]-[0144]), multiple systems (par. [0086]), and multiple sources (par. [0012], par. [0028]) inherently teaches receiving data arranged in one or more different data formats, as each source generates data in its native format. Applicant's argument is therefore unpersuasive, and the rejection has been maintained.
The Applicant argues on pages 16-17 "Claim 5 recites, in part "the table including associations between building site identifiers of the one or more different data formats and a unified building site identifier." The Office Action cites disparate sections of Zhang, including for a "discovery tables to store data variables related to the equipment." but, "data variables related to the equipment" are not disclosed as being "associations between building site identifiers of the one or more different data formats and a unified building site identifier" as claimed. With respect to the "identifiers," the Office Action appears to cite to paragraph [0144] which mentions specifically identifying equipment, but which is silent as to a "table" and which relates to identifying equipment, not to "associations between building site identifiers of the one or more different data formats and a unified building site identifier" as claimed. Claim 5 is therefore not anticipated by the cited disclosure of Zhang”.
The Examiner respectfully disagrees.
In response to the arguments in the Examiner notes that the Examiner respectfully disagrees with Applicant's characterization of Zhang's teachings and the scope of the claim limitations. First, the Examiner addresses the claim construction of "building site identifiers." Under the broadest reasonable interpretation, a "building site identifier" is any identifier that identifies or is associated with a building site, including identifiers for equipment located at a building site, identifiers for buildings within a site, or identifiers for the site itself. Equipment identifiers that are specific to particular buildings inherently serve as building site identifiers because they identify equipment at a particular building site. Second, Zhang explicitly teaches tables with building and equipment identifiers at par. [0111]: "Discovery tables storing data variables related to equipment, equipment identifiers for specific buildings". This passage teaches: and Tables ("discovery tables") and Equipment identifiers that are associated with specific buildings. Equipment identifiers "for specific buildings" are identifiers that associate equipment with particular building sites. When the system uses discovery tables to store these identifiers, it is creating associations between identifiers from different sources and a unified identification scheme for the building site's equipment. Third, Zhang teaches the concept of unified identification across multiple buildings and systems at par. [0141]-[0144]. Specifically, par. [0141] teaches: "The integrated control layer 418 allows building operators to implement cross-system constraints and/or control logic across multiple building subsystems including different buildings of a building campus". For such cross-system and cross-building integration to function, the system must maintain associations between different identifiers used by different subsystems and buildings with a unified identification scheme. This is precisely what the claimed "associations between building site identifiers of the one or more different data formats and a unified building site identifier" describes. Fourth, par. [0144] teaches: "Integrated control layer allowing constraints and control to detect and diagnose specific machines in specific buildings". To "detect and diagnose specific machines in specific buildings," the system must maintain identifier associations that link machine/equipment identifiers from various subsystems to their specific building locations. This requires a mapping or association table between disparate identifiers and a unified building site identification scheme.
For additional clarification the Examiner provides additional support from Zhang: par. [0097]: Teaches "tables providing equipment data." These tables store equipment information that necessarily includes identifiers associating equipment with building sites. Paragraph [0086]: Teaches "filtering by various attributes of events from multiple systems." For filtering across multiple systems to work effectively, the system must maintain identifier associations that map different system identifiers to unified identifiers—otherwise, cross-system filtering would be impossible. Paragraph [0111]: Explicitly teaches "discovery tables storing data variables related to equipment, equipment identifiers for specific buildings." The phrase "equipment identifiers for specific buildings" directly teaches identifiers that associate equipment with building sites. The discovery tables storing these identifiers constitute "a table including associations between building site identifiers." Finally, par. [0127]: Teaches "external applications monitoring events" with a "report interface showing data regarding building subsystems." Reports that show data across building subsystems necessarily utilize identifier mappings that associate different subsystem identifiers with unified building site identifiers.
Specifically, the Applicant Argues: "Data variables related to the equipment" are not "associations between building site identifiers." The Examiner notes that Zhang at par. [0111] does not merely teach "data variables related to equipment"—it specifically teaches "equipment identifiers for specific buildings." Equipment identifiers that are designated "for specific buildings" inherently associate equipment with building sites. When stored in discovery tables, these create associations between equipment identifiers (from different data formats/subsystems) and building site identification. The Applicant further argues that par. [0144] is "silent as to a table.” To which the Examiner's notes that the rejection reads Zhang as a whole. Paragraph [0111] explicitly teaches "discovery tables" and par. [0097] teaches "tables providing equipment data." The identifier teachings at par. [0144] are stored and organized in the tables taught at par. [0097] and par. [0111]. A POSITA would understand that the identification functionality described in par. [0144] utilizes the table structures described in par. [0097] and par. [0111]. Finally, argues that Zhang's equipment identifiers are not building site identifiers, however, Under the broadest reasonable interpretation, equipment identifiers "for specific buildings" (par. [0111]) are building site identifiers because they identify equipment at specific building sites. The claim does not require identifiers that identify only the site itself—identifiers that associate elements (equipment, events, data) with specific building sites satisfy the limitation.
Claim 5 depends from Claims 1 and 4, which address receiving data from multiple building applications and converting data formats using conversion rules. Claim 5 specifies that conversion rules are "stored in a table including associations between building site identifiers of the one or more different data formats and a unified building site identifier." Zhang teaches: Conversion of data formats (par. [0166]: "receiving data in multiple data formats"), Tables storing identifier information (par. [0097]: "tables providing equipment data"; par. [0111]: "discovery tables"), Equipment identifiers for specific buildings (par. [0111]), and Cross-system integration requiring unified identification (par. [0141]-[0144]). The combination of tables (par. [0097], par. [0111]) storing equipment identifiers associated with specific buildings (par. [0111]) to enable cross-system identification (par. [0144]) teaches the claimed table including associations between building site identifiers and unified identifiers.
Zhang teaches a table (discovery tables at par. [0111]; tables providing equipment data at par. [0097]) including associations between building site identifiers of different data formats (equipment identifiers from different subsystems) and a unified building site identifier (identifiers "for specific buildings" enabling cross-system detection and diagnosis at par. [0141]-[0144]). Applicant's argument is therefore unpersuasive, and the rejection of Claim 5 has been maintained.
The Applicant argues on page 17 "Claim 7 recites "filtering the aggregated data using a machine learning model trained using historical data associated with a plurality of building sites." Page 12 of the Office Action cites to paragraph [0137] of Zhang which is entirely silent on a machine learning model trained using historical data associated with a plurality of building sites. Although there are equipment models in the cited paragraph, the passage provides not details suggesting that the cited models would be within the broadest reasonable interpretation of "machine learning models" or providing details on how the equipment models might be created (i.e., anything that might plausibly anticipate "trained using historical data associated with a plurality of building sites."). Claim 7 is therefore not anticipated by Zhang.”.
The Examiner respectfully disagrees.
In response to the arguments in the Examiner notes the Examiner respectfully disagrees with Applicant's characterization of Zhang's teachings and provides the following clarification. First, the Examiner acknowledges Applicant's argument regarding par. [0137] and provides additional citations from Zhang that more clearly teach the claimed machine learning model trained using historical data. Second, Zhang explicitly teaches machine learning models and analysis of data at multiple locations: par. [0137]: Teaches "control module initiating control actions to identify and manage events, analyzed by models." While Applicant argues these are merely "equipment models," the context of Zhang's disclosure reveals that these models perform analytical functions to identify and manage events functions consistent with machine learning models. Paragraph [0145]: Teaches "time series data showing performance of events, data generated by building system providing information about system and specific processes/operations." Time series data is inherently historical data, as it represents data collected over time. The analysis of this time series data to detect faults and generate alerts necessarily involves models trained on historical patterns. Paragraph [0141]-[0142]: Teaches that the FDD (Fault Detection and Diagnostics) layer (416) performs fault detection and diagnostics. FDD systems are well-known in the art to utilize machine learning models trained on historical operational data to detect anomalies and predict faults. A POSITA would understand that Zhang's FDD layer employs such models.
For additional clarification the Examiner provides more explicit support from Zhang for machine learning models trained on historical data: par. [0145]: "Time series data showing performance of events, data generated by building system providing information about system and specific processes/operations viewable on display, including faults and communication with time series data, providing alerts for repair and faults". This passage teaches: Historical data: "Time series data" is by definition historical data collected and organized over time, Analysis/modeling: The system detects "faults" and provides "alerts" which requires analytical models that can distinguish normal from abnormal conditions based on learned patterns, and Multiple building sites: par. [0141] establishes that the system operates across "multiple building subsystems including different buildings of a building campus". Paragraph [0141]: "The integrated control layer 418 allows building operators to implement cross-system constraints and/or control logic across multiple building subsystems including different buildings of a building campus". This teaches that the system's analytical capabilities (including the FDD layer's fault detection models) operate across a plurality of building sites (different buildings of a campus). FDD Layer par. [0141]-[0145]: Fault Detection and Diagnostics (FDD) systems are well-established in the building management art to employ machine learning models. The MPEP provides that the Examiner may take official notice of facts that are well-known in the art. The Examiner takes Official Notice that FDD systems in building management commonly utilize machine learning models (such as neural networks, support vector machines, decision trees, or statistical models) trained on historical operational data from building systems to detect faults, anomalies, and performance degradation. Zhang's explicit disclosure of an FDD layer (416) that performs fault detection and diagnostics using time series data (historical data) from multiple buildings teaches the claimed limitation.
Regarding "Trained Using Historical Data Associated with a Plurality of Building Sites": Zhang teaches this limitation through the combination of: Historical data: Time series data (par. [0145]) is historical data by definition, Plurality of building sites: par. [0141] teaches "different buildings of a building campus"; par. [0144] teaches "specific machines in specific buildings", and Model training: The FDD layer's ability to detect faults and generate alerts necessarily requires models that have been trained/configured to recognize fault conditions based on historical patterns par. [0144]: "Integrated control layer allowing constraints and control to detect and diagnose specific machines in specific buildings". For the system to "detect and diagnose specific machines in specific buildings," it must employ models that have learned (been trained on) the normal and abnormal operational patterns of those machines across the plurality of building sites.
With respect to claim construction consideration under the broadest reasonable interpretation, "a machine learning model trained using historical data" encompasses any computational model that uses historical/time-series data to make predictions, detect patterns, identify anomalies, or perform classifications. Zhang's FDD system, which analyzes time series data to detect faults and generate alerts, satisfies this interpretation. The claim does not require explicit disclosure of specific machine learning algorithms (e.g., neural networks, random forests) or detailed training procedures. It requires a model that: Performs filtering/analysis functions, uses historical data, and is associated with a plurality of building sites. Zhang teaches all three elements.
Machine learning-based FDD is well-established in the building management art. Implementing Zhang's fault detection using machine learning models trained on historical building data would have been a predictable application of known techniques to achieve predictable results namely, improved fault detection accuracy based on learned patterns from historical operations. Zhang teaches filtering/analyzing aggregated data using models (par. [0137]) that analyze time series data (historical data) (par. [0145]) from an FDD layer (par. [0141]-[0145]) operating across multiple buildings of a campus (plurality of building sites) (par. [0141], par. [0144]). The FDD layer's fault detection and diagnostics functionality inherently involves models trained on historical operational data to detect faults and anomalies. Applicant's argument is therefore unpersuasive, and the has been maintained.
The Applicant argues on page 17 "Claim 8 recites, in part, "each of the plurality of filtering rules is associated with a different building application of the plurality of separate building applications." The Examiner cites paragraph [0141] which is entirely silent with respect to filtering rules. Page 12 of the Office Action says that Zhang discloses "constraints and control to detect and diagnose specific machines in specific buildings (i.e. filtering))," but even if Zhang taught features relating to filtering to specific buildings, such disclosure would not amount to a teaching of "filtering rules is associated with a different building application of the plurality of separate building applications" (i.e., filters associated with the different applications from which data is received in Claim 1). Claim 8 is therefore not anticipated by Zhang.”.
The Examiner respectfully disagrees.
In response to the arguments in the Examiner notes the Examiner respectfully disagrees with Applicant's characterization of Zhang's teachings and provides the following clarification. First, the Examiner acknowledges Applicant's argument that par. [0141] does not explicitly use the term "filtering rules." However, Zhang teaches the functional equivalent of filtering rules associated with different building applications at multiple locations in the disclosure. Second, Zhang at par. [0086] explicitly teaches filtering associated with multiple systems: "Filtering by various attributes of events from multiple systems". This passage directly teaches: Filtering the act of applying filter criteria, Various attributes different filtering criteria/rules based on different attributes, and Multiple systems the filtering is associated with different systems (building applications). The "various attributes" used for filtering from "multiple systems" constitute filtering rules associated with different building applications. Each system (building application) has its own attributes by which data can be filtered, meaning the filtering rules are inherently associated with the different applications. Third, Zhang at par. [0141] teaches: "The integrated control layer 418 allows building operators to implement cross-system constraints and/or control logic across multiple building subsystems"
The term "constraints" in this context refers to rules or criteria applied to control and manage data across different building subsystems. These constraints function as filtering rules that determine how data from different subsystems (building applications) is processed and managed. The fact that these are "cross-system constraints" applied to "multiple building subsystems" teaches that different constraints/rules are associated with different building applications. Fourth, Zhang at par. [0144] teaches: "Integrated control layer allowing constraints and control to detect and diagnose specific machines in specific buildings". The ability to "detect and diagnose specific machines in specific buildings" requires filtering rules that are tailored to each building subsystem and application. To identify specific machines within specific buildings from aggregated data across multiple subsystems, the system must apply filtering rules that are associated with each respective building application/subsystem.
For Additional Clarification: For additional consideration the Examiner provides additional support from Zhang: par. [0086]: "Filtering by various attributes of events from multiple systems”. This is the most explicit teaching of the claimed limitation. The "various attributes" constitute different filtering rules, and these filtering rules are applied to data "from multiple systems" meaning each filtering rule/attribute is associated with a different system (building application). For example: HVAC system events are filtered by HVAC-specific attributes, Security system events are filtered by security-specific attributes and Lighting system events are filtered by lighting-specific attributes
Each set of filtering attributes constitutes filtering rules associated with a different building application. Paragraph [0142]: Zhang teaches that the FDD layer (416) performs fault detection and diagnostics across different building subsystems. To detect faults specific to each subsystem, the FDD layer must apply filtering rules specific to each building application (subsystem). A fault condition in an HVAC system requires different filtering criteria than a fault condition in a fire safety system. Paragraph [0143]: "Providing alerts related to events". Alerts are generated based on filtered data—the system must apply rules to determine which events warrant alerts. Different building applications have different alert criteria (filtering rules) based on their specific operational parameters and fault conditions.
Figure 1A-4 and par. [0143]-[0144]: Zhang depicts multiple building subsystems including: HVAC (440), Lighting (442), Security (438), Fire safety (430), Building electrical (434), ICT (436), and Lift/escalators (432). Each of these subsystems constitutes a separate building application. For the integrated control layer to manage data from all these subsystems and provide subsystem-specific fault detection and alerts, it must maintain filtering rules associated with each different building application.
With respect to claim construction consideration under the broadest reasonable interpretation, "filtering rules associated with a different building application" requires that the system maintain or apply filtering criteria that are specific to or correspond with different building applications. This does not require explicit labeling of "rules" in the reference—it requires that different filtering criteria be applied based on which building application the data originates from. Zhang satisfies this interpretation through: par. [0086]: "Filtering by various attributes of events from multiple systems" — different attributes (rules) for different systems (applications), par. [0141]: "Cross-system constraints" across "multiple building subsystems" — different constraints (rules) for different subsystems (applications), and par. [0144]: Detection and diagnosis of "specific machines in specific buildings" — requiring application-specific filtering criteria
With respect to the Applicants arguments par. [0141] is "entirely silent with respect to filtering rules." However, while par. [0141] does not use the exact phrase "filtering rules," it teaches "constraints" applied across "multiple building subsystems." Constraints that control how data is processed across different subsystems function as filtering rules. Furthermore, the Examiner's rejection relies on Zhang as a whole, including par. [0086] which explicitly teaches "filtering by various attributes...from multiple systems."
Furthermore, with respect to filtering to specific buildings does not teach filtering rules associated with different building applications. The Examiner's position is not merely that Zhang filters "to" specific buildings. Rather, Zhang teaches filtering "by various attributes" of events "from multiple systems" (par. [0086]). This means different filtering criteria (rules) are applied based on which system (building application) the data comes from. This directly teaches filtering rules associated with different building applications.
Zhang explicitly teaches at par. [0086] "filtering by various attributes of events from multiple systems"—which directly teaches filtering rules (various attributes) associated with different building applications (multiple systems). Additionally, Zhang's cross-system constraints (par. [0141]) applied to multiple building subsystems, and the subsystem-specific fault detection and diagnosis (par. [0144]), further teach filtering rules associated with different building applications. Applicant's argument is therefore unpersuasive, and the rejection is maintained.
The remaining Applicant's arguments filed 12 December 2025 have been fully considered but they are moot in view of new grounds of rejection as necessitated by amendment.
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 is directed to an abstract idea without significantly more. When considering the claim(s) 1-20 is/are as a whole and all claim elements both individually and in combination, these claims (1-20) are directed to the abstract idea of determining a timeline that includes installation and service activities without significantly more than the judicial exception itself.
Step 1
Regarding Step 1 of the Subject Matter Eligibility Test for Products and Processes (from the MPEP 2106.05(a)), claim(s) (1-17) is/are directed to a method, claim(s) (18 and 19) is/ are directed to a non-transitory computer readable media, and claims(s) (20) is/are directed to a system and therefore the claims recites a series of steps and, therefore the claims are viewed as falling in statutory categories.
Step 2A Prong 1
The claimed invention is directed to an abstract idea without significantly more. The claim(s) recite(s) a mental process. Specifically, the independent claims 1, 18, and 20 recites a mental process: as drafted, the claim recites the limitation of determining a timeline that includes installation and service activities which is a process that, under its broadest reasonable interpretation, covers performance of the limitation in the mind but for the recitation of generic computer components. That is, other than reciting a processor, nothing in the claim precludes the determining step from practically being performed in the human mind. For example, but for a processor language, the claim encompasses the user manually:
receiving data relating to a building site from a plurality of separate building applications;
aggregating the received data from the plurality of separate building applications in accordance with a predetermined format, wherein the aggregated data represents a plurality of events associated with the building site over a lifecycle of the building site;
filtering the aggregated data to identify a plurality of isolated events associated with the building site over the lifecycle of the building site, wherein each of the plurality of isolated events includes a time associated with the isolated event;
generating a timeline comprising the plurality of isolated events, wherein the timeline is arranged based on the time associated with each isolated event; and
providing the timeline on a graphical user interface, wherein each of the plurality of isolated events includes an event marker on the timeline representative of the isolated event.
While the claims could reasonably also be construed as certain methods of organizing human activity it was determined that the more applicable aspects are fall more into the analysis of information or as a mental activity and the rejection is focused accordingly. The mere nominal recitation of a generic processor does not take the claim limitation out of the mental processes grouping. It has been established by ongoing guidance that claims that contain a generic processor are still viewed as mental process when they contain limitations that can practically be performed in the human mind, however this is different for instance when the human mind is not equipped to perform the claim limitations (network monitoring, data encryption for communication, and rendering images). Therefore, these limitations are viewed a mental process.
The determining a timeline that includes installation and service activities would clearly be to a mental activity that a company would go through in order to decide how to managing site timelines. The specification makes it clear that the claimed invention is directed to the mental activity data gathering and data analysis to determine how to site timelines for installation or service activities:
Step 2A Prong 2
Specifically, the determined judicial exception is not integrated into a practical application because the generically recited computer elements do not add a meaningful limitation to the abstract idea because they amount to simply implementing the abstract idea on a computer and additionally that data receiving and providing steps required to use the correlation do not add a meaningful limitation to the method as they are insignificant extra-solution activity (including post solution activity).
The claim recites the additional element(s): that a processor is used to perform the aggregating, filtering, and generating steps. The processor in the steps is recited at a high level of generality, i.e., as a generic processor performing a generic computer function of processing data (determining a timeline that includes installation and service activities). This generic processor limitation is no more than mere instructions to apply the exception using a generic computer component. Accordingly, this additional element does not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea. The claim is directed to the abstract idea.
The claim recites the additional element(s): receiving data, and providing a timeline performs the aggregating, filtering, and generating steps. The receiving and providing steps are recited at a high level of generality (i.e., as a general means of determining a timeline that includes installation and service activities), and amounts to mere data management, which is a form of insignificant extra-solution activity. The processor that performs the aggregating, filtering, and generating steps is also recited at a high level of generality, and merely automates the aggregating, filtering, and generating steps. Each of the additional limitations is no more than mere instructions to apply the exception using a generic computer component (the processor).
The Examiner has further determined that the claims as a whole does not integrate a judicial exception into a practical application in order to provide an improvement in the functioning of a computer or an improvement to other technology or technical field. It has been determined that based on the disclosure does not provide sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement. It has not been provided clearly in the disclosure that the alleged improvement would be apparent to one of ordinary skill in the art, but is instead in a conclusory manner (i.e., a bare assertion of an improvement without the detail necessary to be apparent to a person of ordinary skill in the art, and therefore does not improve the technology. Second, in the instance, where it is not clear that the specification sets forth an improvement in technology, the claim must reflect the disclosed improvement (the claims must include components or steps of the invention that provide the improvement described in the specification).
For further clarification the Examiner points out that the claim(s) 1-20 recite(s) receiving data, aggregating the received data, filtering the aggregated data, generating a timeline, and providing the timeline which are viewed as an abstract idea in the form of a mental process. This judicial exception is not integrated into a practical application because the use of a computer for receiving, aggregating, filtering, generating, and providing which is the abstract idea steps of valuing an idea (determining a timeline that includes installation and service activities) in the manner of “apply it”.
Thus, the claims recites an abstract idea directed to a mental process (i.e. to determining a timeline that includes installation and service activities). Using a computer to receiving, aggregating, filtering, generating, and providing the data resulting from this kind of mental process merely implements the abstract idea in the manner of “apply it”.
The dependent claims recite elements that narrow the metes and bounds of the abstract idea but do not provide ‘something more’.
The dependent claims do not remedy these deficiencies.
Claims 4-9 recite limitations which further limit the claimed analysis of data.
Claims 2, 3, 10-13, 16, 17, and 19 recites limitations directed to claim language viewed insignificantly extra solution activity.
Using a computer to perform the data processing as claimed is merely implementing the abstract idea in the manner of “apply it” and does not provide significantly more. Additionally with respect to the Berkheimer the Examiner points out that the steps of the claim are viewed to be to nothing more than spell out what it means to apply it on a computer and cannot confer patent-eligibility as there are no additional limitations beyond applying an abstract idea, restricted to a computer. As the claims are merely implementing the abstract idea in the manner of “Apply It” the need for a Berkheimer analysis does not apply and is not required. With respect to the currently filed claims the implementing steps can be found in Zhang which discloses how the claims alone and in combination are viewed to be well understood, routine and conventional based on point 3 of the Berkheimer memo and subsequent evidence, complying with and providing evidence.
Claims 14 and 15 recites limitations directed to claim language viewed non-functional data labels.
Thus, the problem the claimed invention is directed to answering the question based on determining a timeline that includes installation and service activities. This is not a technical or technological problem but is rather in the realm of project management and scheduling and therefore an abstract idea.
Step 2B
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception because as discussed with respect to Step 2A Prong Two, the additional element in the claim amounts to no more than mere instructions to apply the exception using a generic computer component.
The same analysis applies here in 2B, i.e., mere instructions to apply an exception using a generic computer component cannot integrate a judicial exception into a practical application at Step 2A or provide an inventive concept in Step 2B. This is the case because in order for the claims to be viewed as significantly more the claims must incorporate the integral use of a machine to achieve performance of a method, in contrast to where the machine is merely an object on which the method operates, which does not provide significantly more in order for a machine to add significantly more, it must play a significant part in permitting the claimed method to be performed, rather than function solely as an obvious mechanism for permitting a solution to be achieved more quickly. Whether its involvement is extra-solution activity or a field-of-use, i.e., the extent to which (or how) the machine or apparatus imposes meaningful limits on the claim. Use of a machine that contributes only nominally or insignificantly to the execution of the claimed method (e.g., in a data gathering step or in a field-of-use limitation) would not provide significantly more. Additionally, another consideration when determining whether a claim recites significantly more is whether the claim effects a transformation or reduction of a particular article to a different state or thing. "[T]ransformation and reduction of an article ‘to a different state or thing’ is the clue to patentability of a process claim that does not include particular machines. All together the above analysis shows there is not improvement in computer functionality, or improvement to any other technology or technical field. The claim is ineligible.
Additionally, with respect to the Berkheimer as noted above the same analysis applies to the 2B where the claims are viewed as applying it and as such no further analysis is required. However, with respect to the current claims receiving data and providing the timeline on a graphical user interface that are viewed as extra solution or post solution activity the Examiner notes that the claims are viewed as well-understood, routine, and conventional because a citation to a publication that demonstrates the well-understood, routine, conventional nature of the additional element(s). An appropriate publication such as the currently cited prior art Zhang et al. (U.S. Patent Publication 2023/0297054 A1) provides those extra solution activities and is viewed as a form of publication which also includes a book, manual, review article, or other source that describes the state of the art and discusses what is well-known and in common use in the relevant industry. The claim is ineligible.
The dependent claims recite elements that narrow the metes and bounds of the abstract idea but do not provide ‘something more’. Specifically, the dependent claims do not remedy these deficiencies of the independent claims.
With respect to the legal concept of prima facie case being a procedural tool of patent examination, which allocates the burdens going forward between the examiner and the applicant. MPEP § 2106.07 discusses the requirements of a prima facie case of ineligibility. In particular, the initial burden was on the Examiner and believed to be properly provided as to explain why the claim(s) are ineligible for patenting because of the above provided rejection which clearly and specifically points out in accordance with properly providing the requirement satisfying the initial burden of proof based on the Guidance from the United States Patent and Trademark Office and the burden now shifts to the applicant.
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)(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(s) 1-3, 5-8, and 10-20 is/are rejected under 35 U.S.C. 102(a)(2) as being anticipated by Zhang et al. (U.S. Patent Publication 2023/0297054 A1).
Referring to Claim 1, Might teaches a method for generating a rating scale to be used in an evaluation form, said method comprising:
receiving data relating to a building site from a plurality of separate building applications (see; Abstract of Zhang teaches receiving data from a building site from one of multiple buildings).
aggregating the received data from the plurality of separate building applications in accordance with a predetermined format, wherein the aggregated data represents a plurality of events associated with the building site over a lifecycle of the building site (see; par. [0141]-[0144] of Zhang teaches aggregating data that representing events of a building resources, par. [0147] from multiple buildings).
filtering the aggregated data to identify a plurality of isolated events associated with the building site over the lifecycle of the building site, wherein each of the plurality of isolated events includes a time associated with the isolated event (see; par. [0086] of Zhang teaches filtering various attributes of events from multiple buildings, par. [0141]-[0142] gathered from aggregated data, par. [0145] including time series data associated with the events).
generating a timeline comprising the plurality of isolated events, wherein the timeline is arranged based on the time associated with each isolated event (see; par. [0141]-[0142] and par. [0145] of Zhang teaches time series data that shows the performance of the events, where the time series data is associated with the events).
providing the timeline on a graphical user interface, wherein each of the plurality of isolated events includes an event marker on the timeline representative of the isolated event (see; par. [0145] of Zhang teaches a data generated by a building system that provides information about a system and specific processes as well as operations that can be viewed on a, par. [0148] display of a graphical user interface including, par. [0145] including time series data).
Referring to Claim 2, see discussion of claim 1 above, while Zhang teaches the method above, Zhang further discloses a method having the limitations of:
receiving the data relating to the building site from the plurality of separate building applications includes receiving data from two or more of a commissioning application, a service application, a sales management application, a business solutions application, and a performance verification tool (see; par. [0135] of Zhang teaches receiving inputs, par. [0127] which includes external applications that monitor events (i.e. monitor performance), and par. [0092] application services (i.e. service applications)).
Referring to Claim 3, see discussion of claim 1 above, while Zhang teaches the method above, Zhang further discloses a method having the limitations of:
receiving the data relating to the building site from the plurality of separate building applications includes receiving data arranged in one or more different data formats (see; par. [0166] of Zhang teaches receiving data in multiple data formats).
Referring to Claim 5, see discussion of claim 3 above, while Zhang teaches the method above, Zhang further discloses a method having the limitations of:
aggregating the received data from the plurality of separate building applications in accordance with the predetermined format includes generating a table, the table including associations between building site identifiers of the one or more different data formats and a unified building site identifier (see; par. [0141]-[0144] of Zhang teaches aggregating data that representing events of a building resources, par. [0086] then taking the data and filtering the information, par. [0165]-[0167] taking all data, par. [0111] utilizing discovery tables to store data variables related to the equipment, par. [0144] where specific identifier for equipment for equipment in specific building).
Referring to Claim 6, see discussion of claim 1 above, while Zhang teaches the method above, Zhang further discloses a method having the limitations of:
filtering the aggregated data to identify the plurality of isolated events includes obscuring additional events associated with the building site over the lifecycle of the building site such that the plurality of isolated events provide an overall view of the lifecycle of the building site (see; par. [0086] of Zhang teaches filtering by various attributes of multiple systems, par. [0143] providing an alert related to the events, par. [0145] along with the associated time series data).
wherein the isolated events represented by event markers comprise a first event determined from first data from a first building application of the plurality of separate building applications and a second event corresponding to a second building application determined from second data from a second building application of the plurality of separate building applications (see; par. [0143]-[0144] of Zhang teaches events from HVAC subsystems, par. [0145] faults alerts from building systems, Figure 7 installation services (teaches first event determined from first data from first building application), par. [0143]-[0144] events from lighting subsystem, security, fire safety, fig. 7 service activities (teaches second event determined from second data from second building application), par. [0141] multiple building subsystems, par. [0086] multiple systems, Figs 1A-4 HVAC, lighting security, fire safety, building electrical, ICT, Lift/escalators (teaches plurality of separate building applications, par. [0145] faults and alerts displayed, fig. 7 workflow activities, par. [0106] icons representing events (teaches isolated events represented by event markers).
Referring to Claim 7, see discussion of claim 1 above, while Zhang teaches the method above, Zhang further discloses a method having the limitations of:
filtering the aggregated data to identify the plurality of isolated events includes filtering the aggregated data using a machine learning model trained using historical data associated with a plurality of building sites (see; par. [0137] of Zhang teaches a control module to initiate control actions to identify and manage events associated with machining in the buildings, par. [0137] analyzed by models).
Referring to Claim 8, see discussion of claim 1 above, while Zhang teaches the method above, Zhang further discloses a method having the limitations of:
filtering the aggregated data to identify the plurality of isolated events includes filtering the aggregated data using a plurality of filtering rules, wherein each of the plurality of filtering rules is associated with a different building application of the plurality of separate building applications (see; par. [0141] of Zhang teaches integrated control layer that allows for constraints and control to detect and diagnose specific machines in specific buildings (i.e. filtering)).
Referring to Claim 10, see discussion of claim 9 above, while Zhang teaches the method above, Zhang further discloses a method having the limitations of:
providing the timeline on the graphical user interface includes providing the additional event with an event marker that is different than the event markers of the plurality of isolated events (see; par. [0145] of Zhang teaches a data generated by a building system that provides information about a system and specific processes as well as operations (i.e. isolated event) that can be viewed on a, par. [0148] display of a graphical user interface including, par. [0145] including time series data).
Referring to Claim 11, see discussion of claim 9 above, while Zhang teaches the method above, Zhang further discloses a method having the limitations of:
receiving an approval of the additional event from a user, and updating the timeline on the graphical user interface to include the additional event on the timeline (see; par. [0106] of Zhang teaches adding, removing, and change points for machines to modify events, par. [0145] to define data generated building systems about a system and process that can be viewed, par. [0148] on a graphical user interface).
Referring to Claim 12, see discussion of claim 1 above, while Zhang teaches the method above, Zhang further discloses a method having the limitations of:
providing the timeline on the graphical user interface includes providing the timeline with a health indicator, wherein the health indicator provides an indication of an overall health of the building site at a point in time along the timeline (see; par. [0056] of Zhang teaches diagnostics and stat us information (i.e. health), par. [0064] displayed on a graphical user interface, par. [0145] including a time series of the health events).
Referring to Claim 13, see discussion of claim 1 above, while Zhang teaches the method above, Zhang further discloses a method having the limitations of:
providing the timeline on the graphical user interface comprises providing a table associated with one or more points in time along the timeline (see; par. [0145] of Zhang teaches providing a time series for events, par. [0064] on a graphical user interface, par. [0097] in the form of a table).
wherein the table includes characteristics relating to a component of the building site at a first point in time along the timeline and a second point in time along the timeline (see; par. [0097] of Zhang teaches the use of a table to provide, par. [0111] equipment data in a table, par. [0145] along with time series data).
providing the table associated with the one or more points in time along the timeline comprises (see; par. [0097] of Zhang teaches the use of a table to provide, par. [0111] equipment data in a table, par. [0145] along with time series data).
providing a change identifier, the change identifier indicating a change in the characteristic of the component of the building site between the first point in time and the second point in time (see; par. [0143]-[0145] of Zhang teaches a fault detector and diagnostic identification that can send an alert message as well as a schedule (i.e. time series data)).
providing an element health indicator, the element health indicator providing an indication of an overall health of the component of the building site between the first point in time and the second point in time (see; par. [0063] of Zhang teaches providing information measurements, positions, operating statuses, and diagnostics (i.e. health), par. [0145] including faults a and communication with time series data).
Referring to Claim 14, see discussion of claim 1 above, while Zhang teaches the method above, Zhang further discloses a method having the limitations of:
providing the timeline on the graphical user interface includes providing a topic selection bar including a plurality of topic selection icons, and wherein in response to a selection of one or more of the plurality of topic selection icons the method further comprises providing one or more topic report displays, wherein providing the one or more topic report displays includes providing one of a service report graph indicating a number of service visits performed at the building site over the timeline, a ticket report graph indicating a number of tickets close over the timeline, a work order graph indicating a number of open work orders over the timeline, and a system change graph indicating a number of system changes associated with the building site over the timeline (see; par. [0106] of Zhang teaches the visualization of equipment (i.e. icon) par. [0098] where the equipment is selected, par. [0127] an a report interface shows data regarding each building subsystems, par. [0145] which also provides time series data).
Referring to Claim 15, see discussion of claim 1 above, while Zhang teaches the method above, Zhang further discloses a method having the limitations of:
providing the timeline on the graphical user interface includes providing a project timeline associated with a project at the building site, the project timeline including a phase indicator indicating a phase of the project at a point in time along the project timeline, wherein providing the project timeline includes providing a status indicator, the status indicator indicating a status of the project compared to a projected timeline associated with the project (see; par. [0148] of Zhang teaches project workflows that indicates services to track project statuses (i.e. timeline), par. [0145] which also provides time series data, par. [0064] on a graphical user interface, par. [0148] which also provides the tracking of project statuses and updating schedules that include financial forecasting that further provides ongoing status of the equipment).).
Referring to Claim 16, see discussion of claim 1 above, while Zhang teaches the method above, Zhang further discloses a method having the limitations of:
providing a recommendation interface on the graphical user interface, wherein the recommendation interface includes an issue identification icon designating an identified issue, a recommendation display including a recommendation for addressing the identified issue, and a health potential indicator providing an indication of a projected overall health of the building site based on the recommendation (see; par. [0145] of Zhang teaches providing an alert for repair and faults, par. [0120] and then providing a recommendation for control parameter to address issues).
Referring to Claim 16, see discussion of claim 1 above, while Zhang teaches the method above, Zhang further discloses a method having the limitations of:
automatically causing, based on the data relating to the building site, an intervention at the building site to affect building health and adding the intervention to the timeline on the graphical user interface (see; par. [0145] of Zhang teaches automatically control parameters to address issues is using the business management system).
Referring to Claim 18, Zhang teaches one or more non-transitory computer readable media. Claim 18 recites the same or similar limitations as those addressed above in claim 1, Claim 18 is therefore rejected for the same reasons as set forth above in claim 1, except for the following noted exception.
providing, on a graphical user interface, a timeline comprising event markers representing a plurality of isolated events filtered from the data, the event markers spatially along the timeline based on times associated with the isolated events (see; fig. 7 of Zhang teaches a CAP dashboard and time series displays, par. [0145] inherently present events in temporal arrangement: "event markers spatially arranged along the timeline based on times associated with the isolated events", fig. 7: Workflow activities (712-730) arranged sequentially according to project phase timing; par. [0148] "timeline," "tracking project statuses and updating schedules”).
Referring to Claim 19, see discussion of claim 18 above, while Zhang teaches the non-transitory computer readable media above Claim 19 recites the same or similar limitations as those addressed above in claim 17, Claim 19 is therefore rejected for the same or similar limitations as set forth above in claim 17.
Referring to Claim 20, Zhang teaches a building system. Claim 20 recites the same or similar limitations as those addressed above in claims 1 and 2, Claim 20 is therefore rejected for the same reasons as set forth above in claim 1 and 2, except for the following noted exceptions.
building equipment operable to heat, cool, or ventilate a building (see; par. [0038] of Zhang teaches the equipment that is operated includes heating, cooling and ventilation).
providing a graphical user interface comprising a line representing time and event markers positioned along the line, wherein the event markers are associated with isolated events identified from the data from the plurality of building applications and are arranged on the line based on times associated with the isolated events (see; fig. 7 of Zhang teaches a line representing time", par. [0145] and par. [0148] sequential workflow arrangement; par. [0148] "time series data...viewable on display", and "timeline", "event markers positioned along the line", Zhang teaches FIG. 7: Workflow activities (712-730), tasks (714) positioned in sequential/temporal order; par. [0106] icons representing events).
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 may not be obtained through the invention is not identically disclosed or described as set forth in section 102, if the differences between the subject matter sought to be patented and the prior art are such that the subject matter as a whole would have been obvious at the time the invention was made to a person having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 4 and 9 is/are rejected under 35 U.S.C. 103 as being unpatentable over Zhang et al. (U.S. Patent Publication 2023/0297054 A1) in view of Knox (U.S. Patent Publication 2020/0364588 A1).
Referring to Claim 4, see discussion of claim 3, above, while Zhang teaches the method above, Zhang does not explicitly disclose a method having the limitations of, however,
Knox teaches converting, via one or more conversion rules, the received data from the plurality of separate building applications into a unified data format (see; par. [0008] of Knox teaches converting to standardized data format).
The Examiner notes that Zhang teaches similar to the instant application teaches virtual commissioning of building management systems. Specifically, Zhang discloses a building management system that receives building data that can be sued to remotely control the building it is therefore viewed as analogous art in the same field of endeavor. Additionally, Knox teaches recommendations in ubiquitous computing environments using machine learning models in living spaces and as it is comparable in certain respects to Zhang which virtual commissioning of building management systems as well as the instant application it is viewed as analogous art and is viewed as reasonably pertinent to the problem faced by the inventor. This provides support that it would be obvious to combine the references to provide an obviousness rejection.
Zhang discloses the a building management system that receives building data that can be sued to remotely control the building. However, Zhang fails to disclose converting, via one or more conversion rules, the received data from the plurality of separate building applications into a unified data format.
Zhang discloses converting, via one or more conversion rules, the received data from the plurality of separate building applications into a unified data format.
It would be obvious to one of ordinary skill in the art to include in the task management
(system/method/apparatus) of Zhang the converting, via one or more conversion rules, the received data from the plurality of separate building applications into a unified data format as taught by Knox since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Additionally, Zhang and Knox teach the collecting and analysis of data in order to manage building resources and they do not contradict or diminish the other alone or when combined.
Referring to Claim 9, see discussion of claim 1, above, while Zhang teaches the method above, Zhang does not explicitly disclose a method having the limitations of, however,
Knox teaches generating, via an artificial intelligence (AI) model trained using historical data associated with a plurality of building sites, an additional event and a time associated with the additional event to be included in the timeline (see; par. [0050] of Knox teaches the utilization of an artificial intelligence to provide solutions for environments, par. [0077] that is trained in order to analyze and utilize large data sets, par. [0091] including historical data sets to determine opportunities and provide, par. [0013] time, location and frequency data, par. [0077] and par. [0082] that then generates a recommendation that uses the historical data that models possible interactions to anticipate future outcomes and schedules activities (i.e. additional events and timing)).
The Examiner notes that Zhang teaches similar to the instant application teaches virtual commissioning of building management systems. Specifically, Zhang discloses a building management system that receives building data that can be sued to remotely control the building it is therefore viewed as analogous art in the same field of endeavor. Additionally, Knox teaches recommendations in ubiquitous computing environments using machine learning models in living spaces and as it is comparable in certain respects to Zhang which virtual commissioning of building management systems as well as the instant application it is viewed as analogous art and is viewed as reasonably pertinent to the problem faced by the inventor. This provides support that it would be obvious to combine the references to provide an obviousness rejection.
Zhang discloses the a building management system that receives building data that can be sued to remotely control the building. However, Zhang fails to disclose generating, via an artificial intelligence (AI) model trained using historical data associated with a plurality of building sites, an additional event and a time associated with the additional event to be included in the timeline.
Zhang discloses generating, via an artificial intelligence (AI) model trained using historical data associated with a plurality of building sites, an additional event and a time associated with the additional event to be included in the timeline.
It would be obvious to one of ordinary skill in the art to include in the task management
(system/method/apparatus) of Zhang generating, via an artificial intelligence (AI) model trained using historical data associated with a plurality of building sites, an additional event and a time associated with the additional event to be included in the timeline as taught by Knox since the claimed invention is merely a combination of old elements, and in the combination each element merely would have performed the same function as it did separately, and one of ordinary skill in the art would have recognized that the results of the combination were predictable. Additionally, Zhang and Knox teach the collecting and analysis of data in order to manage building resources and they do not contradict or diminish the other alone or when combined.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Nayak et al. (U.S. Patent Publication 2019/0034309 A1) discloses a building management system with fault detection and diagnostics visualization.
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 STEPHEN S SWARTZ whose telephone number is (571)270-7789. The examiner can normally be reached Mon-Fri 9:00 - 6:00.
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, Boswell Beth can be reached at 571 272-6737. 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.
/S.S.S/Examiner, Art Unit 3625
/BETH V BOSWELL/Supervisory Patent Examiner, Art Unit 3625
Prosecution Insights