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 .
Claims 1-25 are pending in this application.
Response to Arguments
The examiner notes that the clarifying language to further distinguish the invention that applicant’s representative and the examiner briefly discussed in the interview on 10/06/2025 seem to be recited in the newly added claims 23-25. Applicant's arguments filed 10/17/2025 have been fully considered but they are not persuasive as the independent claims were not amended.
Applicant’s argue on pages 7-8 that Bruchner fails to teach or suggest “receiving an API permission based on the user and the identified target file server from the permissions repository; and allowing or declining the API call by the user in accordance with the API permission.” The examiner respectfully disagrees.
The examiner notes that Bruchner shows in fig. 4, [0037]-[0039], in response to the user permitting aggregation system to access a particular media server or service, the media content application sends a request to the API server to determine if the user has an account with the media server or service. Upon the Permission API returning the request that the user has an account with the media server or service (GET/(user-id)/permissions), the media content application queries the user to input authentication information through a pop-up window. As the return result from the Permission API, the pop-up window in the UI on the client device allows the user to input the authentication information. Therefore, it is clear that Bruchner discloses receiving an API permission based on the user and the identified target file server from the permissions repository since Bruchner presents the user with the pop-up window for authentication information in response to the Permission API sending the determination that the user has an account with the media server.
Applicant’s also argue on page 8 that Bruchner does not teach allowing or declining the API call by the user in accordance with the API permission. The examiner respectfully disagrees.
As stated above, the API permission pop-up window for query for authentication information is presented in response to receiving the request response from the Permission API. Bruchner discloses in Fig. 4, that it prepares the permission request in a pop-up query where the user inputs authentication information (Permission #2) based from the previous request response from the Permission API. The API server then determines if the user provides the correct authentication information. Once determined and the API server successfully authenticates the user, it returns an authentication token for the user to access the information. Therefore, it is clear that Bruchner discloses allowing or declining the API call by the user in accordance with the API permission.
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-8, and 10-22 are rejected under 35 U.S.C. 103 as being Unpatentable over Parthasarathy (US 2019/0334768) and in view of Bruchner (US 2015/0334101).
Re claim 1, Parthasarathy discloses a method comprising:
receiving, at a gateway of a management system configured to manage multiple file servers, an API including an identified target file server ([0043], [0045] configuration agent receives user-specified information from interactions. Mapper module parameters include the source data structures and target data structures. Mapper module receives selected source configuration parameters through an access API);
preparing a request for an API permissions repository based on the identified target file server and a user (fig. 4, [0054]-[0056], mapper module utilizes the source data structure that stores user ID, set of permissions and other user attributes to configure mapping with the target data structures);
Parthasarathy does not disclose, however, Bruchner discloses API call ([0039], API call to the API server);
receiving an API permission based on the user and the identified target file server from the permissions repository ([0037]-[0039], media content application sends a request to the API server to determine if the user has an account with the media server/service. The request maybe an API call to the API server with providing correct user authentication information. Upon the Permission API returning the request that the user has an account with the media server or service (GET/(user-id)/permissions), the media content application queries the user to input authentication information through a pop-up window. API permission is received since the information is received and a pop-up window is presented as shown in Fig. 4); and
allowing or declining the API call by the user in accordance with the API permission ([0039], if the user provides correct authentication information and the API server successfully authenticates the user, the user successfully logs into the media server).
It would have been obvious for one of ordinary skill in the art before the date the current invention was effectively filed to have modified the teachings of Parthasarathy’s API configuration permissions with Bruchner’s API permissions in order to utilize a request via API call to the API server. One of ordinary skill in the art would have been motivated to incorporate the teachings with one another in order to create a more efficient system by utilizing API call protocols.
Re claim 2, one of ordinary level of skill in the art would have been compelled to make the proposed modification to Parthasarathy for the same reasons identified in the rejection of claim 1. In addition, Bruchner discloses wherein said allowing or declining the API call comprises allowing the API call, and wherein the API call is for an action at the target file server ([0039], if the user provides correct authentication information and the API server successfully authenticates the user, the user successfully logs into the media server. The request maybe an API call to the API server with providing correct user authentication information).
Re claim 3, one of ordinary level of skill in the art would have been compelled to make the proposed modification to Parthasarathy for the same reasons identified in the rejection of claim 1. In addition, Bruchner discloses routing the API call to the target file server based on an identification of the target file server ([0021], [0039]-[0040], request is an API call to the API server for content on the media server. Content items provided by the media server includes content location information (URL).
Re claim 4, one of ordinary level of skill in the art would have been compelled to make the proposed modification to Parthasarathy for the same reasons identified in the rejection of claim 1. In addition, Bruchner discloses wherein the identification comprises a URI or URL received with the API call ([0021], [0039]-[0040], request is an API call to the API server for content on the media server. Content items provided by the media server includes content location information (URL).
Re claim 5, Parthasarathy discloses storing associations between respective identifications of each of the multiple file servers and operation types expected at each of the multiple file servers (fig. 3, multiple clusters in the source and target computing environments. [0055], discloses the data structures with object model schema includes a role type description).
Re claim 6, Parthasarathy discloses providing a user interface for updating permissions in the API permissions repository ([0037]-[0038], data structures invoke updates to the user role data record for access to certain resources).
Re claim 7, Parthasarathy discloses receiving, through the user interface, a request to provide a first permission to a particular user ([0038], user roles/permissions stored in the configuration information is used to restrict access to certain resources); and
prompting, through the user interface, for authorization to provide a second permission to the particular user, wherein the first permission utilizes the second permission ([0036]-[0038], [0043] first data structure and the second data structure comprises multiple related data structures where mapping parameters associate certain fields of the first data structure with certain fields of the second data structure. A user interface to receive user-specified information).
Re claim 8, Parthasarathy discloses wherein the second permission comprises a network permission ([0037]-[0038], updating user roles can give user access to certain resources in the target computing system in which allows them access to that part of the network).
Re claims 10-22, they are similar to claims 1-8 and therefore are rejected for the same reasons above.
Claim 9 is rejected under 35 U.S.C. 103 as being Unpatentable over Parthasarathy and in view of Bruchner and in view of Qureshi (US 2014/0007222).
Re claim 9, Parthasarathy and Bruchner does not disclose, however, Qureshi discloses wherein the API permission comprises a role-based permission, and wherein the API permissions repository includes an association between the user and a role ([0393], authentication involves a login process to grant access based on user ID, user role, or other group memberships) .
It would have been obvious for one of ordinary skill in the art before the date the current invention was effectively filed to have modified the teachings of Parthasarathy and Bruchner’s API configuration permissions with Qureshi’s API permissions in order to give access depending on the user’s role. One of ordinary skill in the art would have been motivated to incorporate the teachings with one another in order to create a more versatile system by granting access based on user ID, user role, or other group memberships.
Claims 23-25 are rejected under 35 U.S.C. 103 as being Unpatentable over Parthasarathy and in view of Bruchner and in view of Poliashenko (US 2018/0288025).
Re claims 23-25, Parthasarathy and Bruchner does not disclose, however, Poliashenko discloses wherein the API permission comprises a permission regarding execution of the API call ([0081]-[0082], determining whether the API call is enabled. Once the API is enabled, it then determine if the API call is authorized by evaluating whether access is authorized to the particular API to which the API call requests access. The message from the source device may include a source device credential, and evaluating whether the API call is authorized which in turn determines if the source device is authorized to make the API call).
It would have been obvious for one of ordinary skill in the art before the date the current invention was effectively filed to have modified the teachings of Parthasarathy and Bruchner’s API permissions with Poliashenko’s API that are enabled and determine if the source device is authorized to make the API call. One of ordinary skill in the art would have been motivated to incorporate the teachings with one another in order to provide a more secure system by ensure the API is enabled to be accessed, and also determine if the source device is authorized to make the API call.
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.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to HO T SHIU whose telephone number is (571)270-3810. The examiner can normally be reached Mon-Fri (9:00am - 5:00pm).
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, Nicholas Taylor can be reached at 571-272-3089. 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.
/HO T SHIU/Examiner, Art Unit 2443
HO T. SHIU
Examiner
Art Unit 2443
/NICHOLAS R TAYLOR/Supervisory Patent Examiner, Art Unit 2443