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 01/12/2026.
Response to Amendment
The Examiner has acknowledged the amended claims 1, 10, and 17.
Response to Arguments
Applicant's arguments filed on 01/12/2026 have been fully considered but they are not persuasive.
Regarding Applicant’s argument that Horton fails to anticipate at least in part the features of “extracting from one or more portions of the request including a request payload, a set of request data characterizing at least one operational attribute of the request” and “comparing the set of request data against an authorization tree, the authorization tree specifying one or more classes of rules associated with the user”.
The Examiner respectfully disagrees with Applicant’s assertion because 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). (see paragraph [0202]).
Horton further discloses that the client 182 may connect to the API 90. In one embodiment, the API 90 may include one or more hosts 192 that may receive and/or process the data 184 and/or the requests 186 and/or 190 in near real-time and/or real-time. The hosts 192 may include a Firebase host and/or one or more Representation State Transfer (REST) hosts 196 (e.g. periodic REST and/or rest streaming transactions)(see paragraph [0169]).
Horton also discloses that when an interaction with the system 180 occurs, a data request is received by the device service 84 (block 252). In one embodiment, the data request may include a request to retrieve particular smart device information and/or a request to set particular smart device information. The request may be provided, in some embodiments, via the API 90, based upon communications from a client 182.(see paragraph [0176]).
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).
Horton discloses that the response may include all data values in an all objects so the client 318 or the client application 352 may filter the fields of interest and map the access tokens to the corresponding users (e.g., by identifying the access tokens provided in a metadata section of the response and mapping them to the users). Additionally or alternatively, there may be more than one response and each response may be particular for a single access token that was sent in the list of access tokens with the request. The metadata section including the access token provides a mechanism to identify which access token with which the data and/or user is associated.(see paragraph [0207]).
Thus, the Examiner contends that the prior art read on the claimed invention.
It appears that applicants are interpreting the claims very narrow without considering the broad teaching of the references used in the rejection. Applicants are reminded that the examiner is entitled to the broadest reasonable interpretation of the claims. The Applicants always have the opportunity to amend the claims during prosecution and broad interpretation by the examiner reduces the possibility that the claim, once issued, will be interpreted more broadly than is justified. In re Prater 162 USPQ 541,550-51 (CCPA 1969).
In view of such, the rejections are as follows:
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.
Claim 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 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)); and
determine whether to grant, on behalf of the user, access to the resource based at least in part on an 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, Karp 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, Karp 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, Karp 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, Karp 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, Karp 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, Karp 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, Karp 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, Karp 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; 14 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
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
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