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 .
Status of Claims
This Office Action is in response to Applicant’s amendment filed on 3/5/2026.
Claims 11-17 are withdrawn. Claim 18 is canceled. Claim 21 is newly added. Claims 1-10 and 19-21 are pending.
Response to Amendment
Applicant’s amendments have fixed the deficiencies set forth in the previous Office Action hence the respective rejections/objections have been withdrawn, except for those rejections/objections if still maintained or newly added in this Office Action. Particularly the objections and 112(b) rejections are withdrawn. The interpretations under 112(f) are withdrawn.
Regarding the double patenting rejection, the Office acknowledges Applicant’s intention to hold it in abeyance until allowable subject matter is identified. For purpose of record, the double patenting rejection is maintained in this Office action.
Regarding the 103 rejections, claims have been amended to add in new limitations. However, the added limitations are also taught by prior arts. See the sections of “response to arguments” and 103 rejections for details.
Response to Arguments
Regarding Applicant’s arguments about the rejections for claims under 35 U.S.C § 103, the arguments have been fully considered.
Regarding claims 1, 4, 5 and 9, Applicant has added new limitations to claim 1 and argued in substance that (1) reference Church only teaches an end-user device allowing a user to interact with a computing environment but does not teach microservices to control/monitor building equipment; (2) reference Franchitti only teaches an IP address of a microservices container but does not teach using endpoint of microservices to facilitate communication between the microservices for controlling/monitoring building equipment.
As per point (1), Church teaches in [0026] that “End-user devices 150 may include any type of device that allows a user to interact with the components of computing environment 100”. The word “may” teaches that the device 150 can include other type of device. Actually Church further teaches in [0026] that “End-user devices 150 may include, ... smart appliances (e.g., …, home automation systems, heat-ventilation-air-conditioning (HVAC) appliances), and the like”. This teaches that the device 150 is home automation system or HVAC appliance which uses microservices to control home/building.
As per point (2), as Applicant teaches in specification [0080, 0081, 0090] that a plurality of containers each contains one endpoint to facilitate communicate. Franchitti teaches in [0620] that “Cross-container management and communication when using multiple containers is facilitated by giving each container its own set of virtual network devices and a unique IP address”. This teaches each container includes an endpoint with a unique IP address to communicate via a system bus. Since Church teaches a plurality of containers containing microservices for HVAC equipment, it is obvious to Franchitti’s teaching into Church so that each container has its own endpoint to facilitate communication between the plurality of microservices for HVAC equipment.
Therefore, claim 1 with amendments is still rejected by Church in view of Franchitti.
Applicant’s arguments for other claims, which depend on the argued patentability of claim 1, are also traversed by Examiner based on the reasons recited above.
Therefore, the rejections are maintained.
Double Patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine grounded in public policy (a policy reflected in the statute) so as to prevent the unjustified or improper timewise extension of the “right to exclude” granted by a patent and to prevent possible harassment by multiple assignees. A nonstatutory double patenting rejection is appropriate where the conflicting claims are not identical, but at least one examined application claim is not patentably distinct from the reference claim(s) because the examined application claim is either anticipated by, or would have been obvious over, the reference claim(s). See, e.g., In re Berg, 140 F.3d 1428, 46 USPQ2d 1226 (Fed. Cir. 1998); In re Goodman, 11 F.3d 1046, 29 USPQ2d 2010 (Fed. Cir. 1993); In re Longi, 759 F.2d 887, 225 USPQ 645 (Fed. Cir. 1985); In re Van Ornum, 686 F.2d 937, 214 USPQ 761 (CCPA 1982); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Thorington, 418 F.2d 528, 163 USPQ 644 (CCPA 1969).
Claim 19 is rejected on the ground of nonstatutory double patenting as being unpatentable over claim 11 of U.S. Patent No. 11662701 B2 (hereinafter as “Pat_701”). Although the claims at issue are not identical, they are not patentably distinct from each other because application claim 19 is anticipated by patent claim 11.
Table has been created below to compare claim 19 of the instant application and claim 11 of the Pat_701.
Instant application
Pat_701
19. A server for a building automation system (BAS), the server comprising:
a microservices platform configured to execute various processes within the BAS, the microservices platform comprising:
a plurality of nodes wherein each of the plurality of nodes is configured to run one or more services as separate processes; and
an orchestration network configured to control communication between the plurality of nodes;
a common data model (CDM) shared between the plurality of nodes wherein the common data model comprises metadata of the BAS; and
a container orchestration platform configured to manage and control the plurality of nodes.
11. A server for a building automation system (BAS), the server comprising processing circuitry configured to implement:
a microservices platform configured to execute various processes within the BAS, the microservices platform comprising:
a plurality of nodes configured to run one or more services as separate processes; and
an orchestration network configured to control communication between the plurality of nodes;
a common data model (CDM) shared between the plurality of nodes and used by the one or more services run on the plurality of nodes wherein the CDM comprises metadata of the BAS, the metadata defining a plurality of relationships between physical equipment, spaces, and networked devices of the BAS; and
a container orchestration platform configured to manage and control the plurality of nodes.
In the table above, all matching elements of the claim limitations are underlined.
As illustrated in the table above, claim 11 of Pat_701 teaches all the limitations of claim 19 of the instant application. Although the claims at issue are not identical, it has been held that a generic invention is “anticipated” by a “species” within the scope of the generic invention. See In re Goodman, 29 USPQ2d 2010 (Fed. Cir. 1993).
Similarly, claim 20 of instant application are also anticipated by claim 12 of Pat_701.
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the reference application or patent either is shown to be commonly owned with the examined application, or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. See MPEP § 717.02 for applications subject to examination under the first inventor to file provisions of the AIA as explained in MPEP § 2159. See MPEP §§ 706.02(l)(1) - 706.02(l)(3) for applications not subject to examination under the first inventor to file provisions of the AIA . A terminal disclaimer must be signed in compliance with 37 CFR 1.321(b).
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used. A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/process/file/efs/guidance/eTD-info-I.jsp.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 4, 5 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Church (US 20180088935 A1, prior art of record, hereinafter as “Church”) in view of FRANCHITTI (US 2019/0171438 A1, prior art of record, hereinafter as “FRANCHITTI”).
Regarding claim 1, Church teaches:
A building automation system (BAS) (100 in FIG. 1 and [0026]: “End-user devices 150 may include, ... smart appliances (e.g., …, home automation systems, heat-ventilation-air-conditioning (HVAC) appliances), and the like.”), the system comprising:
a microservices computing platform (microservices application 410B in FIG. 4B) configured to execute various processes within the BAS (as shown in FIG. 4B, 410B execute microservices/processes within the system), the microservices computing platform comprising:
a plurality of microservice containers (containers 514 in FIG. 5) comprising microservices that distribute software functionality ([0055]: “various orchestration tools and/or orchestration environments may be used to facilitate or automate deployment, scaling, and/or operations of containerized applications”) to control building equipment or monitor the building equipment ([0026]: “End-user devices 150 may include, ... smart appliances (e.g., …, home automation systems, heat-ventilation-air-conditioning (HVAC) appliances), and the like”. This teaches the containerized microservices are for controlling/monitoring building equipment such as HVAC or home automation system);
a container orchestration computing platform (environment 500 in FIG. 5 and [0055], [0083-0084]) configured to monitor ([0056]: “while the runtime environment of a microservice container of an application is being monitored, any suspicious or unnecessary activity by the microservice container may be identified”), deploy ([0055]: “various orchestration tools and/or orchestration environments may be used to facilitate or automate deployment, scaling, and/or operations of containerized applications”), start, or restart ([0050]: “microservice B may then be configured, for example, by launching microservice B or restarting the microservices application to launch microservices A and B together”) the microservices associated with the plurality of microservice containers.
Church teaches all the limitations except a system bus in communication with the plurality of microservice containers, wherein each microservice comprises an endpoint to facilitate communication between the microservices to implement the control of the building equipment or the monitoring of the building equipment, the endpoint being exposed for the plurality of microservice containers.
However, FRANCHITTI teaches in an analogous art:
a system bus in communication with the plurality of microservice containers, wherein each microservice comprises an endpoint to facilitate communication between the microservices, the endpoint being exposed for the plurality of microservice containers ([0620]: “Cross-container management and communication when using multiple containers is facilitated by giving each container its own set of virtual network devices and a unique IP address”. This teaches each microservice container includes an endpoint with a unique IP address to communicate via a system bus).
Since Church teaches containers comprising microservices for controlling/monitoring building equipment, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Church based on the teaching of FRANCHITTI, to make the building automation system a system bus in communication with the plurality of microservice containers, wherein each microservice comprises an endpoint to facilitate communication between the microservices to implement the control of the building equipment or the monitoring of the building equipment, the endpoint being exposed for the plurality of microservice containers. One of ordinary skill in the art would have been motivated to do this modification since it can help facilitate “cross-container management and communication”, as FRANCHITTI teaches in [0620].
Regarding claim 4, Church-FRANCHITTI teach(es) all the limitations of its base claim from which the claim depends.
Church further teaches:
the microservices computing platform is deployed on at least one cloud server (FIG. 1: one or more of the nodes are deployed on application server 130 which is remote/(in cloud)).
Regarding claim 5, Church-FRANCHITTI teach(es) all the limitations of its base claim from which the claim depends.
Church further teaches:
the plurality of microservice containers are from a decomposition of server functionality ([0072]: “A microservices application, for example, may be implemented using multiple separate and self-contained applications, or microservices, that each provide a particular service and collectively form a fully functional application”. This teaches to decomposite a full server function into multiple separate and self-contained microservices in containers).
FRANCHITTI further teaches:
the endpoint exposes an application programming interface ([0620]: each container comprises an endpoint with unique address for application programming interface).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have further modified Church based on the teaching of FRANCHITTI, to make the building automation system wherein the endpoint exposes an application programming interface. One of ordinary skill in the art would have been motivated to do this modification since it can help facilitate “cross-container management and communication”, as FRANCHITTI teaches in [0620].
Regarding claim 9, Church-FRANCHITTI teach all the limitations of its base claim from which the claim depends.
Church further teaches:
the container orchestration computing platform is configured to deploy one or more copies of one or more nodes ([0075]: “Microservices can be scaled by deploying any number of instances of a particular microservice needed to satisfy the capacity and availability constraints of that microservice”. This teaches any number of the microservices can be copied and deployed for more efficient load balancing).
Claims 2 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Church in view of FRANCHITTI, and in further view of Allmaras (US 2019/0286078 A1, prior art of record, hereinafter as “Allmaras”).
Regarding claim 2, Church-FRANCHITTI teach(es) all the limitations of its base claim from which the claim depends on.
FRANCHITTI further teaches:
the system bus comprises a message bus configured to control communication between processes, and wherein the container orchestration computing platform comprises an orchestration network configured to control communication ([0620]: FRANCHITTI teaches a bus to control communication between microservices processes wherein an orchestration network coordinates the communication).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have further modified Church based on the teaching of FRANCHITTI, to make the building automation system wherein the system bus comprises a message bus configured to control communication between processes, and wherein the container orchestration computing platform comprises an orchestration network configured to control communication. One of ordinary skill in the art would have been motivated to do this modification since it can help facilitate “cross-container management and communication”, as FRANCHITTI teaches in [0620].
Church-FRANCHITTI teach(es) all the limitations, but they don’t teach a common data model (CDM) is shared between the plurality of microservice containers, the common data model comprising metadata of the BAS.
However, Allmaras teaches in an analogous art:
a common data model (CDM) is shared between the plurality of microservice containers, the common data model comprising metadata of the system ([0011]: “the data model can be provided by virtue of an unparameterized data model with data components associated with the system components ..”; And [0067]: “The use of independently usable functional modules FM accessing a common data model DM allows the control device CTL to be matched to different applications particularly easily. ... Said application information can specify in particular an intended application, such as e.g. monitoring, forecast or optimization of the technical system TS. As well as that, the functional modules FM can also be embodied as microservices in edge computing environments or cloud computing environments”. All these teach a CDM shared by multiple microservices and the CDM comprises metadata of the system to control).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Church-FRANCHITTI based on the teaching of Allmaras, to make the building automation system wherein a common data model (CDM) is shared between the plurality of microservice containers, the common data model comprising metadata of the BAS. One of ordinary skill in the art would have been motivated to do this modification since it can help match “different applications particularly easily”, as Allmaras teaches in [0067].
Regarding claim 19, Church teaches:
A server (application server 130 in Fig. 1) for a building automation system (BAS) (100 in FIG. 1. [0026]: “End-user devices 150 may include, ... smart appliances (e.g., …, home automation systems, heat-ventilation-air-conditioning (HVAC) appliances), and the like.”), the server comprising:
a microservices computing platform (microservices application 410B in FIG. 4B) comprising:
a plurality of microservice containers (containers 514 in FIG. 5) comprising microservices that distribute software functionality ([0055]: “various orchestration tools and/or orchestration environments may be used to facilitate or automate deployment, scaling, and/or operations of containerized applications”) to control building equipment or monitor the building equipment ([0026]: “End-user devices 150 may include, ... smart appliances (e.g., …, home automation systems, heat-ventilation-air-conditioning (HVAC) appliances), and the like”. This teaches the containerized microservices are for controlling/monitoring building equipment such as HVAC or home automation system);
a system bus in communication with the plurality of microservice containers for communication between microservices associated with the plurality of microservice containers ([0073]: “Microservices are often designed to communicate using simple and well-known communication methods and protocols, …”. This teaches there is a bus to communicate between the separate microservices in containers).
a container orchestration computing platform (container environment 500 in FIG. 5) configured to manage and control a plurality of nodes ([0083-0084]: “container environment 500 includes infrastructure 502,operating system 504, container engine 506, and software containers 514…. Container engine 506 includes software responsible for providing and managing the containerized environment 500, ….Software containers 514 are containers that execute distinct software components in their own respective environments. In the illustrated example, containers 514 each include a microservice515 and its associated dependencies 516. For example, container 514a includes microservice A(515a) and its dependencies (516a), container 514b includes microservice B (515b) and its dependencies (516b), and container 514c includes microservice C (515c) and its dependencies(516c). These microservices 515 may collectively form a microservices application that is executing on infrastructure 502 in a containerized environment 500”. This teaches the container environment 500 manage and control the plurality of nodes/(microservices containers)).
Church teaches all the limitations except that each microservice comprises an endpoint to facilitate communication between the microservices to implement the control of the building equipment or the monitoring of the building equipment; a common data model (CDM), wherein the common data model comprises metadata of the BAS.
However, FRANCHITTI teaches in an analogous art:
each microservice comprises an endpoint to facilitate communication between the microservices ([0620]: “Cross-container management and communication when using multiple containers is facilitated by giving each container its own set of virtual network devices and a unique IP address”. This teaches each microservices container includes an endpoint/(virtual network device) with a unique IP address to communicate via a system bus).
Since Church teaches containers comprising microservices for controlling/monitoring building equipment, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Church based on the teaching of FRANCHITTI, to make the building automation system wherein each microservice comprises an endpoint to facilitate communication between the microservices to implement the control of the building equipment or the monitoring of the building equipment. One of ordinary skill in the art would have been motivated to do this modification since it can help facilitate “cross-container management and communication”, as FRANCHITTI teaches in [0620].
Church-FRANCHITTI teaches all the limitations except a common data model (CDM), wherein the common data model comprises metadata of the BAS.
However, Allmaras teaches in an analogous art:
a common data model (CDM), wherein the common data model comprises metadata of the system ([0011]: “the data model can be provided by virtue of an unparameterized data model with data components associated with the system components ..”; And [0067]: “The use of independently usable functional modules FM accessing a common data model DM allows the control device CTL to be matched to different applications particularly easily. ... Said application information can specify in particular an intended application, such as e.g. monitoring, forecast or optimization of the technical system TS. As well as that, the functional modules FM can also be embodied as microservices in edge computing environments or cloud computing environments”. All these teach a CDM shared by multiple microservices and the CDM comprises metadata of the system to control).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Church-FRANCHITTI based on the teaching of Allmaras, to make the server to further comprise a common data model (CDM), wherein the common data model comprises metadata of the BAS. One of ordinary skill in the art would have been motivated to do this modification since it can help match “different applications particularly easily”, as Allmaras teaches in [0067].
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Church in view of FRANCHITTI, and in further view of VERBRUGH (US 2018/0376570 A1, prior art of record, hereinafter as “VERBRUGH”).
Regarding claim 3, Church-FRANCHITTI teach(es) all the limitations of its base claim from which the claim depends.
Church further teaches:
the microservices computing platform is deployed on at least one physical server ([0084]: “Infrastructure 502 includes the underlying hardware and/or software infrastructure used to provide the containerized environment, such as an application server”).
Church-FRANCHITTI teach(es) all the limitations but do not explicitly teach the physical server is on-premise of the building automation system, wherein the endpoint is accessed via Hyper Text Transfer Protocol Secure (HTTPS) and/or Hyper Text Transfer Protocol (HTTP).
However, VERBRUGH teaches in an analogous art:
the physical server is on-premise of the building automation system ([0080]: “the database server 30 is local in the sense that it is part of the lighting system infrastructure itself (e.g. being located in the same building, and forming part of a building automation system”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Church-FRANCHITTI based on the teaching of VERBRUGH, to make the building automation system wherein the at least one physical server is on-premise of the building automation system. One of ordinary skill in the art would have been motivated to do this modification since it can help form “part of a building automation system”, as VERBRUGH teaches in [0080].
Church-FRANCHITTI-VERBRUGH do not explicitly teach the endpoint is accessed via Hyper Text Transfer Protocol Secure (HTTPS) and/or Hyper Text Transfer Protocol (HTTP). Examiner takes Office Notice here it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to use http or https protocol to access the endpoint with unique IP address, since it is a one of common practices.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Church in view of FRANCHITTI, and in further view of Perreira (US 20190238399 A1, prior art of record, hereinafter as “Perreira”).
Regarding claim 6, Church-FRANCHITTI teach(es) all the limitations of its base claim from which the claim depends, but they don’t teach the container orchestration platform in configured to restart the one or more microservices upon failure.
However, Perreira teaches in an analogous art:
to restart the microservices upon failure ([Claim 8]: “wherein performing the action such that the cluster continues to execute the microservice comprises: restarting the member at which the soft failure was identified”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Church-FRANCHITTI based on the teaching of Perreira, to make the building automation system wherein the container orchestration computing platform in configured to restart the microservices upon failure. One of ordinary skill in the art would have been motivated to do this modification since it can help continue “execution of the microservices”, as Perreira teaches in [0013].
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Church in view of FRANCHITTI, and in further view of KYO (KR 2018-0120991 A, prior art of record, hereinafter as “KYO”).
Regarding claim 10, Church-FRANCHITTI teach all the limitations of its base claim from which the claim depends on, but they don’t teach the container orchestration computing platform is configured to monitor the microservices platform for faults.
However, KYO teaches in an analogous art:
the orchestration computing platform is configured to monitor the microservices computing platform for faults (FIG. 5 and [Page 28]: “The application management system 530 can perform application orchestration and provide application services by combining micro service modules. The application management system530 can perform substantially the same function as the service orchestration unit 270 of FIG. 2, and redundant description will be omitted. The application management system 530 may receive status information of the micro-services from the micro-service support/maintenance system 520. If the status information of the micro-service is in an inoperable state or an error occurrence state, the application management system 530 calls the alternative micro-service from the duplicated service”; And [Page 30]: “If it is determined that the operation is disabled or an error has occurred as a result of the monitoring, the microservice support/maintenance system 520 calls the replicated microservice to the cloud service provider 300 to stably support the service operation of the microservice application”. All these teach the orchestration computing platform monitors the microservices for error and takes actions accordingly).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Church-FRANCHITTI based on the teaching of KYO, to make the building automation system wherein the container orchestration computing platform is configured to monitor the microservices computing platform for faults. One of ordinary skill in the art would have been motivated to do this modification since it can help “stably support the service operation of the microservice”, as KYO teaches on [Page 30].
Claim 21 is rejected under 35 U.S.C. 103 as being unpatentable over Church in view of FRANCHITTI, and in further view of Goyal (US 20200159723 A1, hereinafter as “Goyal”).
Regarding claim 21, Church-FRANCHITTI teach all the limitations of its base claim from which the claim depends, but they don’t teach the microservices comprise a first microservice comprising to monitor building equipment and generate alarms and a second microservice configured to control building equipment.
However, Goyal teaches in an analogous art:
a first application comprising to monitor building equipment and generate alarms [0239]: “one application may generate an alarm if a monitored equipment setting exceeds a predefined amount”) and a second application configured to control building equipment ([0029]: “in some embodiments, the building logic application is at least one of a control application configured to control the piece of building equipment”).
Since Church teaches to use microservices to facilitate different applications, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Church-FRANCHITTI based on the teaching of Goyal, to make the building automation system wherein the microservices comprise a first microservice comprising to monitor building equipment and generate alarms and a second microservice configured to control building equipment. One of ordinary skill in the art would have been motivated to do this modification since it can help control and monitor the building equipment.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Church in view of FRANCHITTI and Perreira, and in further view of Rhodes (US 20200133795 A1, prior art of record, hereinafter as “Rhodes”).
Regarding claim 7, Church-FRANCHITTI-Perreira teach all the limitations of its base claim from which the claim depends, but they don’t teach the plurality of microservice containers comprise one or more components of storage used to store data for the one or more microservices.
However, Rhodes teaches in an analogous art:
the plurality of microservice containers comprise one or more components of storage used to store data for the microservices ([0016]: “… may provide for a persistent volume or other persistent storage to be attached to a container in which a microservice of the application runs. The persistent volume may store persistent data generated by, and/or otherwise associated with, the microservice”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Church-FRANCHITTI-Perreira based on the teaching of Rhodes, to make the building automation system wherein the plurality of microservice containers comprise one or more components of storage used to store data for the microservices. One of ordinary skill in the art would have been motivated to do this modification since it can help store the data associated with the microservice, as Rhodes teaches in [0016].
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Church in view of FRANCHITTI and Allmaras, and in further view of KI (KR 2017-0016666 A, prior art of record, hereinafter as “KI”).
Regarding claim 8, Church-FRANCHITTI-Allmaras teach all the limitations of its base claim from which the claim depends, but they don’t teach the common data model classifies data relating to the building automation system.
However, KI teaches in an analogous art:
the common data model classifies data (“the method of claim 5, Wherein the common data model includes a type definition class for classifying and converting the data according to a standard version”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Church- FRANCHITTI-Allmaras based on the teaching of KI, to make the building automation system wherein the common data model classifies data relating to the building automation system. One of ordinary skill in the art would have been motivated to do this modification since it can help convert the data before storing, as KI teaches in [Abstract].
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Church in view of FRANCHITTI and Allmaras, and in further view of VERBRUGH and Rangasamy (US 2017/0244787 A1, prior art of record, hereinafter as “Rangasamy”).
Regarding claim 20, Church-FRANCHITTI-Allmaras teach all the limitations of its base claim from which the claim depends, but they don’t teach the server is an on-premises BAS server and the server comprises an orchestration layer associated with a virtual private network (VPN).
However, VERBRUGH teaches in an analogous art:
the server is an on-premises BAS server ([0080]: “the database server 30 is local in the sense that it is part of the lighting system infrastructure itself (e.g. being located in the same building, and forming part of a building automation system”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Church-FRANCHITTI-Allmaras based on the teaching of VERBRUGH, to make the server wherein the server is an on-premises BAS server. One of ordinary skill in the art would have been motivated to do this modification since it can help form “part of a building automation system”, as VERBRUGH teaches in [0080].
Church-FRANCHITTI-Allmaras-VERBRUGH teaches all the limitations except the server comprises an orchestration layer associated with a virtual private network (VPN).
However, Rangasamy teaches in an analogous art that microservice containers communicate via a virtual private network (FIG. 2 and [0048]: “virtual circuit 127B may represent an extension of underlying virtual circuit elements (e.g., Virtual Local Area Networks (VLANs)129A, 129B or an Internet Protocol-Virtual Private Network (IP-VPN) shared in common), thereby enabling containers 126A-C executed by first CSP 122A to exchange data with containers 126D-F executed by second CSP 122B as well as with orchestration engine 106”).
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Church-FRANCHITTI-Allmaras-VERBRUGH based on the teaching of Rangasamy, to make the server wherein the server comprises an orchestration layer associated with a virtual private network (VPN). One of ordinary skill in the art would have been motivated to do this modification since it can help make the data private and secure, as the name of VPN suggests.
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any extension fee 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 date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHARLES CAI whose telephone number is (571)272-7192. The examiner can normally be reached on M-F 8-5 EST.
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, Kamini Shah can be reached on 571-272-2279. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/CHARLES CAI/
Primary Patent Examiner, Art Unit 2115
Prosecution Insights