DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
This office action is responsive to amendment filed on 05/12/2026.
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 05/12/2026 has been entered.
Response to Amendment
The Examiner has acknowledged the amended claims 1, 10, and 17.
Response to Arguments
Applicant's arguments filed on 05/12/2026 have been fully considered but they are not persuasive.
Regarding Applicant’s argument that Horton does not disclose extracting request data including one or more command paths specified within a request payload, where such command paths characterize operational attributes of a request, such as operations to be performed on particular resources, sub-resources, or paths implicated by payload content.
The Examiner respectfully disagrees with Applicant’s assertion because Horton discloses that The Examiner respectfully disagrees with Applicant’s assertion because Horton discloses that Upon receiving third-party data, the API 90 may translate the payload into a format interpretable by the device service 84. Upon receiving the translated payload, the device service 84 may retrieve the device type definition for the particular device 502. For example, when the device service 84 starts, it may load all available device type definitions from the services 191 (see paragraph [0313]).
Horton further discloses that the device type definitions may be provided not only to the device service 84, but also the applications 182 and/or 510, and/or the data warehouse 185, which may enable the payload to be interpreted by each of these entities. For example, accumulated third-party payload data that is stored in the data warehouse 185 may be interpreted using the device type definition, such that an energy report 514 may be provided to the user 512 (see paragraph 0314]).
Horton also discloses that the one or more scopes may provide one or more access rights to one or more of the data elements of the data model defined by a hierarchical position of the data elements in the data model represented by a respective path to the data elements. It should be noted that the sending of the request including the access token may be implemented as computer instructions stored one or more tangible non-transitory computer-readable medias and executed by the API client or the API client device. (see paragraphs [0213], [0215]).
Horton discloses that an authorization server 191, and the device service 84 and/or API 90. It should be noted that, in some embodiments, the device service 84 and/or the API 90 may receive the requests for resources from the client 318 and validate the access token provided by the client 318. It should also be noted that, in some embodiments, the authorization server 191 may provide functionality including querying client information and a list of scopes that the user granted to the client. As described in detail below, the scopes may group together one or more permissions for a specific functionality (e.g., viewing thermostat data, setting HVAC, etc.). The authorization server 191 may also authenticate the user 316 and fetch the user ID, validate the user's consent to grant the client's requested scopes, handle redirects, and receive requests for the authorization code and the access token. In some embodiments, the authorization server 191 may handle the requests via HTTP REST GET calls with query parameter format. (see paragraph [0191]).
Regarding Applicant’s argument that Horton does not disclose classes of rules, does not disclose classes containing command paths and associated actions, and does not disclose class-based authorization logic used to evaluate request-derived command paths.
The Examiner respectfully disagrees with Applicant’s argument because Horton discloses that the scopes that are assigned and granted to the client 318 or the client application 352 may be tied to the session (access token) for the life of the session. In some embodiments, the API 90 may validate that the access token is signed by a client secret issued by the authorization server 191. After validation, the API 90 may allow access to the resources in the data model according to the granted scopes associated with the access token using the device service 84. In some embodiments, rules may be set up that allow access to the resources if certain conditions are met. The table below shows one such rule. (see paragraph [0210]).
The Examiner wants to point out to the Applicants that the prior art still reads on the claimed invention because the claims are very broad.
It appears that Applicants have argued the limitations of the claims in a more specific way than what is actually claimed. The Applicants always have the opportunity to amend the claims during prosecution and broad interpretation by the examiner reduces the possibility that the claims, once issued, will be interpreted more broadly than is justified.
Claim Rejections - 35 USC § 102
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 (i.e., changing from AIA to pre-AIA ) 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 the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claims 1 - 20 are rejected under 35 U.S.C. 102(a)(1)/(a)(2) as being anticipated by Horton et al (US 2016/0261425; hereinafter Horton).
Regarding claim 1, Horton discloses a processor (paragraphs [0072], [0079]), comprising:
one or more logical units (paragraph [0120]) to:
receive, on behalf of a user, a request for access to at least one resource (paragraphs [0197 - 0198] Horton discloses that the client 318 requests the needed resource from the device service 84 using the API 90. The API 90 request may include the following parameter added: access token (the access token returned in the call to the authorization server 191). That is, in some embodiments, the API client or API client device may send one or more requests including the access token to retrieve, access, view, subscribe, or modify data elements of a data model representative of one or more smart environments);
extract, from one or more portions of the request including a request payload (paragraphs [0172], [0208], [0228], [0314]; Horton discloses that the device type definitions may be provided not only to the device service 84, but also the applications 182 and/or 510, and/or the data warehouse 185, which may enable the payload to be interpreted by each of these entities. For example, accumulated third-party payload data that is stored in the data warehouse 185 may be interpreted using the device type definition, such that an energy report 514 may be provided to the user 512), a set of request data including one or more command paths specified within the request payload (paragraphs [0309 - 0313], [0316]; Horton discloses that a vendor scope may correspond to an ability to read and write data under a vendor path in the data model. Multiple clients 184 may be associated with one vendor (e.g. third-party 502). The clients 184 may be associated with a vendor entity 702. Accordingly, exchanging an access token granted to a client 184 associated to a vendor entity 702 (e.g., either directly or via a developer) may return permissions corresponding to that vendor entity 702. The vendor entity 702 may include a vendor path attribute which may be unique across all vendor entities 702) and characterizing at least one operational attribute of the request (paragraphs [0313 - 0314], [0202]; Horton discloses that the authorization server 191 responds to the client application 352 with an access token (event 9 378). The client application 352 can now make resource requests from the data model via the device service 84 providing the access token as a request parameter to the API 90 and/or the device service 84 (event 10 380). The device service 84 and/or the API 90 may analyze the access token and return the requested resources from the data model based on the permissions granted to the client application 352 (event 11 382).);
compare the set of request data against an authorization tree, the authorization tree specifying one or more classes of rules associated with the user (paragraphs [0197], [0200], [0202], [0207]; Horton discloses that the device service 84 and/or the API 90 may analyze the access token and return the requested resources from the data model based on the permissions granted to the client application 352 (event 11 382)), each class including at least one command path and an associated action (paragraphs [0213], [0215]; Horton discloses the one or more scopes may provide one or more access rights to one or more of the data elements of the data model defined by a hierarchical position of the data elements in the data model represented by a respective path to the data elements. It should be noted that the sending of the request including the access token may be implemented as computer instructions stored one or more tangible non-transitory computer-readable medias and executed by the API client or the API client device.); and
determine whether to grant, on behalf of the user, access to the resource based at least in part on the action specified in the authorization tree and corresponding to the set of request data (paragraphs [0194 - 0195], [0197], [0210]; Horton discloses that the authorization server 191 may create an authorization entry in the authorization tree for the user and the client that is granted permission in the assigned scopes. In some embodiments, once the permission is granted, data synchronization between the API 90 and the data service 84 may begin).
Regarding claim 2, Horton discloses the processor of claim 1, wherein the authorization tree includes a hierarchy of nodes at different levels, the levels including a set of classes of rules at a first level aggregated to a set of roles at a second level, the set of roles aggregated to a set of users at a third level higher than the first and second levels (paragraphs [0171], [0213], [0274]; Horton discloses that each data element location can store strings, numbers, Boolean values and/or parent/child objects or arrays. Using the API 90, a user's client can sync data from locations at multiple levels in the hierarchy).
Regarding claim 3, Horton discloses the processor of claim 1, wherein the action is associated with a path of the request, and wherein individual rules are associated with respective paths and permissions (paragraph [0193]; Horton discloses that Event 1 322 of the sequence diagram 320 includes the user 316 sending a request to the client 318 webpage/app that incorporates data from the data model. In response, event 2 324 shows a page being returned to the user with a webpage containing a link to the authorization page).
Regarding claim 4, Horton discloses the processor of claim 1, wherein the request is a restful API request (paragraphs [0171], [0205]; Horton discloses that these data locations may be accessed by creating a client 182 application, using the client libraries 198 and/or using streaming and/or traditional REST communications.).
Regarding claim 5, Horton discloses the processor of claim 1, wherein the set of request data is further extracted from at least one of a header, an endpoint, an address, or a protocol method of the request (paragraphs [0197], [0181], [0209]; Horton discloses that the one or more scopes may provide one or more access rights to one or more of the data elements of the data model defined by a hierarchical position of the data elements in the data model represented by a respective path to the data elements).
Regarding claim 6, Horton discloses the processor of claim 1, wherein multiple rules of the authorization tree are determined to apply to the request and are to be used to determine the action (paragraphs [0210 – 0213]; Horton discloses that An authorization tree may contain an object for each user who has granted any client 318 or client application 352 access. Within the user object there may be sub-objects for every client that has been granted access. Each client object contains information on rights granted to that client. The below table includes an example of an authorization tree).
Regarding claim 7, Horton discloses the processor of claim 1, wherein the one or more logical units are further to generate a request tree and a response tree, and determine whether to grant access further based upon comparing the request tree and the response tree against the authorization tree (paragraphs [0184 – 0186], [0194], [0211], ; Horton discloses that the authorization server 191 may create an authorization entry in the authorization tree for the user and the client that is granted permission in the assigned scopes. In some embodiments, once the permission is granted, data synchronization between the API 90 and the data service 84 may begin).
Regarding claim 8, Horton discloses the processor of claim 1, wherein child nodes of the authorization tree automatically inherit permissions of a parent node unless otherwise specified (paragraph [0211]; Horton discloses that an authorization tree may contain an object for each user who has granted any client 318 or client application 352 access. Within the user object there may be sub-objects for every client that has been granted access. Each client object contains information on rights granted to that client. The below table includes an example of an authorization tree).
Regarding claim 9, Horton discloses the processor of claim 1, wherein the one or more logical units are further to attempt to authenticate and authorize the request before extracting the set of request data (paragraphs [0018], [0172 – 0173], [0234]; Horton discloses that a custom login feature may be used to enable the device service 84 provider to utilize customized authentication payloads to authorize access to the APIs 90 and/or device services 84.).
Regarding 10, Horton discloses a system, comprising:
one or more processors (paragraphs [0072], [0079]) to:
extract, from at least a header and a payload of a request received on behalf of a user (paragraphs [0172], [0208], [0228]; Horton discloses that a custom login feature may be used to enable the device service 84 provider to utilize customized authentication payloads to authorize access to the APIs 90 and/or device services 84), a set of request data specifying an endpoint corresponding to an action to be performed (paragraphs [0183], [0232], [0240]; Horton discloses that the disclosed techniques provide functionality to enable the client to insert their own data into the data model using the device service 84 (e.g., via the API 90), retrieve their own data from data model using the device service 84 (e.g., via the API 90));
determine, using the set of request data, an actual endpoint corresponding to the action is to be performed (paragraphs [0204 – 0205]);
determine, from an authorization tree associated with the user, a permission and an action corresponding to the actual endpoint (paragraphs [0210 – 0213]; Horton discloses that an authorization tree may contain an object for each user who has granted any client 318 or client application 352 access. Within the user object there may be sub-objects for every client that has been granted access. Each client object contains information on rights granted to that client. The below table includes an example of an authorization tree); and
determine whether to grant access to the request based in part on the permission
and the action corresponding to the actual endpoint (paragraphs [0194 - 0195], [0197], [0210]; Horton discloses that the authorization server 191 may create an authorization entry in the authorization tree for the user and the client that is granted permission in the assigned scopes. In some embodiments, once the permission is granted, data synchronization between the API 90 and the data service 84 may begin).
Regarding 11, Horton discloses the system of claim 10, wherein the one or more processors are further to:
generate a request tree using the set of request data (paragraphs [0184 – 0186], [0194], [0211]; Horton discloses that the authorization server 191 may create an authorization entry in the authorization tree for the user and the client that is granted permission in the assigned scopes. In some embodiments, once the permission is granted, data synchronization between the API 90 and the data service 84 may begin); and
compare nodes of the request tree against corresponding nodes of the authorization tree to determine the permission and the action corresponding to the actual endpoint (paragraphs [0194 - 0195], [0197], [0202], [0205], [0207]; Horton discloses that the device service 84 and/or the API 90 may analyze the access token and return the requested resources from the data model based on the permissions granted to the client application 352 (event 11 382)).
Regarding 12, Horton discloses the system of claim 10, wherein the one or more processors are further to:
generate a response tree using the set of request data (paragraphs [0184 – 0186], [0194], [0211]); and
compare nodes of the response tree against corresponding nodes of the authorization tree to determine which data to include in a response generated for the request (paragraphs [0194 - 0195], [0197], [0202], [0207]).
Regarding 13, Horton discloses the system of claim 10, wherein the authorization tree includes a hierarchy of nodes at different levels, the levels including a set of rules at a first level aggregated to a set of classes at a second level, the set of classes aggregated to a set of roles at a third level higher than the first and second levels (paragraphs [0171], [0213], [0274]; Horton discloses that each data element location can store strings, numbers, Boolean values and/or parent/child objects or arrays. Using the API 90, a user's client can sync data from locations at multiple levels in the hierarchy).
Regarding 14, Horton discloses the system of claim 10, wherein the action is associated with one or more rules of a class, and wherein individual rules are associated with respective paths and permissions (paragraph [0193]; Horton discloses that Event 1 322 of the sequence diagram 320 includes the user 316 sending a request to the client 318 webpage/app that incorporates data from the data model. In response, event 2 324 shows a page being returned to the user with a webpage containing a link to the authorization page).
Regarding 15, Horton discloses the system of claim 10, wherein the one or more processors are to extract the set of request data further from at least one of a header, an endpoint, an address, or a protocol method of the request (paragraphs [0197], [0181], [0209]; Horton discloses that the one or more scopes may provide one or more access rights to one or more of the data elements of the data model defined by a hierarchical position of the data elements in the data model represented by a respective path to the data elements).
Regarding 16, Horton discloses the system of claim 10, wherein the system is at least one of:
a system for performing simulation operations (paragraph [0441]; Horton discloses that it may be desirable to simulate occupancy of the smart environment);
a system for performing simulation operations to test or validate autonomous machine applications;
a system for performing digital twin operations;
a system for performing light transport simulation;
a system for rendering graphical output;
a system for performing deep learning operations;
a system for performing generative AI operations using a large language model (LLM);
a system implemented using an edge device;
a system for generating or presenting virtual reality (VR) content;
a system for generating or presenting augmented reality (AR) content;
a system for generating or presenting mixed reality (MR) content; a system incorporating one or more Virtual Machines (VMs);
a system implemented at least partially in a data center;
a system for performing hardware testing using simulation;
a system for performing generative operations using a language model (LM);
a system for synthetic data generation;
a collaborative content creation platform for 3D assets; or a system implemented at least partially using cloud computing resources.
Claims 17 – 20 incorporate substantively all the limitations of claims 10 – 16 in computer-implemented method form rather than system form. The reasons for rejecting claims 10 – 16 apply in claims 17 – 20. Therefore, claims 17 – 20 are rejected for the same reasons.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Thable et al (US 2025/0382133) discloses a system and method for multi-rack storage.
Douglas et al (US 2019/0028360) discloses VISUAL DEVOPS SYSTEMS AND METHODS.
Contact Information
Any inquiry concerning this communication or earlier communications from the examiner should be directed to YVES DALENCOURT whose telephone number is (571)272-3998. The examiner can normally be reached M-F 8AM-5:30PM.
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, Ario Etienne can be reached at 571-272-4001. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/YVES DALENCOURT/Primary Examiner, Art Unit 2457
Prosecution Insights