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 .
DETAILED ACTION
This Office Action is in response to the application filed on 03/11/2025. This is CONT of application 17/304,209. Claims 1, 15, and 19 are independent claims. Claims 1-29 have been examined and are pending. This Action is made non-FINAL.
Drawings
The drawings were received on 03/11/2025. These drawings are reviewed and accepted by the Examiner.
Priority
Acknowledgment is made of applicant’s claim for foreign priority under 35 U.S.C. 119 (a)-(d). The certified copy has been filed in parent Application No. 202011026338, filed on Jun. 22, 2020.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked. As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term "means" or "step" or a term used as a substitute for "means" that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term "means" or "step" or the generic placeholder is modified by functional language, typically, but not always linked by the transition word "for" (e.g., "means for") or another linking word or phrase, such as "configured to" or "so that"; and
(C) the term "means" or "step" or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word "means" (or "step") in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Absence of the word "means" (or "step") in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function. Claim limitations in this application that use the word "means" (or "step") are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word "means" (or "step") are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word "means," but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: control devices configured to control ..; gateway is configured to: “queue/send/attempts/download” recited in claims 1, 4, and 9.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Objections
Claims 1, 11, 15, and 18 are objected to because of the following informalities:
Regarding claim 1; claim 1 recites the limitations:
“the gateway exposes;” “the mobile app stores;” “the gateway determining …;” and “the requested APIs download …;”
To properly recite embodiments and corresponding functions of a system claim, it's suggested that the aforementioned limitations be further amended to:
“the gateway is configured to expose …;” “the mobile app is configured to store” “the gateway is configured to determine …; “the requested APIs is configured to download …” respectively (emphasis added).
Regarding claim 11; claim 11 recites the acronym “IO” without spelling out in full at its first occurrence. It’s suggested that said acronym be spelled out in full as its first occurrence. Appropriate correction(s) is required.
Regarding claim 15; claim 15 recites the limitations:
“a gateway exposing a plurality for application program interfaces (APIs) …;
a user using the mobile app of a mobile device;
the mobile app making access requests …;
the gateway determining whether to provide the mobile app…;”
To properly recite active steps of a method claim, it's suggested that the aforementioned limitations be further amended to:
“exposing, by a gateway, a plurality for application program interfaces (APIs)…;
using, by user, the mobile app of a mobile device;
making, by the mobile app, access requests…;
determining, by the gateway, whether to provide the mobile app…; (emphasis added).
Regarding claim 18; claim 18 recites the limitations:
“the mobile app logging into a web a web server …, the gateway providing a session ID …; the gateway sending synchronous responses …”;
To properly recite active steps of a method claim, it's suggested that the aforementioned limitations be further amended to:
“logging, by the mobile app, into a web a web server …, providing, by gateway, a session ID …; sending, by the gateway, synchronous responses …;” (emphasis added).
Appropriate corrections are required.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3 are rejected under 35 U.S.C. 103 as being unpatentable over Barnum et al. (“Barnum,” US 2020/0241375), in view of L’Heureux et al (“L’Heureux,” US 2014/0254546), and Spector (“Spector,” US 2013/0061138), further in view of Lusk et al. (“Lusk,” US 2020/0167364)
Regarding claim 1, Barnum teaches a system for downloading configurations to control devices of a building management system, comprising:
(a) a gateway (Barnum: par. [0022],"The electrochromic window system 100 includes ... a gateway 106 ..." Paragraph [0023], "The gateway 106 is operatively coupled to a cloud computing system 110." The cloud computing system provides a dashboard, mobile app support, APIs, and management services; par. [0024], “The gateway 106 communicates directly with the cloud computing system 110" and "communicates with the cloud computing system on behalf of the set of drivers 104 and the distributed EMS 102." );
(b) one or more control devices operatively coupled to the gateway, the one or more control devices configured to control building management system equipment (Barnum: par. [0022], "The electrochromic window system 100 includes ... a first set of drivers 104, and a gateway 106.... Each of the set of drivers 104 is coupled to an individual one of a set of electrochromic (EC) windows 130.... The set of drivers 104 are coupled to the set of EC windows 130 via power cables and control wires."; par. 0020, "The cloud computing system can provide ... configuration information ... for each of the drivers to the gateway and the gateway can provide the respective configuration information to the corresponding driver."; par. 0020, "The configuration information can be used by the driver to control driver operations...." and "The cloud computing system can define the configuration information to specify how the respective driver should drive the electrochromic device...."; par. 0023, “control logic, glare control, and configuration for electronic window system 100, “automation algorithm”; par. 0025, The tint selector 120 can be mounted or otherwise disposed in a building having the EC windows 130”; par. 0025, occupancy sensor 122; building sensor 124 (“roof mounted irradiance sensor”);
(c) a mobile app running on a mobile device (Barnum: fig. 1, Dashboard Mobile App 142; par. 0023, "The cloud computing system 110 can provide a system dashboard to ... a dashboard mobile app 142 on a personal computing device.... The dashboard mobile app 142 can be used to monitor or control the electrochromic window system 100."; par. 0023, "The dashboard web app 140 and the dashboard mobile app 142 communicate with the cloud computing system....”);
Barnum does not explicitly disclose “(d) the gateway exposes a plurality of application programming interfaces (APIs) of the gateway to the mobile app, wherein the plurality of APIs are categorized on a basis of a type of data that can be downloaded by the mobile app to a respective control device.”
However, in an analogous art, L’Heureux discloses
(d) the gateway exposes a plurality of application programming interfaces (APIs) of the gateway to the mobile app, wherein the plurality of APIs are categorized on a basis of a type of data that can be downloaded by the mobile app to a respective control device (L'Heureux: par. [0069], "an application program or OS component on each client device communicates with an API on the gateway router, such as a file storage API, session handoff API, store session state API, user login API, device authentication API, etc."; par. [0047 , "APIs on the gateway router" that the applications "access".. In the combination, the gateway that exposes these APIs is Barnum's gateway 106 (Barnum: pars. [0022], [0023], [0024]), and the mobile app to which they are exposed is Barnum's dashboard mobile app 142 (Barnum par. [0023]; FIG. 1).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of L’Heureux with the method and system of Barnum to include “(d) the gateway exposes a plurality of application programming interfaces (APIs) of the gateway to the mobile app, wherein the plurality of APIs are categorized on a basis of a type of data that can be downloaded by the mobile app to a respective control device.” One would have been motivated to do so because it provides an organized means for a client application to store, exchange, and access data resources through the gateway (L'Heureux, Abstract).
The combination of Barnum and L’Heureux teaches a configuration of a control device is configured via the mobile app, the mobile app stores the configuration in a local database (Barnum: discloses a configuration for a control device. "The cloud computing system can provide... configuration information... for each of the drivers to the gateway and the gateway can provide the respective configuration information to the corresponding driver" (Barnum: par. [0020]), and the configuration "can be used by the driver to control driver operations" (Barnum: par. [0020]). Barnum further discloses "a configuration file 322 stored at the first driver 308 " (Barnum [0048]). Barnum's dashboard mobile app 142 is used to "monitor or control the electrochromic window system 100" (Barnum: par. [0023]; L'Heureux: discloses the client device storing data locally through the application. The client device includes a "storage device 144" (L'Heureux: [0023]; FIG. 1) at which data resources are stored. L'Heureux discloses that a user, operating the application on the client device, may "upload a new file “from client device 600”" and may "browse the contents of a storage device to select a file located at client device 600" (L'Heureux :” par. [0064]). Data resources "in the form of account information, files, applications, session state information, etc." are stored (L'Heureux: par. [0021]));
The combination of Barnum and L’Heureux does not explicitly disclose as a configuration of a control device is being configured (storing overlaps editing).
However, in an analogous art, Spector discloses Spector discloses storing in-process content in a local database while the content is being edited (Spector: par. 0082, “Spector discloses storing in-process content in a local database while the content is being edited. Spector states that "at any time during the creation or editing process, the user can tap the save button 710 to save the... in a database in memory 230 of the computing device". Spector further discloses that "an autosave option is available whereby the user would configure the method... to automatically save the in-process... at regular intervals or prior to certain editing functions" (Spector: par. [0082])).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Spector with the method and system of Barnum and L’Heureux to include as a configuration of a control device is being configured (storing overlaps editing). One would have been motivated to do so because autosaving the in-process content to the local database as it is edited reduces the risk and impact of data loss (Spector: par. [0082]).
The combination of Barnum, L’Heureux, and Spector further teaches
(f) the mobile app is configured to make access requests to the gateway for access to respective APIs of the gateway depending on the type of data in the configuration (L'Heureux: par. 0047, “the applications may access APIs on the gateway router", and par. [0069], "an application program or OS component on each client device communicates with an API on the gateway router"). The GUIs by which the user operates the application "may be accessed... through one or more of the previously described APIs" (par. [0070]; Barnum: par. 0020; L'Heureux: par. 0069, L’Heureux discloses a plurality of APIs each directed to a distinct type of data).
Barnum, L’Heureux, and Spector do not explicitly disclose (g) in response to the access requests, the gateway determines whether to provide the mobile app access to the requested APIs;
However, in an analogous art, Lusk discloses (g) in response to the access requests, the gateway determines whether to provide the mobile app access to the requested APIs (Lusk discloses that the determination is triggered by, and performed on, a received request to invoke an API. Lusk states the process "begins at block 1702 with an API gateway service receiving a request to invoke an API" (Lusk: par. [0105]), after which the gateway “acquires credentials from the caller for the purpose of authorizing the request" (Lusk par. [0105], block 1704) and authenticates the caller (block 1706), before determining authorization at block 1708; par. 0105, "At block 1708, the API gateway examines a set of access controls that limit access to the API, and determines whether the credentials provided by the caller are sufficient to authorize the request. If the provided credentials are sufficient to authorize the request, execution proceeds to block 1710. If the provided credentials are not sufficient to authorize the request, the process stops and an error is returned to the caller."; Abstract: "Access to the application programming interface may be controlled via fine-grained access controls; par. 0024);
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lusk with the method and system of Barnum, L’Heureux, and Spector to include (g) in response to the access requests, the gateway determines whether to provide the mobile app access to the requested APIs. One would have been motivated to do so because it adds fine-grained, per-API access controls to backend services that would otherwise have only coarse, broad-access security (Lusk: par. [0024]; Abstract).
The combination of Barnum, L’Heureux, Spector, and Lusk further teaches
(h) when the gateway provides the mobile app access to the requested APIs, the requested APIs download the respective types of data in the configuration from the mobile app to the respective control device (Lusk discloses that, upon a sufficient-authorization determination, execution proceeds to fulfill the request. "If the provided credentials are sufficient to authorize the request, execution proceeds to block 1710" (Lusk: par. [0105]), after which "the API gateway invokes the API, and the API generates a backend service request" (Lusk: par. [0107]) and the request is fulfilled (par. [0109]–[0110]); L'Heureux discloses that the application transfers data from the client device through the gateway router's API. The user "upload[s] a new file from client device 600 to the gateway router" (L'Heureux: par. [0064]), and the APIs on the gateway router "handle one or more of the previously described operations... such as storing a file" (L’Heureux: par. [0069]); Barnum discloses the gateway delivering the configuration onward to the control device. "The cloud computing system can provide... configuration information... for each of the drivers to the gateway and the gateway can provide the respective configuration information to the corresponding driver" (Barnum: par. [0020]), resulting in "a configuration file 322 stored at the first driver 308" (Barnum: par. [0048]); L'Heureux's gateway router exposes a plurality of APIs each directed to a distinct type of data (L'Heureux: par. [0069])).
Regarding claim 2, the combination of Barnum, L’Heureux, Spector, and Lusk teaches the system of claim 1, The combination of Barnum, L’Heureux, Spector, and Lusk further teaches, wherein the type of data that the plurality of APIs are categorized include one or more of:
device data (L'Heureux: par. [0069], “ ..Other APIs may also be provided, such as device data sync API..”);
point data;
alarm data;
application configuration data; and
schedule data.
Regarding claim 3, the combination of Barnum, L’Heureux, Spector, and Lusk teaches the system of claim 1. The combination of Barnum, L’Heureux, Spector, and Lusk further teaches, wherein the mobile app is configured to automatically make the access requests to the gateway without user input (L’Heureux: par. 0057, Synchronization may be performed by the gateway router …. or automatically responsive to identification of a data resource stored on one client device of the client identity not present on another client device of the client identity.”),
Claim 4 is rejected under 35 U.S.C. 103 as being unpatentable over Barnum et al. (“Barnum,” US 2020/0241375), in view of L’Heureux et al (“L’Heureux,” US 2014/0254546), and Spector (“Spector,” US 2013/0061138), and Lusk et al. (“Lusk,” US 2020/0167364), and Christiansen et al. (“Christiansen,” US 2019/0354075), and further in view of McCaig et al (“McCaig,” US 2018/0262533).
Regarding claim 4, the combination of Barnum, L’Heureux, Spector, and Lusk teaches the system of claim 1. The combination of Barnum, L’Heureux, Spector, and Lusk do not teach, wherein the gateway is configured to: (a) queue incoming access requests for the APIs from the mobile app; (b) send a status code to the mobile app after reviewing a validity of the data associated with a respective access request ; and (c) accepts the respective access request for access to the respective API if the data associated with the respective access request is determined by the gateway to be valid .
However, in an analogous art, Christiansen teaches a system that queues incoming requests in the order received (Christiansen discloses that its system is "configured to receive requests from users" and "establishes a queue of requests from the users," and "may organize the queue of requests based on... order in which the requests were received" (Christiansen: par. [0120])).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Christiansen with the method and system of Barnum, L’Heureux, Spector, and Lusk to include (a) queue incoming access requests for the APIs from the mobile app. One would have been motivated to do so because establishing a queue of requests organized by order received provides orderly processing of multiple incoming requests (Christiansen: par. [0120]).
Christiansen does not explicitly disclose
(b) send a status code to the mobile app after reviewing a validity of the data associated with a respective access request ; and
(c) accepts the respective access request for access to the respective API if the data associated with the respective access request is determined by the gateway to be valid .
However, in an analogous art, McCaig teaches
(b) send a status code to the mobile app after reviewing a validity of the data associated with a respective access request (McCaig: par. [0107], "if there is a validation failure of the client input parameters on a POST, PUT on any resource, the server may return a JSON body" with "status: 400" and an error code identifying the "field" where "validation failed" (McCaig : par. [0107]). McCaig further discloses that the response includes "HTTP status codes that reflects the success/failure state of this query" (par. [0104]), and that "a predefined error code may be established for validation failure of input fields" (par. [0104])); and
(c) accepts the respective access request for access to the respective API if the data associated with the respective access request is determined by the gateway to be valid (McCaig discloses that a "POST success response" is returned, including a "status (e.g., one of a plurality of predefined HTTP status codes that reflects the success/failure state of this query)" (McCaig: par. [0104]); the success response format returns "status," "message," and the requested "data" (par. [0105]). A failure status (e.g., 400) is returned only "if there is a validation failure of the client input parameters" (par. [0107]))
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of McCaig with the method and system of Barnum, L’Heureux, Spector, Lusk, and Christiansen to include send a status code to the mobile app after reviewing a validity of the data associated with a respective access request; and accepts the respective access request for access to the respective API if the data associated with the respective access request is determined by the gateway to be valid. One would have been motivated to do so because validating client input and reporting the success or failure state allows malformed requests to be rejected and valid requests to be confirmed (McCaig: pars. [0104], [0107]).
Claim 5 is rejected under 35 U.S.C. 103 as being unpatentable over Barnum et al. (“Barnum,” US 2020/0241375), in view of L’Heureux et al (“L’Heureux,” US 2014/0254546), and Spector (“Spector,” US 2013/0061138), and (“Lusk,” US 2020/0167364), further in view of Sundar et al. (“Sundar,” US 2021/0120417)
Regarding claim 5, the combination of Barnum, L’Heureux, Spector, Lusk teaches the system of claim 1, The combination of Barnum, L’Heureux, Spector, Lusk further teaches wherein
(a) the mobile app is configured to log into a web server of the gateway with a client certificate (Lusk discloses that the API gateway provides a web interface — the API gateway service provides "a web-based representational state transfer ('REST') interface" (Lusk: par. [0022]), and "the API gateway service 102 provides a web interface that provides access to management functions" accessed via "a web browser" (par. [0031]). Lusk further discloses that a caller logs into the API gateway using a client certificate — the credentials "provided to the API gateway" for authenticating the caller "may take the form of a username and password, cryptographic key, security token, digital signature, or digital certificate" (par. [0105]));
Barnum, L’Heureux, Spector, Lusk do not explicitly discloses
(b)in response, the gateway is configured to provide a session ID to the mobile app.
However, in an analogous art, Sundar discloses in response, the gateway is configured to provide a session ID to the mobile app (Sundar: par. 0008. "the authentication framework a session identifier and device identifier after validating the login credentials"; see also par. [0016]). Sundar further discloses that "after validation, the authentication framework... may further generate a session identifier [ (e.g., SM_SESSION)... for the user]" (par. [0056]))
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Sundar with the method and system of Barnum, L’Heureux, Spector, and Lusk to include (b)in response, the gateway is configured to provide a session ID to the mobile app. One would have been motivated to do so because generating a session identifier as part of login process helps secure communication between the application and the platform (Sundar: Abstract, par. 0001).
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Barnum et al. (“Barnum,” US 2020/0241375), in view of L’Heureux et al (“L’Heureux,” US 2014/0254546), and Spector (“Spector,” US 2013/0061138), and (“Lusk,” US 2020/0167364), Sundar et al. (“Sundar,” US 2021/0120417), further in view of McCaig et al (“McCaig,” US 2018/0262533).
Regarding claim 6, the combination of Barnum, L’Heureux, Spector, Lusk, and Sandar teaches the system of claim 5. Barnum, L’Heureux, Spector, Lusk, and Sandar do not explicitly disclose, wherein:
(a) upon successful login to the web server of the gateway, and subscription to a websocket of the gateway, the gateway is configured to send synchronous responses to the mobile app in response to each of the access requests ; and
(b) the responses from the gateway are sent over the websocket to the mobile app.
However, in an analogous art, McCaig discloses
(a) upon successful login to the web server of the gateway, and subscription to a websocket of the gateway, the gateway is configured to send synchronous responses to the mobile app in response to each of the access requests (McCaig teaches a client subscribing to a websocket of a gateway and receiving responses over that websocket. McCaig discloses "a web socket interface for consuming applications to subscribe to messages for a specific gateway," where messages "for the gateway... that a client application has subscribed to... are sent to the consuming application, e.g., as JSON over a web socket" (McCaig: par. [0164]). McCaig further discloses that "a web socket interface may be provided for clients to connect to the server and to request events... routed to any interested client web socket connections" (par. [0168]). McCaig further teaches that a response is returned for each request: for a request on a resource, "a success or failure response may be returned," the response including a "status" reflecting "the success/failure state of this query" (McCaig: par. [0104])); and
(b) the responses from the gateway are sent over the websocket to the mobile app (McCaig teaches that the responses are sent to the subscribed client over the websocket. McCaig discloses that messages for the subscribed gateway "are... sent to the consuming application, e.g., as JSON over a web socket" (McCaig: par. [0164]), and that events are "routed to any interested client web socket connections" (par. [0168])).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of McCaig with the method and system of Barnum, L’Heureux, Spector, Lusk, and Sandar to include (a) upon successful login to the web server of the gateway, and subscription to a websocket of the gateway, the gateway is configured to send synchronous responses to the mobile app in response to each of the access requests ; and (b) the responses from the gateway are sent over the websocket to the mobile app. One would have been motivated to do so because a websocket interface delivers responses to the subscribed client with minimal delay (McCaig: pars. [0164], [0167]).
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Barnum et al. (“Barnum,” US 2020/0241375), in view of L’Heureux et al (“L’Heureux,” US 2014/0254546), and Spector (“Spector,” US 2013/0061138), and Lusk (“Lusk,” US 2020/0167364), and further in view of Subramanya et al. (“Subramanya,” US 2017/0045882).
Regarding claim 7, the combination of Barnum, L’Heureux, Spector, Lusk teaches the system of claim 1. The combination of Barnum, L’Heureux, Spector, Lusk further teaches (a)if any access request by the mobile app fails (Lusk discloses that, upon an insufficient-authorization determination, "the process stops and an error is returned to the caller" (Lusk: par. [0105]), and that results returned to the client may indicate "that an operation was successful or unsuccessful" (Lusk: par. [0088]) but does not explicitly disclose the mobile app is configured to repeat the same access request one or more times.
However, in an analogous art, Subramanya discloses repeating a request when it fails (Subrammanya discloses that when a device "experiences a communications error such as timeout encountered when requests are sent to it," the system performs "repeated retries as it tries to establish communications" (Subrammanya: par. [0006]). Subrammanya further discloses "Retries in case of communication failures" that occur after "initial configured retries" (par. [0034])).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Subramanya with the method and system of Barnum, L’Heureux, Spector, Lusk, and Sinha to include the mobile app is configured to repeat the same access request one or more times. One would have been motivated to do so because retrying a request upon a communication failure allows communications to be established and the request completed when an initial attempt fails (Subrammanya: pars. [0006], [0034]).
Claims 8, 9 and 10 are rejected under 35 U.S.C. 103 as being unpatentable over Barnum et al. (“Barnum,” US 2020/0241375), in view of L’Heureux et al (“L’Heureux,” US 2014/0254546), and Spector (“Spector,” US 2013/0061138), and Lusk et al. (“Lusk,” US 2020/0167364), and further in view of Moser (“Moser,” US 2014/0344325)
Regarding claim 8, the combination of Barnum, L’Heureux, Spector, and Lusk teaches the system of claim 1. The combination of Barnum, L’Heureux, Spector, and Lusk teaches, wherein downloading a configuration from the mobile app to a control device via one or more of the APIs but does not explicitly disclose “is performed in an automated and asynchronous way without user input.”
However, in an analogous art, Moser discloses Moser teaches performing a client-to-server data transfer automatically and asynchronously (Moser discloses that the update "can occur automatically upon determining that the cached resource is invalid" (par. [0005]); that the transfer is "an asynchronous download of the content resource to the client machine" (Abstract) and "an asynchronous call from the client machine to the backend server" (par. [0004]); and that the resource is "downloaded asynchronously and displayed immediately" (par. [0037])).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Moser with the method and system of Barnum, L’Heureux, Spector, and Lusk to include “is performed in an automated and asynchronous way without user input.” One would have been motivated to do so because doing it improves application performance and the user experience by transferring data in the background without blocking the user (Moser, Abstract; par. [0002]).
Regarding claim 9, the combination of Barnum, L’Heureux, Spector, and Lusk teaches the system of claim 1. The combination of Barnum, L’Heureux, Spector, and Lusk further teaches the following portions:
the gateway downloading a configuration to multiple control devices (Barnum discloses that "the cloud computing system can provide the configuration information (in a configuration file) for each of the drivers to the gateway and the gateway can provide the respective configuration information to the corresponding driver" (Barnum: par. [0020]). Barnum further discloses "a first set of drivers 104," where "each of the set of drivers 104 is coupled to an individual one of a set of electrochromic (EC) windows 130" (par. [0022])),
downloading a configuration from the mobile app (L'Heureux discloses the transfer of data from the mobile app through the gateway's API: the application "upload[s] a new file from client device 600 to the gateway router" (L'Heureux: par. [0064]), and the gateway router's APIs handle "storing a file" (par. [0069]). The configuration so downloaded is Barnum's configuration (Barnum: pars. [0020], [0048]).
automatically / without intervening user input (L'Heureux discloses that the transfer is performed "automatically responsive to identification of a data resource stored on one client device of the client identity not present on another client device" (L'Heureux: par. [0056])).
The combination teaches a gateway configured to download a configuration from the mobile app to multiple control devices but does not explicitly disclose the download to multiple control devices is performed "automatically and asynchronously... without intervening user input."
However, in an analogous art, Moser teaches performing a client-to-server data transfer automatically and asynchronously (Moser discloses that the transfer "can occur automatically upon determining that the cached resource is invalid relative to the current state of the data" (Moser: par. [0005]). Moser further discloses "an asynchronous download of the content resource to the client machine" (Abstract), "an asynchronous call from the client machine to the backend server" (par. [0004]), and that the resource is "downloaded asynchronously and displayed immediately" (par. [0037])).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Moser with the method and system of Barnum, L’Heureux, Spector, and Lusk to include to “download to multiple control devices is performed "automatically and asynchronously... without intervening user input." One would have been motivated to do so because doing it improves application performance and the user experience by transferring data in the background without blocking the user (Moser, Abstract; par. [0002]).
Regarding claim 10, the combination of Barnum, L’Heureux, Spector, and Lusk teaches the system of claim 1. The combination of the combination of Barnum, L’Heureux, Spector, and Lusk teaches wherein the requested APIs can download the respective types of data in the configuration from the mobile app to the respective control device but does not explicitly disclose “while a user continues to configure one or more control devices.”
However, in an analogous art, Moser teaches performing a client-to-server data transfer concurrently with the user's continued activity at the client (Moser discloses "an asynchronous call from the client machine to the backend server that occurs while the content resource... is displayed by the client machine as part of the application page" (Moser: par. 0004]). Moser further teaches that the resource is "downloaded asynchronously and displayed immediately" (par. [0037]), the transfer proceeding without interrupting the user's use of the page)).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Moser with the method and system of Barnum, L’Heureux, Spector, and Lusk to include to include “while a user continues to configure one or more control devices.” One would have been motivated to do so because doing it improves application performance and the user experience by transferring data in the background without blocking the user (Moser, Abstract; par. [0002]).
Claims 11-14 are rejected under 35 U.S.C. 103 as being unpatentable over Barnum et al. (“Barnum,” US 2020/0241375), in view of L’Heureux et al (“L’Heureux,” US 2014/0254546), and Spector (“Spector,” US 2013/0061138), and Lusk et al. (“Lusk,” US 2020/0167364), and further in view of Sinha et al. (“Sinha,” US 2017/0284691)
Regarding claim 11, the combination of Barnum, L’Heureux, Spector, and Lusk teaches the system of claim 1. Barnum, L’Heureux, Spector, and Lusk do not explicitly disclose, wherein the one or more control devices comprises one or more of a thermostat device and a smart IO controller.
However, in an analogous art, Sinha discloses wherein the one or more control devices comprises one or more of a thermostat device and a smart IO controller (Sinha teaches a control device that is a smart IO controller. Sinha discloses smart connected equipment that "have their own processing and analytics capabilities" (Sinha : par. 0047]), and describes "a smart actuator that has built in position feedback, computing power, and a communication network [that] can... perform local decision making" (par. [0047]). Sinha further discloses that "a series of smart actuators and dampers that work together can provide... autonomous manipulation of a building and/or BMS" (par. [0047]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Sinha with the method and system of Barnum, L’Heureux, Spector, and Lusk to include wherein the one or more control devices comprises one or more of a thermostat device and a smart IO controller. One would have been motivated to apply the combination's gateway-based configuration download to such HVAC equipment in order to configure and control the standard building equipment that a building management system manages (Sinha: pars. [0002], [0046])
Regarding claim 12, the combination of Barnum, L’Heureux, Spector, and Lusk teaches the system of claim 1. Barnum, L’Heureux, Spector, and Lusk do not explicitly disclose, wherein the building management system equipment comprises one or more of a Roof Top Unit (RTU), a Variable Flow Refrigerant (VRF) Unit, an Air Handling Unit (AHU), a boiler, a chiller, and lighting.
However, in an analogous art, Sinha discloses wherein the building management system equipment comprises one or more of a Roof Top Unit (RTU), a Variable Flow Refrigerant (VRF) Unit, an Air Handling Unit (AHU), a boiler, a chiller, and lighting (Sinha discloses "smart connected HVAC equipment 408 [that] may include an actuator 410, a damper 412, a chiller 414, a heater 416, a rooftop unit (RTU) 418, an air handling unit (AHU) 420" (par. [0046]), all installed within a building (par. [0046]) and managed as part of a building management system (par. [0002]: "A building management system (BMS) is... a system of devices configured to control, monitor, and manage equipment in or around a building")).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Sinha with the method and system of Barnum, L’Heureux, Spector, and Lusk to include wherein the building management system equipment comprises one or more of a Roof Top Unit (RTU), a Variable Flow Refrigerant (VRF) Unit, an Air Handling Unit (AHU), a boiler, a chiller, and lighting. One would have been motivated to apply the combination's gateway-based configuration download to such HVAC equipment in order to configure and control the standard building equipment that a building management system manages (Sinha: pars. [0002], [0046])
Regarding claim 13, the combination of Barnum, L’Heureux, Spector, and Lusk teaches the system of claim. The combination of Barnum, L’Heureux, Spector, and Lusk further teaches comprising a cloud, wherein a gateway is configured to send telemetry data from the one or more control devices to the cloud (Barnum: par. [0023]). Barnum further discloses that "the distributed EMS can communicate data to the cloud computing system via a radio using a gateway operatively coupled to the cloud computing system" (par. 0020]), and that the cloud computing system provides "extensive system health monitoring, proactive troubleshooting" (par. [0023])) but does not explicitly disclose "the gateway is registered with the cloud."
However, in an analogous art, Sinha discloses a cloud "the gateway is registered with the cloud." (Sinha: teaches registering a device with a distributed building management system in the cloud. Sinha discloses "a method for registering an HVAC device in a distributed building management system (BMS)" (Sinha: Abstract; par. [0022]), in which the device is registered "into a document database of the registration service" and a device shadow is stored "within a data platform of the distributed BMS" (pars. [0022]–[0023]). Sinha's distributed BMS is cloud-based (Sinha: par. [0003]: an "Internet of Things (IoT) based BMS"))
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Sinha with the method and system of Barnum, L’Heureux, Spector, and Lusk to include the gateway is registered with the cloud. One would have been motivated to provide the newly added device should be registered and verified to ensure that proper security precautions are taken due to the device’s connection to the Internet (Sinha: par. 0003).
Regarding claim 14, the combination of Barnum, L’Heureux, Spector, Lusk, and Sinha teaches the system of claim 13. The combination of Barnum, L’Heureux, Spector, Lusk, and Sinha further teaches wherein the cloud comprises a synch service to keep the configuration of the one or more control devices available for access by the mobile app and a supervisor (Barnum discloses that "the cloud computing system 110 can provide a system dashboard to a dashboard web app 140 on a desktop computer, a dashboard mobile app 142 on a personal computing device, or both" (Barnum: par. [0023]), and that both "can be used to monitor or control the electrochromic window system 100" (par. [0023]). The cloud provides "configuration for the electrochromic window system 100" (par. [0023]) Sinha discloses "generating a device shadow associated with the HVAC device" and "storing the device shadow in a memory of the distributed BMS" (Sinha: Abstract; pars. [0022]–[0023])).
Claims 15-16 are rejected under 35 U.S.C. 103 as being unpatentable over Barnum et al. (“Barnum,” US 2020/0241375), in view of L’Heureux et al (“L’Heureux,” US 2014/0254546), further in view of Lusk et al. (“Lusk,” US 2020/0167364).
Regarding claim 15, Barnum teaches a method for downloading configurations to control devices of a building management system (Barnum: pars. 0022, 0023, 0024, Gateway; pars, 0020, 0023-24, control devices, building management system; fig. 1, par. 0023, mobile app running a mobile device), the method comprising:
Barnum does not explicitly disclose (a) a gateway exposing a plurality of application programming interfaces (APIs) of the gateway to a mobile app, wherein the plurality of APIs are categorized on a basis of a type of data that can be downloaded by the mobile app to a respective control device
However, in an analogous art, L’Heureux discloses
(a) a gateway exposing a plurality of application programming interfaces (APIs) of the gateway to a mobile app, wherein the plurality of APIs are categorized on a basis of a type of data that can be downloaded by the mobile app to a respective control device (L'Heureux: par. [0069], "an application program or OS component on each client device communicates with an API on the gateway router, such as a file storage API, session handoff API, store session state API, user login API, device authentication API, etc."; par. [0047 , "APIs on the gateway router" that the applications "access".. In the combination, the gateway that exposes these APIs is Barnum's gateway 106 (Barnum: pars. [0022], [0023], [0024]), and the mobile app to which they are exposed is Barnum's dashboard mobile app 142 (Barnum par. [0023]; FIG. 1));
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of L’Heureux with the method and system of Barnum to include “(a) a gateway exposing a plurality of application programming interfaces (APIs) of the gateway to a mobile app, wherein the plurality of APIs are categorized on a basis of a type of data that can be downloaded by the mobile app” One would have been motivated to do so because it provides an organized means for a client application to store, exchange, and access data resources through the gateway (L'Heureux, Abstract).
The combination of Barnum and L’Heureux teaches
(b)a user using the mobile app of a mobile device to configure a configuration for a control device, the mobile app storing the configuration in a local database (Barnum: discloses a configuration for a control device. "The cloud computing system can provide... configuration information... for each of the drivers to the gateway and the gateway can provide the respective configuration information to the corresponding driver" (Barnum: par. [0020]), and the configuration "can be used by the driver to control driver operations" (Barnum: par. [0020]). Barnum further discloses "a configuration file 322 stored at the first driver 308 " (Barnum [0048]). Barnum's dashboard mobile app 142 is used to "monitor or control the electrochromic window system 100" : Barnum: par. [0023]; L'Heureux: discloses the client device storing data locally through the application. The client device includes a "storage device 144" (L'Heureux: [0023]; FIG. 1) at which data resources are stored. L'Heureux discloses that a user, operating the application on the client device, may "upload a new file “from client device 600”" and may "browse the contents of a storage device to select a file located at client device 600" (L'Heureux :” par. [0064]). Data resources "in the form of account information, files, applications, session state information, etc." are stored (L'Heureux: par. [0021]). In the combination, the data resource stored locally by the app is Barnum's configuration);
(c) the mobile app making access requests to the gateway for access to respective APIs of the gateway depending on the type of data in the configuration (L'Heureux: par. 0047, “the applications may access APIs on the gateway router", and par. [0069], "an application program or OS component on each client device communicates with an API on the gateway router"). The GUIs by which the user operates the application "may be accessed... through one or more of the previously described APIs" (par. [0070]); Barnum: par. 0020; L'Heureux: par. 0069, L’Heureux discloses a plurality of APIs each directed to a distinct type of data);
Barnum and L’Heureux, do not explicitly disclose (d) in response to the access requests, the gateway determining whether to provide the mobile app access to the requested APIs;
However, in an analogous art, Lusk discloses (d) in response to the access requests, the gateway determining whether to provide the mobile app access to the requested APIs (Lusk discloses that the determination is triggered by, and performed on, a received request to invoke an API. Lusk states the process "begins at block 1702 with an API gateway service receiving a request to invoke an API" (Lusk: par. [0105]), after which the gateway “acquires credentials from the caller for the purpose of authorizing the request" (Lusk par. [0105], block 1704) and authenticates the caller (block 1706), before determining authorization at block 1708; par. 0105, "At block 1708, the API gateway examines a set of access controls that limit access to the API, and determines whether the credentials provided by the caller are sufficient to authorize the request. If the provided credentials are sufficient to authorize the request, execution proceeds to block 1710. If the provided credentials are not sufficient to authorize the request, the process stops and an error is returned to the caller."; Abstract: "Access to the application programming interface may be controlled via fine-grained access controls; par. 0024.).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lusk with the method and system of Barnum, L’Heureux, and Spector to include (c) in response to the access requests, the gateway determining whether to provide the mobile app access to the requested APIs. One would have been motivated to do so because it adds fine-grained, per-API access controls to backend services that would otherwise have only coarse, broad-access security (Lusk: par. [0024]; Abstract).
The combination of Barnum, L’Heureux, Spector, and Lusk further teaches
(e) when the gateway provides the mobile app access to the requested APIs, the requested APIs downloading the respective types of data in the configuration from the mobile app to the respective control device (Lusk discloses that, upon a sufficient-authorization determination, execution proceeds to fulfill the request. "If the provided credentials are sufficient to authorize the request, execution proceeds to block 1710" (Lusk: par. [0105]), after which "the API gateway invokes the API, and the API generates a backend service request" (Lusk: par. [0107]) and the request is fulfilled (pars. [0109]–[0110]); L'Heureux discloses that the application transfers data from the client device through the gateway router's API. The user "upload[s] a new file from client device 600 to the gateway router" (L'Heureux: par. [0064]), and the APIs on the gateway router "handle one or more of the previously described operations... such as storing a file" (L’Heureux: par. [0069]); Barnum discloses the gateway delivering the configuration onward to the control device. "The cloud computing system can provide... configuration information... for each of the drivers to the gateway and the gateway can provide the respective configuration information to the corresponding driver" (Barnum: par. [0020]), resulting in "a configuration file 322 stored at the first driver 308" (Barnum: par. [0048]); L'Heureux's gateway router exposes a plurality of APIs each directed to a distinct type of data (L'Heureux: par. [0069]).).
Regarding claim 16, the combination of Barnum, L’Heureux, and Lusk teaches the method of claim 15. The combination of Barnum, L’Heureux, and Lusk further teaches wherein the type of data that the plurality of APIs are categorized include one or more of:
device data (L'Heureux: par. [0069], “ ..Other APIs may also be provided, such as device data sync API..”);
point data;
alarm data;
application configuration data; and
schedule data.
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Barnum et al. (“Barnum,” US 2020/0241375), in view of L’Heureux et al (“L’Heureux,” US 2014/0254546), and Lusk et al. (“Lusk,” US 2020/0167364), and Christiansen et al. (“Christiansen,” US 2019/0354075), and further in view of McCaig et al (“McCaig,” US 2018/0262533).
Regarding claim 17, the combination of Barnum, L’Heureux, and Lusk teaches the system of claim 15. The combination of Barnum, L’Heureux, and Lusk do not teach, wherein the gateway is configured to: queue incoming access requests for the APIs from the mobile app; send a status code to the mobile app after reviewing a validity of the data associated with a respective access request; and accepts the respective access request for access to the respective API if the data associated with the respective access request is determined by the gateway to be valid .
However, in an analogous art, Christiansen teaches a system that queues incoming requests in the order received (Christiansen discloses that its system is "configured to receive requests from users" and "establishes a queue of requests from the users," and "may organize the queue of requests based on... order in which the requests were received" (Christiansen: par. [0120]).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Christiansen with the method and system of Barnum, L’Heureux, and Lusk to include (a) queue incoming access requests for the APIs from the mobile app. One would have been motivated to do so because establishing a queue of requests organized by order received provides orderly processing of multiple incoming requests (Christiansen: par. [0120]).
Christiansen does not explicitly disclose
(b) send a status code to the mobile app after reviewing a validity of the data associated with a respective access request ; and
(c) accepts the respective access request for access to the respective API if the data associated with the respective access request is determined by the gateway to be valid .
However, in an analogous art, McCaig teaches
(b) send a status code to the mobile app after reviewing a validity of the data associated with a respective access request (McCaig: par. [0107], "if there is a validation failure of the client input parameters on a POST, PUT on any resource, the server may return a JSON body" with "status: 400" and an error code identifying the "field" where "validation failed" (McCaig: par. [0107]). McCaig further discloses that the response includes "HTTP status codes that reflects the success/failure state of this query" (par. [0104]), and that "a predefined error code may be established for validation failure of input fields" (par. [0104])); and
(c) accepts the respective access request for access to the respective API if the data associated with the respective access request is determined by the gateway to be valid (McCaig discloses that a "POST success response" is returned, including a "status (e.g., one of a plurality of predefined HTTP status codes that reflects the success/failure state of this query)" (McCaig: par. [0104]); the success response format returns "status," "message," and the requested "data" (par. [0105]). A failure status (e.g., 400) is returned only "if there is a validation failure of the client input parameters" (par. [0107]))
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of McCaig with the method and system of Barnum, L’Heureux, Lusk, and Christiansen to include send a status code to the mobile app after reviewing a validity of the data associated with a respective access request; and accepts the respective access request for access to the respective API if the data associated with the respective access request is determined by the gateway to be valid. One would have been motivated to do so because validating client input and reporting the success or failure state allows malformed requests to be rejected and valid requests to be confirmed (McCaig: pars. [0104], [0107]).
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Barnum et al. (“Barnum,” US 2020/0241375), in view of L’Heureux et al (“L’Heureux,” US 2014/0254546), and (“Lusk,” US 2020/0167364), Sundar et al. (“Sundar,” US 2021/0120417), further in view of McCaig et al (“McCaig,” US 2018/0262533).
Regarding claim 18, the combination of Barnum, L’Heureux, and Lusk teaches the method of claim 15. The combination of Barnum, L’Heureux, and Lusk further teaches, wherein:
(a) the mobile app logging into a web server of the gateway with a client certificate (Lusk discloses that the API gateway provides a web interface — the API gateway service provides "a web-based representational state transfer ('REST') interface" (Lusk: par. [0022]), and "the API gateway service 102 provides a web interface that provides access to management functions" accessed via "a web browser" (par. [0031]). Lusk further discloses that a caller logs into the API gateway using a client certificate — the credentials "provided to the API gateway" for authenticating the caller "may take the form of a username and password, cryptographic key, security token, digital signature, or digital certificate" (par. [0105]).);
Barnum, L’Heureux, and Lusk do not explicitly disclose
(b)in response, the gateway is configured to provide a session ID to the mobile app.
However, in an analogous art, Sundar discloses in response, the gateway is configured to provide a session ID to the mobile app (Sundar: par. 0008. "the authentication framework a session identifier and device identifier after validating the login credentials"; see also par. [0016]). Sundar further discloses that "after validation, the authentication framework... may further generate a session identifier [ (e.g., SM_SESSION)... for the user]" (par. [0056]).)
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Sundar with the method and system of Barnum, L’Heureux, and Lusk to include (b)in response, the gateway is configured to provide a session ID to the mobile app. One would have been motivated to do so because generating a session identifier as part of login process helps secure communication between the application and the platform (Sundar: Abstract, par. 0001).
Barnum, L’Heureux, Lusk, and Sundar do not explicitly disclose, wherein:
(c) upon successful login to the web server of the gateway, and subscription to a websocket of the gateway, the gateway is configured to send synchronous responses to the mobile app in response to each of the access requests ; and
(d) the responses from the gateway are sent over the websocket to the mobile app.
However, in an analogous art, McCaig discloses
(c) upon successful login to the web server of the gateway, and subscription to a websocket of the gateway, the gateway is configured to send synchronous responses to the mobile app in response to each of the access requests (McCaig teaches a client subscribing to a websocket of a gateway and receiving responses over that websocket. McCaig discloses "a web socket interface for consuming applications to subscribe to messages for a specific gateway," where messages "for the gateway... that a client application has subscribed to... are sent to the consuming application, e.g., as JSON over a web socket" (McCaig: par. [0164]). McCaig further discloses that "a web socket interface may be provided for clients to connect to the server and to request events... routed to any interested client web socket connections" (par. [0168]). McCaig further teaches that a response is returned for each request: for a request on a resource, "a success or failure response may be returned," the response including a "status" reflecting "the success/failure state of this query" (McCaig: par. [0104])); and
(d) the responses from the gateway are sent over the websocket to the mobile app (McCaig teaches that the responses are sent to the subscribed client over the websocket. McCaig discloses that messages for the subscribed gateway "are... sent to the consuming application, e.g., as JSON over a web socket" (McCaig: par. [0164]), and that events are "routed to any interested client web socket connections" (par. [0168])).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of McCaig with the method and system of Barnum, L’Heureux, Spector, Lusk, and Sundar to include (c) upon successful login to the web server of the gateway, and subscription to a websocket of the gateway, the gateway is configured to send synchronous responses to the mobile app in response to each of the access requests ; and (d) the responses from the gateway are sent over the websocket to the mobile app. One would have been motivated to do so because a websocket interface delivers responses to the subscribed client with minimal delay (McCaig: pars. [0164], [0167]).
Claims 19-20 are rejected under 35 U.S.C. 103 as being unpatentable over Barnum et al. (“Barnum,” US 2020/0241375), in view of L’Heureux et al (“L’Heureux,” US 2014/0254546), and further in view of Lusk et al. (“Lusk,” US 2020/0167364)
Regarding claim 19, Barnum teaches a non-transitory computer readable medium storing instructions that when executed by one or more processors of a gateway (Barnum: pars. 0022, 0023, 0024, Gateway; pars, 0020, 0023-24, control devices, building management system; fig. 1, par. 0023, mobile app running a mobile device):
Barnum does not explicitly disclose “(a) exposes plurality of application programming interfaces (APIs) of the gateway to a mobile app of a mobile device, wherein the plurality of APIs are categorized on a basis of a type of data that can be downloaded by the mobile app to a respective control device;”
However, in an analogous art, L’Heureux discloses
(a) the gateway exposes a plurality of application programming interfaces (APIs) of the gateway to the mobile app, wherein the plurality of APIs are categorized on a basis of a type of data that can be downloaded by the mobile app to a respective control device (L'Heureux: par. [0069], "an application program or OS component on each client device communicates with an API on the gateway router, such as a file storage API, session handoff API, store session state API, user login API, device authentication API, etc."; par. [0047 , "APIs on the gateway router" that the applications "access".. In the combination, the gateway that exposes these APIs is Barnum's gateway 106 (Barnum: pars. [0022], [0023], [0024]), and the mobile app to which they are exposed is Barnum's dashboard mobile app 142 (Barnum par. [0023]; FIG. 1).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of L’Heureux with the method and system of Barnum to include “(a) the gateway exposes a plurality of application programming interfaces (APIs) of the gateway to the mobile app, wherein the plurality of APIs are categorized on a basis of a type of data that can be downloaded by the mobile app to a respective control device.” One would have been motivated to do so because it provides an organized means for a client application to store, exchange, and access data resources through the gateway (L'Heureux, Abstract).
The combination of Barnum and L’Heureux further teaches
(b) receive access requests from the mobile app for access to respective APIs of the gateway depending on the type of data in a configuration that is configured and stored by the mobile app (L'Heureux: par. 0047, “the applications may access APIs on the gateway router", and par. [0069], "an application program or OS component on each client device communicates with an API on the gateway router"). The GUIs by which the user operates the application "may be accessed... through one or more of the previously described APIs" (par. [0070].. Barnum: par. 0020; L'Heureux: par. 0069, L'Heureux discloses a plurality of APIs each directed to a distinct type of data).
Barnum and L’Heureux, do not explicitly disclose (c) in response to the access requests, determine whether to provide the mobile app access to the requested APIs.
However, in an analogous art, Lusk discloses
(c) in response to the access requests, determine whether to provide the mobile app access to the requested APIs (Lusk discloses that the determination is triggered by, and performed on, a received request to invoke an API. Lusk states the process "begins at block 1702 with an API gateway service receiving a request to invoke an API" (Lusk: par. [0105]), after which the gateway “acquires credentials from the caller for the purpose of authorizing the request" (Lusk par. [0105], block 1704) and authenticates the caller (block 1706), before determining authorization at block 1708.; par. 0105, "At block 1708, the API gateway examines a set of access controls that limit access to the API, and determines whether the credentials provided by the caller are sufficient to authorize the request. If the provided credentials are sufficient to authorize the request, execution proceeds to block 1710. If the provided credentials are not sufficient to authorize the request, the process stops and an error is returned to the caller."; Abstract: "Access to the application programming interface may be controlled via fine-grained access controls; par. 0024).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the teachings of Lusk with the method and system of Barnum, L’Heureux, and Spector to include (c) in response to the access requests, determine whether to provide the mobile app access to the requested APIs. One would have been motivated to do so because it adds fine-grained, per-API access controls to backend services that would otherwise have only coarse, broad-access security (Lusk: par. [0024]; Abstract).
The combination of Barnum, L’Heureux, and Lusk further teaches
(d) when access to the requested APIs is granted, the requested APIs of the gateway downloading the respective types of data in the configuration received from the mobile app to a respective control device (Lusk discloses that, upon a sufficient-authorization determination, execution proceeds to fulfill the request. "If the provided credentials are sufficient to authorize the request, execution proceeds to block 1710" (Lusk: par. [0105]), after which "the API gateway invokes the API, and the API generates a backend service request" (Lusk: par. [0107]) and the request is fulfilled (pars. [0109]–[0110]); L'Heureux discloses that the application transfers data from the client device through the gateway router's API. The user "upload[s] a new file from client device 600 to the gateway router" (L'Heureux: par. [0064]), and the APIs on the gateway router "handle one or more of the previously described operations... such as storing a file" (L’Heureux: par.[0069]); Barnum discloses the gateway delivering the configuration onward to the control device. "The cloud computing system can provide... configuration information... for each of the drivers to the gateway and the gateway can provide the respective configuration information to the corresponding driver" (Barnum: par. [0020]), resulting in "a configuration file 322 stored at the first driver 308" (Barnum: par. [0048]); L'Heureux's gateway router exposes a plurality of APIs each directed to a distinct type of data (L'Heureux: par. [0069])).
Regarding claim 20, the combination of Barnum, L’Heureux, and Lusk teaches the non-transitory computer readable medium of claim 19. The combination of Barnum, L’Heureux, and Lusk further teaches wherein the type of data that the plurality of APIs are categorized include one or more of:
device data (L'Heureux: par. [0069], “ ..Other APIs may also be provided, such as device data sync API..”);
point data;
alarm data;
application configuration data; and
schedule data.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CANH LE whose telephone number is (571)270-1380. The examiner can normally be reached on Monday to Friday 6:00AM to 3:30PM other Friday off.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Luu Pham, can be reached at telephone number 571-270-5002. 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 Patent Center and the Private Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from Patent Center or Private PAIR. Status information for unpublished applications is available through Patent Center and Private PAIR for authorized users only. Should you have questions about access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free).
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) Form at https://www.uspto.gov/patents/uspto-automated- interview-request-air-form.
/Canh Le/
Examiner, Art Unit 2439
July, 19, 2026
/LUU T PHAM/Supervisory Patent Examiner, Art Unit 2439
Prosecution Insights