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 action is responsive to Applicant’s Amendment filed on 6/25/2026.
Claims 1, 5-9, 13-17 and 21-26 are presented for examination. Claims 1, 9 and 17 have been amended. Claims 21-26 have been added. Claims 2-4, 10-12 and 18-20 have been cancelled.
Examiner Notes
Examiner cites particular columns, paragraphs, figures and line numbers in the references as applied to the claims below for the convenience of the applicant. Although the specified citations are representative of the teachings in the art and are applied to the specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested that, in preparing responses, the applicant fully consider the references in entirely as potentially teaching all or part of the claimed invention, as well as the context of the passage as taught by the prior art or disclosed by the examiner.
Information Disclosure Statement
The information disclosure statement (IDS) submitted on 6/3/2026. The submissions are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement is being considered by the examiner.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102 of this title, 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, 5-9, 13-17 are rejected under 35 U.S.C. 103 as being unpatentable over Evans (US 20150237165 A1) in view of Munoz (US 20170060349 A1, hereafter Munoz).
Regarding to claim 1, Evans discloses: A method for managing access to data (see [0007]-[0008]; “the formal REST interaction constraints applied to resources (components, connectors, and data elements)” and “the computer implemented method includes the steps of identifying individual resources requiring operations to be performed”), the method comprising:
obtaining, by a service device, a new resource creation request for a Representational State Transfer (REST) application programming interface (API) hosted by the service device (see Fig. 1, [0007]-[0008], [0024], [0031] and [0033]; “allow the creation of new resources through a POST request”, “a transmission may be a request to create resources on the server” and “In the event that the URI does not yet have a corresponding resource, then the server creates the resource with that URI”);
identifying, by the service device and based on the new resource creation request, at least one data source uniform resource identifier of the REST API (see [0033]; “A POST operation is used to transmit a representation of a new data entity to the server, so that it will be stored as a new subordinate of the resource identified by the URI … In the event that the URI does not yet have a corresponding resource, then the server creates the resource with that URI”);
establishing, by the service device, a new custom resource for the REST API, the new custom resource having a [new] data source uniform resource identifier (see Fig. 1, [0007]-[0008], [0024], [0031] and [0033]; “allow the creation of new resources through a POST request”, “a transmission may be a request to create resources on the server” and “In the event that the URI does not yet have a corresponding resource, then the server creates the resource with that URI” and “In the event that the URI does not yet have a corresponding resource, then the server creates the resource with that URI”);
obtaining, by the service device and from a client device, an invocation of the REST API, the [new] data source uniform resource identifier be provided as part of the invocation (see [0024]; “allow the creation of new resources through a POST request. When a new resource has been POSTed, the response includes the URI of the new resource. The client may then use that URI to retrieve (GET), update (PUT) or delete (DELETE) that resource”); and
in response to the invocation, providing, by the service device and to the client device, the portion of the data (see [0024]; “allow the creation of new resources through a POST request. When a new resource has been POSTed, the response includes the URI of the new resource. The client may then use that URI to retrieve (GET), update (PUT) or delete (DELETE) that resource”. Also see [0007] and [0033]; “the formal REST interaction constraints applied to resources (components, connectors, and data elements)” and “A POST operation is used to transmit a representation of a new data entity to the server”),
wherein:
the at least one data source uniform resource identifier comprises a first data source uniform resource identifier and a second data source uniform identifier, the REST API associates the first data source uniform resource identifier with a first resource and the second data source uniform resource identifier with a second resource, and prior to obtaining the new resource creation request, the REST API did not include any data source uniform resource identifier associated with both the first resource and the second resource (see [0033]-[0034]; “The three resources, Resource A, Resource B, and Resource C, collected and identified in the client domain as local:resourceA, local:resourceB, and local:resourceC, are “wrapped” (coupled with associated metadata identifying their relationships) and POSTed to the server in one request … After this creation process, the resources now have the correct server-assigned URIs. Specifically, Resource A is now identified by the URI http://myhost/resourceA, Resource B becomes http://myhost/resourceB, and Resource C is http://myhost/resourceC. Their reference properties now also use those server-assigned URIs”. Before obtaining the new resource creation request, i.e., the POST request, the REST API does not include URI associated with resources A, B, C; such associations are achieved during and after the creations of new resources).
Evans does not disclose:
the data source uniform resource identifier associated with the new custom resource is a new data source uniform resource identifier, and the new custom resource being usable to obtain a portion of the data associated with the at least one data source uniform resource identifier,
the REST API associates the first data source uniform resource identifier with a first sub-portion of the portion of the data and the second data source uniform resource identifier with a second sub-portion of the portion of the data, and
the REST API did not include any data source uniform resource identifier associated with both the first sub-portion of the portion of the data and the second sub-portion of the portion of the data.
However, Munoz discloses:
the new custom resource having a new data source uniform resource identifier, and the new custom resource being usable to obtain a portion of the data associated with the at least one data source uniform resource identifier, associates the first data source uniform resource identifier with a first sub-portion of the portion of the data and the second data source uniform resource identifier with a second sub-portion of the data (see [0033], [0045], [0069]; “the user may associate a tab with a stack of pages through which the user may visually navigate. The uniform resource indicator (URI) address of each page in the stack may be stored in the master URI of the stack associated with the tab, allowing for sharing or bookmarking of the stack … a URI may include a uniform resource locator (URL), a uniform resource name (URN) or an indicator of other resources or content, for example deep links of applications”, “the address of the stack may include a combination of the addresses of the pages 302 and 304 in the stack”, “a stack, may be implemented by combining the URI addresses into a single master URI address. The URI addresses may be written into the master URI address in the same order in which they are placed in the stack. A combination character or set of characters, for example &&& may be placed in between the URI addresses of the pages in the stack … The master URI of the stack may then be … the same order as they appear in the stack”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the URI of new resource created by REST API request from Evans by including combining URI addresses of multiple objects into a single URI address of a new object from Munoz, and thus the combination of Evans and Munoz would disclose the missing limitations from Evans, since it would provide a mechanism allowing a user to navigate through multiple dimensions of resources within a single tab of an application (see [0033], [0045] and [0069] from Munoz).
Regarding to Claim 5, the rejection of Claim 1 is incorporated and further the combination of Evans and Munoz discloses: wherein the new custom resource associates the first sub-portion of the portion of the data and the second sub-portion of the portion of the data with the new data source uniform resource identifier (see [0033] and [0069] from Munoz; “a stack of pages through which the user may visually navigate. The uniform resource indicator (URI) address of each page in the stack may be stored in the master URI of the stack associated with the tab” and “for example &&& may be placed in between the URI addresses of the pages in the stack … The master URI of the stack may then be … the same order as they appear in the stack”).
Regarding to Claim 6, the rejection of Claim 1 is incorporated and further the combination of Evans and Munoz discloses:
obtaining, by the service device and from a second client device, a second invocation of the REST API, the first data source uniform resource identifier be provided as part of the second invocation; in response to the second invocation, providing, by the service device and to the second client device, the first sub-portion of the portion of the data (see Fig. 1, [0017], [0023]-[0024] and [0033] from Evans; “the server 102 may communicate primarily with one or more clients 112”, “a RESTful client generally retrieves, creates, updates and deletes resources through HTTP methods (GET, POST, PUT, DELETE). Each resource is identified by a URI” and “PUT requests that the enclosed entity be stored under the URI that is provided in the request”. At the combination system, a second client from the one or more clients 112 makes REST API request/invocation to request the first sub-portion of the portion of the data or pages via the corresponding URI of the first sub-portion on the REST API request/invocation);
obtaining, by the service device and from a third client device, a third invocation of the REST API, the second data source uniform resource identifier be provided as part of the third invocation; and in response to the third invocation, providing, by the service device and to the third client device, the first sub-portion of the portion of the data (see [0024], [0033] from Evans and [0033] from Munoz; “A POST operation is used to transmit a representation of a new data entity to the server, so that it will be stored as a new subordinate of the resource identified by the URI … In the event that the URI does not yet have a corresponding resource, then the server creates the resource with that URI” and “the user may associate a tab with a stack of pages through which the user may visually navigate. The uniform resource indicator (URI) address of each page in the stack may be stored in the master URI of the stack associated with the tab”. Also see Fig. 1, [0017] from Evans; “the server 102 may communicate primarily with one or more clients 112”. At the combination system, a third client from the one or more clients 112 makes REST API request to create another new resource contains at least first sub-portion and second sub-portion, and thus the response of such REST API request contains a master URI having second URI associated with the second sub-portion and first URL associated with the first sub-portion, then the third client uses such master URI to make REST API invocation to request such new resources to access at least the first sub-portion). Note: the claim now only requests “the second data source uniform resource identifier be provided as part of the third invocation” and “providing” “the first sub-portion of the portion of the data”. Such particular requirement does not further limit that the claimed third invocation contains the second data source uniform resource identifier only without containing the URI associated with the first sub-portion of the portion of the data OR the claimed providing does not provide the second sub-portion and the first sub-portion of the portion of data together.
Regarding to Claim 7, the rejection of Claim 1 is incorporated and further the combination of Evans and Munoz discloses: wherein the REST API comprises a customizable resource (see [0024] from Evans, [0033] and [0069] from Munoz; “allow the creation of new resources through a POST request. When a new resource has been POSTed, the response includes the URI of the new resource” “the user may associate a tab with a stack of pages through which the user may visually navigate. The uniform resource indicator (URI) address of each page in the stack may be stored in the master URI of the stack associated with the tab”. The new resource created by REST at the combination system is a combination/stack of pages selected or associated by user, and thus the REST API comprises a customizable resource by the user).
Regarding to Claim 8, the rejection of Claim 7 is incorporated and further the combination of Evans and Munoz discloses: wherein the new resource creation request comprises a criteria usable to discriminate the at least one data source uniform resource identifier from other data source uniform resource identifiers of the REST API (see [0033] and [0069] from Munoz; “a stack of pages through which the user may visually navigate. The uniform resource indicator (URI) address of each page in the stack may be stored in the master URI of the stack associated with the tab” and “for example &&& may be placed in between the URI addresses of the pages in the stack … The master URI of the stack may then be … the same order as they appear in the stack”).
Regarding to Claim 9, Claim 9 is a product claim corresponds to method Claim 1 and is rejected for the same reason set forth in the rejection of Claim 1 above (see “Software and data 522 are stored in persistent storage 508 for access and/or execution by processors 504” from [0057] and [0064]- [0065] from Evans for claimed limitation “non-transitory machine-readable medium … cause the processor to perform operations”).
Regarding to Claim 13, Claim 13 is a product claim corresponds to method Claim 5 and is rejected for the same reason set forth in the rejection of Claim 5 above.
Regarding to Claim 14, Claim 14 is a product claim corresponds to method Claim 6 and is rejected for the same reason set forth in the rejection of Claim 6 above.
Regarding to Claim 15, Claim 15 is a product claim corresponds to method Claim 7 and is rejected for the same reason set forth in the rejection of Claim 7 above.
Regarding to Claim 16, Claim 16 is a product claim corresponds to method Claim 8 and is rejected for the same reason set forth in the rejection of Claim 8 above.
Regarding to Claim 17, Claim 17 is a system claim corresponds to method Claim 1 and is rejected for the same reason set forth in the rejection of Claim 1 above (see “Software and data 522 are stored in persistent storage 508 for access and/or execution by processors 504” from [0057] and [0064]- [0065] from Evans for claimed limitation “a processor … cause the processor to perform operations”).
Regarding to Claim 21, Claim 21 is a system claim corresponds to method Claim 5 and is rejected for the same reason set forth in the rejection of Claim 5 above.
Regarding to Claim 22, Claim 22 is a system claim corresponds to method Claim 6 and is rejected for the same reason set forth in the rejection of Claim 6 above.
Regarding to Claim 23, Claim 23 is a system claim corresponds to method Claim 7 and is rejected for the same reason set forth in the rejection of Claim 7 above.
Regarding to Claim 24, Claim 24 is a system claim corresponds to method Claim 8 and is rejected for the same reason set forth in the rejection of Claim 8 above.
Claim 25 is rejected under 35 U.S.C. 103 as being unpatentable over Evans (US 20150237165 A1) in view of Munoz (US 20170060349 A1, hereafter Munoz) and further in view of Bothwell et al. (US 20230198860 A1, hereafter Bothwell).
Regarding to Claim 25, the rejection of Claim 1 is incorporated, the combination of Evans and Munoz does not disclose: wherein the portion of the data indicates port states and network topology of a plurality of network devices.
However, Bothwell discloses: wherein the portion of the data to be requested by REST API indicates port states and network topology of a plurality of network devices (see [0007]; “the temporal monitoring and visualization of the health of a direct interconnect network comprising the steps of: (i) discovering and configuring nodes interconnected in the direct interconnect network; (ii) determining network topology of the nodes and maintaining and updating a topology database as necessary; (iii) receiving node telemetry data from each of the nodes or every port on each of the nodes at a time interval and storing said node telemetry data in association with a timestamp in a temporal datastore; (iv) raising an alarm if applicable against at least one node or at least one port of said at least one node if any such node telemetry data in respect of the at least one node or the at least one port of said at least one node crosses a node metrics threshold or if there is a change to the network topology in respect of the at least one node or the at least one port of said at least one node during the time interval; (v) assigning an individual health status to each of the nodes or every port on each of the nodes”. Also see [0124], [0137]; “An API layer provides access to querying the topological state and health state to consumers preferably via RESTful services (Representational State Transfer; a stateless, client-server, cacheable communications protocol) for instance. The UI's visualization component leverages the API to display the topology and health of the network at any point in time in various unique”).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the process of querying or retrieving certain generic object or information via REST API from the combination of Evans and Munoz by including the process of querying or retrieving particular type of object or information from Bothwell, and thus the combination of Evans, Munoz and Evans would disclose the missing limitations from the combination of Evans and Munoz, since it would provide a mechanism to specify particular application to be utilized on REST API (see [0007], [0124], [0137] from Bothwell).
Claim 26 is rejected under 35 U.S.C. 103 as being unpatentable over Evans (US 20150237165 A1) in view of Munoz (US 20170060349 A1, hereafter Munoz) and further in view of Miller et al. (US 20210019067 A1, hereafter Miller).
Regarding to Claim 26, the rejection of Claim 1 is incorporated, the combination of Evans and Munoz does not disclose: wherein the new resource creation request is automatically generated based on a detected pattern of API call activity.
However, Miller discloses: wherein the new resource creation [request] is automatically generated based on a detected pattern of API call activity (see [0343]; “automatic use of a write-mostly storage class based on a determination that a cost or budget may be saved and reused for other purposes if data that is determined to have a low likelihood of access is consolidated, such as into segments that consolidate data with similar access patterns or similar access likelihood characteristics”. Also see [0329]; “Receiving (1702), by the virtual storage system 1700, the request to write data to the virtual storage system 1700 may be carried out as described above … and the request may be received using one or more communication protocols, or one or more API calls provided by a cloud computing environment 402 that is hosting the virtual storage system 1700”. Due to the data access requests are implemented via API calls, and thus the similar access patterns discussed at [0343] in one of the reasonable embodiments is actually detected pattern of API call activity).
It would have been obvious to one with ordinary skill, in the art before the effective filing date of the claim invention, to modify the request to create a new object via merging multiple objects from the combination of Evans and Munoz by including the process of merging multiple data portions based on detected API request pattern from Miller, and thus the combination of Evans, Munoz and Miller would disclose the missing limitations from the combination of Evans and Munoz, since it would provide a mechanism to improve cost or budge for storage resource (see [0343] from Miller; “a determination that a cost or budget may be saved and reused for other purposes if data that is determined to have a low likelihood of access is consolidated”).
Response to Arguments
Applicant’s arguments, filed 6/25/2026, with respect to rejections of claims 1, 5-9, 13-17 under 35 U.S.C. 103 have been full considered but they are not persuasive.
Applicant’s arguments at pages 8-10 are summarized as the following:
For the amended independent claims 1, 9 and 17, “even combining the teachings of Evans and Munoz fails to suggest that ‘the REST API did not include any data source uniform resource identifiers associated with both the first sub-portion of the portion of the data and the second sub-portion of the portion of the data’ when ‘the REST API associates the first data source uniform resource identifier with a first sub-portion of the portion of the data and the second data source uniform resource identifier with a second sub-portion of the portion of the data’ and ‘the at least one data source uniform resource identifier comprises a first data source uniform resource identifier and a second data source uniform resource identifier,’ as required by the claim” (see 3rd paragraph of page 9 from the Remarks). Applicant also argued that “[T]hat is, the combined teachings of Evans and Munoz fail to disclose or suggest identifying a uniform resource identifier, which includes two identifiers associated with sub-portions of data, when no identifiers associated with the sub-portions of data were present” (see 4th paragraph of page 9 from the Remarks).
The examiner respectively disagrees.
Applicant is suggested to review the amended independent claims carefully since Applicant were arguing certain feature that is not required by the current claims. According to the current language used at the claims 1, 9 and 17, the feature related to “the REST API did not include any data source uniform resource identifiers” is required to be occurred “prior to obtaining the new resource creation request” instead of the two conditions that Applicant argued. According to different unclaimed or possible implementations or embodiments of the claimed invention, the two conditions that Applicant argued may be included within “prior to obtaining the new resource creation request”. However, under BRI of the current claims 1, 9 and 17, such two conditions are not necessary to be included within “prior to obtaining the new resource creation request”, let alone the current claimed invention requires the feature related to “the REST API did not include any data source uniform resource identifiers” to be occurred when such two conditions as Applicant argued. In this way, Applicant was arguing certain feature that is not required by the current claims.
For the argument none of reference alone or in combination teaches “suggest identifying a uniform resource identifier, which includes two identifiers associated with sub-portions of data, when no identifiers associated with the sub-portions of data were present”, once again, Applicant is suggested to review the amended independent claims carefully since nothing from the claimed invention requires the claimed identifying limitation (i.e., “identifying, by the service device and based on the new resource creation request, at least one data source uniform resource identifier of the REST API” at lines 5-6 of claim 1) is occurred “when no identifiers associated with the sub-portions of data were present”. Actually, there is no such “no identifiers associated with the sub-portions of data were present”. The exact related limitation from claim 1 is “the REST API did not include any data source uniform resource identifiers associated with both the first sub-portion of the portion of the data and the second sub-portion of the portion of the data” (see last 4 lines of claim 1). Such feature is different from “no identifiers associated with the sub-portions of data were present”. For the exact claimed feature, it is possible that there are/were identifiers associated with the sub-portions of data (i.e., the identifiers associated with the sub-portions of data were present) but such identifiers are not included in the REST API OR the REST API is possible to include certain data source uniform resource identifiers but such identifiers are not associated with sub-portions of data yet. None of them is same or similar as “no identifiers associated with the sub-portions of data were present” that Applicant argued.
Therefore, Claims 1, 5-9, 13-17 are rejected.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Pan et al. (CN 107749802 B-English translation provided by Google Patents) discloses: the portions of data to be retrieved via REST GET request indicates port states and network topology of a plurality of network devices (see [0049], [0166]-[0177]).
Yang et al. (US 20160261727 A1) discloses: this system provides a REST State Management Service that allows each component in the database streaming ecosystem to record their state, such as running versus not running (see [0157]).
Savalle et al. (US 20240394121 A1) discloses: based on a set of calls among the API calls that are frequently co-occurring or are made to query same database but different information, consolidating the set of calls into a single API call (see [0134] and [0136]-[0138]).
Ohyama et al. (US 20070250827 A1) discloses: a section consolidation unit configured to consolidate the sections based on the function call graph, the execution transition frequency between functions and an instruction memory constraint (see [0031], [0203] and claim 16).
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 extension fee pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to ZHI CHEN whose telephone number is (571)272-0805. The examiner can normally be reached on M-F from 9:30AM to 5:30PM.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, April Y Blair can be reached on 571-270-1014. 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 to 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.
/Zhi Chen/
Patent Examiner, AU2196
/APRIL Y BLAIR/Supervisory Patent Examiner, Art Unit 2196
Prosecution Insights