DETAILED ACTION
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 02/13/2026 has been entered.
Claims 1-18, 20 and 22 are pending. Claims 1, 17, 18, 20, and 22 are in independent form. Claims 19 and 21 are cancelled. Claims 1-11, 13, 15-17, 20, and 22 are amended.
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 .
Response to Amendment
This Office Action is in response to the applicant’s remarks and arguments filed on 02/13/2026.
Claims 19 and 21 are canceled. Claims 1-11, 13, 15-17, 20, and 22 are amended. Claims 1-18, 20 and 22 remain pending in the application and are being considered on the merits.
Applicant’s argument filed on 02/13/2026 regarding 35 U.S.C. §101 Rejections have been fully considered and they are persuasive. The 35 U.S.C. §101 Rejections has been withdrawn.
Applicant’s argument filed on 02/13/2026 regarding Claim Objections have been fully considered and they are persuasive. The examiner agreed with all of the amendment made to the claims 1, 17, 20, and 22. The Claim Objections has been withdrawn.
The previous claims Rejection under 35 U.S.C § 103 has been withdrawn due to the amendment to the claims filed on 02/13/2026. However, upon further consideration, a new ground(s) of rejection is made in view of a newly found prior art KO et al. US Pub. No. US 20160092493 A1 and Tucker9901 et al. US Pub. No. US 20210109901 A1, and in view of the previously cited prior art(s). Reference KO and Tucker9901, in combination with previously cited prior art(s), discloses each element of the claims highlighted by applicant.
Response to Arguments
The applicant’s remarks and/or arguments, filed on 02/13/2026 have been fully considered with the following result(s).
The examiner is entitled to give claim limitations their broadest reasonable interpretation in light of the specification. See MPEP 2111 [R-1] Interpretation of Claims-Broadest Reasonable Interpretation. The applicant always has 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).
Response to Claim Objections
Applicant’s argument filed on 02/13/2026 regarding Claim Objections have been fully considered and they are persuasive. The examiner agreed with all of the amendment made to the claims 1, 17, 20, and 22. The Claim Objections has been withdrawn.
Response to 35 U.S.C. § 101 Remarks
Applicant’s argument filed on 09/05/2025 regarding 35 U.S.C. § 101 rejections have been fully considered but they are persuasive. The 35 U.S.C. §101 Rejections has been withdrawn.
Response to 35 U.S.C. § 103 Remarks
Applicant’s argument filed on 09/05/2025 regarding 35 U.S.C. § 103 rejections have been fully considered and they are persuasive. The previous claims Rejection under 35 U.S.C § 103 has been withdrawn due to the amendment to the claims filed on 02/13/2026. However, upon further consideration, a new ground(s) of rejection is made in view of a newly found prior art KO et al. US Pub. No. US 20160092493 A1 and Tucker9901 et al. US Pub. No. US 20210109901 A1, and in view of the previously cited prior art(s). Reference KO and Tucker9901, in combination with previously cited prior art(s), discloses each element of the claims highlighted by applicant.
Specification
The abstract of the disclosure is objected to because the abstract is not written in the correct format. 37 CFR 1.72 requires that the abstract should be in narrative form and generally limited to a single paragraph on a separate sheet within the range of 50 to 150 words in length.
A patent abstract is a concise statement of the technical disclosure of the patent and should include that which is new in the art to which the invention pertains. The abstract should not refer to purported merits or speculative applications of the invention and should not compare the invention with the prior art.
If the patent is of a basic nature, the entire technical disclosure may be new in the art, and the abstract should be directed to the entire disclosure. If the patent is in the nature of an improvement in an old apparatus, process, product, or composition, the abstract should include the technical disclosure of the improvement. The abstract should also mention by way of example any preferred modifications or alternatives.
Where applicable, the abstract should include the following: (1) if a machine or apparatus, its organization and operation; (2) if an article, its method of making; (3) if a chemical compound, its identity and use; (4) if a mixture, its ingredients; (5) if a process, the steps.
See MPEP § 608.01(b) for guidelines for the preparation of patent abstracts.
Appropriate correction is required.
Claim Objections
Claim 6 is objected to because of the following informalities: in line 5: “he first REST server”. It should be “the first REST server”.
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 2-5 and 7-14 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 2 recites the limitation "a second REST server" in lines 3-4, and the limitation “the second REST server” in lines 9. There is insufficient antecedent basis for this limitation in the claim. It is unclear which “second REST server” that the limitation “the second REST server” in lines 9 is referring to, because in claim 3 depends on claim 1, and claim 1 also recites the limitation “a second REST server" in lines 14.
Claim 3 recites the limitation "a second REST server" in lines 4, and the limitation “the second REST server” in lines 11. There is insufficient antecedent basis for this limitation in the claim. It is unclear which “second REST server” that the limitation “the second REST server” in lines 11 is referring to, because in claim 3 depends on claim 1, and claim 1 also recites the limitation “a second REST server" in lines 14.
Claim 4-5 are rejected due to the dependency on the rejection of claim 3.
Claim 7 recites the limitation "a second REST server" in lines 11, and the limitation “the second REST server” in lines 13-14. There is insufficient antecedent basis for this limitation in the claim. It is unclear which “second REST server” that the limitation “the second REST server” in lines 13-14 is referring to, because in claim 7 depends on claim 6 and claim 1, and claim 1 also recites the limitation “a second REST server" in lines 14.
Claim 8 recites the limitation "the second device" in lines 4 and 7. There is insufficient antecedent basis for this limitation in the claim. It is unclear which “second device” that the limitation “the second device” in lines 4 and 7 is referring to.
Claim 9 recites the limitation "a second REST server" in lines 3-4, and the limitation “the second REST server” in lines 6. There is insufficient antecedent basis for this limitation in the claim. It is unclear which “second REST server” that the limitation “the second REST server” in lines 6 is referring to, because in claim 9 depends on claim 1, and claim 1 also recites the limitation “a second REST server" in lines 14.
Claim 10-16 are rejected due to the dependency on the rejection of claim 9.
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, 17, 18, 20, and 22 are rejected under 35 U.S.C. 103 as being unpatentable over Tucker et al. US Pub. No. US 20170124452 A1 (hereafter Tucker), in further view of KO et al. US Pub. No. US 20160092493 A1 (hereafter KO), and Tucker et al. US Pub. No. US 20210109901 A1 (hereafter Tucker9901).
Regarding claim 1, Tucker teaches the invention substantially as claimed: A method for generating output data based on a computational graph (FIG. 1 and [0024]: “FIG. 1 illustrates an example computational graph system 100 for distributing operations for neural networks represented as computational graphs.”) and [0030]: “The system 100 performs the operations to generate the particular output by partitioning the operations represented by the computational graph across multiple devices 116-122”) The citations disclose the system performs the operations represented by the computational graph to generate the output.
the method comprising: a first device storing information related to the computational graph ([0007]: “a device to which the one or more respective nodes are assigned” and [0031]: “Any devices performing neural network operations, e.g., devices 116-122, can include a memory, e.g., a random access memory (RAM), for storing instructions and data and a processor for executing stored instructions.”) The citation discloses at [0007] one or more nodes are assigned to a device, and at [0031] any of the devices 116-122 in the computational graph system 100 can store instruction and data/information.
the computational graph defining a set of operations ([0036]: “The session manager 104 also provides sets of operations to be performed in the computational graph to the executor 106.”)
wherein the set of operations comprises a first subset of one or more operations ([0049]: “The system can partition the computational graph into three subgraphs 318-322. To generate the subgraphs 318-322, the system can analyze the computational graph to identify chains of nodes. ….. a second chain of nodes 302, 306, 310” and [0006]: “wherein each node represents a respective operation”) The citation discloses the computational graph can partition into three subgraphs 318-322/subsets, and the first subgraph/second chain of nodes includes the nodes 302, 306, and 310. Each node represents a respective operation.
and a second subset of one or more operations, ([0049]: “a first chain of nodes 304, 316” and [0006]: “wherein each node represents a respective operation”) The citation discloses the second subgraph/first chain of nodes includes the nodes 304 and 316. Each node represents a respective operation.
and further wherein the information related to the computational graph comprises information representing the first subset of operations ([0039]: “Each node can contain information specifying an operation type, a name, and a list of incoming and outgoing edges to the node.” and [0051]: “The system can start by assigning a first subgraph 322 because it contains an initial node 302 and none of the nodes depend on outputs of other subgraphs.”) The citations disclose at [0039] each node contains the information that relate to the computational graph and at [0051] each subgraph contains nodes that stored the information.
the first device receiving input data ([0048]: “The set of inputs can be provided on a directed edge to the node 302.” and [0051]: “The system can start by assigning a first subgraph 322 because it contains an initial node 302 and none of the nodes depend on outputs of other subgraphs.”) The citations disclose the initial node 302/first device receive the set of inputs.
the first device performing the first subset of operations using the received input data ([0048]: “The set of inputs can be provided on a directed edge to the node 302.” And [0051]: “an output of the node 302, which will be calculated by the device assigned to the first subgraph 322.” and [0047]: “The system causes the devices to perform the operations of the nodes assigned to the devices”) The citation discloses the device, which is assigned to node 302, performs the operations using the provided input.
thereby producing first output data corresponding to the first subset of operations; ([0051]: “an output of the node 302, which will be calculated by the device assigned to the first subgraph 322.”) The citation discloses the output is generated after performing the operations at node 302 by the device assigned to the first subgraph 322.
and the first device exposing the first output data as a discoverable resource
so that the first output data is discoverable by a second device. ([0053]: “Similarly, the initial node 308 of the third subgraph 320 requires the output of the node 306. The system can wait to assign the third subgraph 320 until the device to which the first subgraph is assigned completes the operation represented by node 306. Once the operation represented by the node 306 completes, the system can analyze the output of the node 306 to assign the third subgraph 320 to a respective available device.” And [0050]: “That is, the device can access the same memory location that stores the output from the node 306 when performing operations for both node 310 and 308.”) The citation discloses the output of the node 306 is assigned to the third subgraph 320 after complete the operations at the node 306 by the assigned device. At [0500] discloses the device performs operations for both node 310 and 308 can access the same memory location that stores the output from node 306/making the output, as discoverable resource for other devices.
thereby enabling the second device to produce further output data by performing the second subset of operations on the first output data, (e.g. FIG. 3 and [0042]: “Nodes in a chain structure are nodes that are connected to each other by following one directed edge from node to node. Thus, a node in the chain must wait for operations at previous nodes in the chain to finish computing before computing its own operation. Partitioning subgraphs will be described further with reference to FIG. 3.” and [0052]-[0055]) the citation discloses at [0042] the concept where the nodes in the chain must wait for the operation at the previous node/output data. At [0052]-[0054] disclose the node 312/second device, must wait for the output from previous nodes before performing node 312 operations.
Tucker fails to teach the first device as a first representational state transfer (REST) server; the second device as a second REST server; the first output data having a resource type; the first REST sever obtaining a resource identifier for use in retrieving the first output data; the first REST server linking the resource identifier with the first output data, and the first REST server linking the resource identifier for retrieving the first output data with a first resource type value identifying the resource type of the first output data.
However, KO teaches the first output data having a resource type (e.g. FIG. 1-4, [0022]: “For example, the MapReduce system names the input data blocks, the intermediate outputs of the map computations, and the final outputs of the reduce computations. The assigned names enable a unique identification of the data in the various stages of the MapReduce system given the input data and the type of the MapReduce computation.” and [0025]: “Stated differently, each block 206 to 212 of the input file 130 is assigned a name 214 that is generated based on the data of the block (as compared to being based on the name of its input file); the offset of the input file at which the block starts; and by the length of the block. For example, the name of the block can be a digest such as the SHA1 or MD5 digest of the data block. This naming mechanism enables the reuse of the data block across different input files 130 that happen to have overlapping content.”) The citations disclose at [0022] that each output at each state is assigned a name/resource type, and at [0025] discloses each block 206-212 of the input file 130 is assigned a name/resource type, based on the name of its input file.
the first REST sever obtaining a resource identifier for use in retrieving the first output data; (e.g. FIG. 4, [0040]: “In one embodiment, the MapReduce system utilizes HTTP for naming and retrieving all output data produced in any of its three computation stages: splitter data, mapper data, and reducer data. The use of HTTP simplifies both the naming and the caching of the data and enables the reuse of existing Content Delivery Network (CDN) or HTTP transparent proxy infrastructures for scalability and performance. The names of the data are encoded in the URI portion of the HTTP URL, while the host portion of the HTTP URL is constructed by a manner similar to the way CDNs encode the server names and their locations” and [0041]: “FIG. 4 shows one example of a diagram illustrating the communication model between the different components of the MapReduce system when using HTTP. It should be noted that other communication models, such as remote procedure calls (RPC) and Representational State Transfer (REST), are applicable as well.”) The citation discloses the concept of using HTTP for naming and retrieving all output data produced by the components, and the names of the data are encoded in the URI portion of the HTTP URL/resource identifier. At [0041] discloses the REST communication can be used with this concept.
the first REST server linking the resource identifier with the first output data, (e.g. FIG. 4, [0040] and [0041]) The citation discloses the URL/resource identifier, is used for retrieving the output data.
and the first REST server linking the resource identifier for retrieving the first output data with a first resource type value identifying the resource type of the first output data. (e.g. FIG. 4, [0040] and [0041]) the citation discloses at FIG. 4 the block name/resource type, is a component of the URL/resource identifier.
Both Tucker and KO are in the same field of endeavor, and both references discloses the concept of data processing, and therefore, are combinable/modifiable.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the first output data having a resource type; the first REST sever obtaining a resource identifier for use in retrieving the first output data; the first REST server linking the resource identifier with the first output data, and the first REST server linking the resource identifier for retrieving the first output data with a first resource type value identifying the resource type of the first output data, as taught in KO’s invention into Tucker’s invention because by associate the first output data with a resource type value when exposing it as a discoverable resource, it helps to improve the discoverability and usability of the data by enabling other devices or services quickly and effectively locate, identify, and utilize the data for further processing. This approach helps to enhance the performance and scalability in system that process computational graphs across multiple devices or components. It also helps to ensure the receiver node devices capable of performing the computational of the receiving output data.
However, Tucker9901 teaches the first device as a first representational state transfer (REST) server; the second device as a second REST server; (e.g. FIG. 6-8 and [0110]: “In embodiments where the central control module 2 is a REST server, the REST server is implemented in server hardware or implemented as a virtual server executing on one or more server hardware components. [0111]: “In some embodiments, the data management system comprises a plurality of central control modules 2 which are each implemented as a respective REST server. The REST servers are configured to execute in parallel with one another and are preferably configured to communicate with one another so that the functions of the REST servers can be spread across the plurality of REST servers to optimise performance of the data management system.”) The citation discloses the system comprises multiple REST servers.
Both Tucker and Tucker9901 are in the same field of endeavor, and both references discloses the concept of data management system, and therefore, are combinable/modifiable.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the the first device as a first representational state transfer (REST) server; the second device as a second REST server, as taught in Tucker9901’s invention into Tucker’s invention because the integration of multiple RESR servers system would enable the system to improve in resource identifications, representations, interactions and connections relatively independently.
Regarding claim 17, the claim is a method claim that having similar limitations cited in claim 1. Thus, claim 17 is also rejected under the same rational as cited in the rejection of rejected claim 1.
Regarding claim 18, the claim is a non-transitory computer readable storage medium claim that having similar limitations cited in claim 1. Thus, claim 18 is also rejected under the same rational as cited in the rejection of rejected claim 1.
Regarding claim 20, the claim is an apparatus claim that having similar limitations cited in claim 1. Thus, claim 10 is also rejected under the same rational as cited in the rejection of rejected claim 1.
Regarding claim 22, the claim is a method claim that having similar limitations cited in claim 17. Thus, claim 22 is also rejected under the same rational as cited in the rejection of rejected claim 17.
Claims 2 and 9 are rejected under 35 U.S.C. 103 as being unpatentable over Tucker, KO, and Tucker9901, in further view of Vasudevan et al. US Pub. No. US 20170124454 A1 (hereafter Vasudevan)
Regarding claim 2, Tucker, in view of KO and Tucker9901, discloses the method of claim 1, and KO further teaches in response to receiving the request message, the first REST server using the resource identifier to retrieve the first output data (e.g. [0041]: “The URL of the post message is the name of the reduce node's output, while the body of the post message includes a list of all the URLs that the reducer node can use in order to collect the mapper outputs.”) the citation discloses the concept of using the URL/resource identifier, to collect/retrieve, the output.
Tucker, in view of KO and Tucker9901, fails to teach wherein the method further comprises: the first REST server receiving a request message transmitted by a second REST server, wherein the request message comprises the resource identifier; ........ and the first REST server transmitting the retrieved first output data toward the second REST server in response to receiving the request message.
However, Vasudevan teaches wherein the method further comprises: the first REST server receiving a request message transmitted by a second REST server, (FIG. 3 and [0068]: “Execution of operations 340 represented by receive node R.sub.3 may involve sending one or more messages to that of corresponding send node S.sub.3 (344). Such messages may serve as indication that the subgraph to which the receive node R.sub.3 belongs is ready to receive input by way of execution of corresponding send node S.sub.3. In this way, these messages can be seen as a request to receive data output by one or more upstream operations.”) The citation discloses the execution operations represented by node R.sub.3/second device sends a request message to node S.sub.3/first device
wherein the request message comprises the resource identifier; ([0068]: “these messages can be seen as a request to receive data output by one or more upstream operations. In the example of FIG. 3, the operations 340 represented by receive node R.sub.3 may receive input from send node S.sub.3 that includes the output of the operation represented by node 310.”) The teaching of Vasudevan only discloses the concept of the sending output, but fail to disclose the output as the resource identifier. Ng discloses the output identifier at [0073], so by replacing the output with the output identifier/resource identifier, one with the ordinary skills in the art would be able to come up with the claim invention.
and the first REST server transmitting the retrieved first output data toward the second REST server in response to receiving the request message. ([0069]: “At execution, the operations 330 represented by send node S.sub.3 may include a relaying of data in response to receipt of such messages. In some examples, the operations 330 represented by send node S.sub.3 may not act to relay the output of the operation represented by node 310 until such a message has been received (336). In this way, the flow of information between devices may be regulated so as to ensure that tensors are successfully exchanged …… the operations represented by receive node R.sub.3 may act to provide such output as input to the operation represented by downstream node 320 (348).”) The citation discloses after receiving the request message, the operation 310 relay the output data/transmit the first data to the downstream node 320.
Both Tucker and Vasudevan are in the same field of endeavor, and both references discloses the concept of processing computational graphs, and therefore, are combinable/modifiable.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the first REST server receiving a request message transmitted by a second REST server, wherein the request message comprises the resource identifier; ........ and the first REST server transmitting the retrieved first output data toward the second REST server in response to receiving the request message, as taught in Vasudevan’s invention into Tucker, KO and Tucker9901’s invention because it helps to prevent the slowdown or corruption of the whole computational graph system because the output from the first node is sent to the second node when the second node does not finish the operation and does not ready to receive the output.
Regarding claim 9, Tucker, in view of KO and Tucker9901, discloses the method of claim 1, but fails to teach further comprising: the first REST server receiving a resource message that indicates that the first REST server should send the first output data to a second REST server; and after receiving the resource message, the first REST server transmitting the first output data toward the second REST server.
However, Vasudevan teaches further comprising: the first REST server receiving a resource message that indicates that the first REST server should send the first output data to a second REST server ([0068]: “Execution of operations 340 represented by receive node R.sub.3 may involve sending one or more messages to that of corresponding send node S.sub.3 (344). Such messages may serve as indication that the subgraph to which the receive node R.sub.3 belongs is ready to receive input by way of execution of corresponding send node S.sub.3.”) The citation discloses the S.sub.3 receive the message sent from R.sub.3 indicate that it ready to receive input/indicate that the first device should send the first output.
and after receiving the resource message, the first REST server transmitting the first output data toward the second REST server. ([0068]): “In the example of FIG. 3, the operations 340 represented by receive node R.sub.3 may receive input from send node S.sub.3 that includes the output of the operation represented by node 310.”) The citation discloses the node S.sub.3 send the output to the node R.sub.3
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the first device receiving a resource message that indicates that the first device should send the first output data to a second device; and after receiving the resource message, the first device transmitting the first output data toward the second device, as taught in Vasudevan’s invention into Tucker’s invention because it helps to prevent the slowdown or corruption of the whole computational graph system because the output from the first node is send to the second node when the second node does not finish the operation and does not ready to receive the output.
Claims 6 are rejected under 35 U.S.C. 103 as being unpatentable over Tucker, KO, and Tucker9901, in further view of Hong et al. US Pub. No. US 20160345283 A1 (hereafter Hong)
Regarding claim 6, Tucker, in view of KO, and Tucker9901, discloses the method of claim 1, wherein linking the resource identifier for retrieving the first output data with the first resource type value identifying the resource type of the first output data, but fails to teach comprises: the first REST server transmitting toward a resource directory a resource registration(RR) message for registering the first output data as a discoverable resource, the resource registration message comprising: i) the first resource type value and ii) the resource identifier for retrieving the first output data;
However, Hong teaches the first REST server transmitting toward a resource directory a resource registration(RR) message for registering the first output data as a discoverable resource, the resource registration message comprising: i) the first resource type value (e.g. [0147]: “The AE sends a request message to the CSE1 for simplified registration, wherein a resource type parameter of the request message is set as an AE registration resource type”) The citation discloses the application entity(AE)/first device, send/transmit, the message to the CSE1/resource directory for registration/registration message that include the resource type.
and ii) the resource identifier for retrieving the first output data; (e.g. [0147]: “and a registration object attribute of the AE registration resource is set as an AE simplified registration identifier.”) The citation discloses the AE identifier. The teaching of Hong does not clearly indicate that the AE identifier as the resource identifier for retrieving the output data. The resource identifier is taught by Ng at (e.g. [0073]). By combining the teaching of Ng about the output identifier (e.g. [0073]) as the resource identifier to retrieve the output data, one with the ordinary skills in the art would be able to come up with the claim invention.
Both Tucker and Hong are in the same field of endeavor, and both references discloses the concept of method and system for cross-node registration, and therefore, are combinable/modifiable.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the first REST server transmitting toward a resource directory a resource registration(RR) message for registering the first output data as a discoverable resource, the resource registration message comprising: i) the first resource type value and ii) the resource identifier for retrieving the first output data, as taught in Hong’s invention into Tucker, KO, and Tucker9901’s invention because by providing registration message that contain the resource type value and the resource identifier corresponding to the output data, it helps to ensure the correct and appropriate output data is being registered and transferred toward the receiver node devices.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Tucker, KO, Tucker9901, and Hong, in further view of Vasudevan et al. US Pub. No. US 20170124454 A1 (hereafter Vasudevan)
Regarding claim 7, Tucker, in view of KO, Tucker9901, and Hong, discloses the method of claim 7, but fails to teach wherein the method further comprises: after transmitting the RR message, the first REST server receiving a request message transmitted by a second REST server, wherein the request message comprises the resource identifier; and the first REST server transmitting the first output data toward the second REST server in response to receiving the request message.
However, Vasudevan teaches after transmitting the RR message, the first REST server receiving a request message transmitted by a second REST server (Vasudevan – e.g. FIG. 3 and [0068]: “Execution of operations 340 represented by receive node R.sub.3 may involve sending one or more messages to that of corresponding send node S.sub.3 (344). Such messages may serve as indication that the subgraph to which the receive node R.sub.3 belongs is ready to receive input by way of execution of corresponding send node S.sub.3. In this way, these messages can be seen as a request to receive data output by one or more upstream operations.”) The citation discloses the execution operations represented by node R.sub.3/second device sends a request message to node S.sub.3/first device.
wherein the request message requests comprise the resource identifier; (Vasudevan – e.g. [0068]: “these messages can be seen as a request to receive data output by one or more upstream operations. In the example of FIG. 3, the operations 340 represented by receive node R.sub.3 may receive input from send node S.sub.3 that includes the output of the operation represented by node 310.”) The citation discloses the downstream operation send a message to the upstream operations to request output data. It would imply that the request message would include an identifier for the upstream operation to send over the output data to the downstream operation. In addition, by also combine the teaching of Ng about the output identifier (e.g. [0073]) as the resource identifier to retrieve the output data, one with the ordinary skills in the art would be able to come up with the claim invention.
and the first REST server transmitting the first output data toward the second REST server in response to receiving the request message (Vasudevan - [0069]: “At execution, the operations 330 represented by send node S.sub.3 may include a relaying of data in response to receipt of such messages. In some examples, the operations 330 represented by send node S.sub.3 may not act to relay the output of the operation represented by node 310 until such a message has been received (336). In this way, the flow of information between devices may be regulated so as to ensure that tensors are successfully exchanged …… the operations represented by receive node R.sub.3 may act to provide such output as input to the operation represented by downstream node 320 (348).”) The citation discloses after receiving the request message, the operation 310 relay the output data/transmit the first data to the downstream node 320.
Both Tucker and Vasudevan are in the same field of endeavor, and both references discloses the concept of system for processing computational graphs, and therefore, are combinable/modifiable.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the wherein the method further comprises: after transmitting the RR message, the first REST server receiving a request message transmitted by a second REST server, wherein the request message comprises the resource identifier; and the first REST server transmitting the first output data toward the second REST server in response to receiving the request message, as taught in Vasudevan’s invention into Tucker, Thambidorai, Li, and Ng’s invention because it helps to prevent the slowdown or corruption of the whole computational graph system because the output from the first node is send to the second node when the second node does not finish the operation and does not ready to receive the output.
Claim 8 is rejected under 35 U.S.C. 103 as being unpatentable over Tucker, KO, Tucker9901, Hong, and Vasudevan, in further view of HONG et al. US Pub. No. US 20160218992 A1 (hereafter HONG)
Regarding claim 7, Tucker, in view of KO, Tucker9901, Hong, and Vasudevan, discloses the method of claim 7, but does not explicitly teach wherein the method further comprising: the second device transmitting a resource discovery message towards the resource directory, the resource discovery message comprising the first resource type value; and the second device receiving a notification message transmitted by the resource directory, the notification message comprising the resource identifier and a device identifier allocated to the first device, wherein the second device transmits the request message after receiving the notification message.
However, HONG teaches further comprising: the second device transmitting a resource discovery message towards the resource directory, the resource discovery message comprising the first resource type value (HONG – FIG. 9 and [0115]: “Referring to FIG. 9, the client transmits, to the resource directory, a GET request, for example, a GET request message, including a resource type that the client desires to look up in the resource directory.”) The citations disclose the client/second device sends to the resource directory a GET request message/a resource discovery message, which is including the resource type/resource type value.
and the second device receiving a notification message transmitted by the resource directory, the notification message comprising the resource identifier and a device identifier allocated to the first device ([0117]: “The resource directory generates a response message including a list of the IDs of the resources and node IP addresses.”) The citation discloses the resource directory generate a response message/a notification message, which includes the ID of the resources/resource identifier and node IP/device identifier allocated to the first device.
wherein the second device transmits the request message after receiving the notification message. ([0118]: “The client selects a resource from the list, and directly communicates with the selected resource using a CoAP.”) The citation discloses the client/second device directly communicates/transmit the request message after receive the response message/notification message.
Both Tucker and Vasudevan are in the same field of endeavor, and both references discloses the concept of system for performing communication method, and therefore, are combinable/modifiable.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the second device transmitting a resource discovery message towards the resource directory, the resource discovery message comprising the first resource type value; and the second device receiving a notification message transmitted by the resource directory, the notification message comprising the resource identifier and a device identifier allocated to the first device, wherein the second device transmits the request message after receiving the notification message, as taught in HONG’s invention into Tucker, KO, Tucker9901, Hong, and Vasudevan’s invention because by providing the resource directory as a middle man to validate the resource request from the client, it helps to ensure the correct resource or output data is transferred toward the requested node devices.
Claims 10 and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Tucker, KO, Tucker9901, and Vasudevan, in further view of Pignataro et al. US Pub. No. US 20190394124 A1 (hereafter Pignataro)
Regarding claim 10, Tucker, in view of KO, Tucker9901, and Vasudevan, discloses the method of claim 9, and Vasudevan further teaches the invention substantially as claimed: resource discovery message comprising the first resource type value. (Vasudevan - [0023]: “Generally, the input and outputs flowing along directed edges in the computational graph are tensors. A tensor is a multidimensional array of numeric or other values, e.g., strings, having a specific order that corresponds to the dimensionality of the array.” and Vasudevan - [0067]: “The operations 330 represented by send node S.sub.3 may then act to determine whether output of an operation of upstream node 310 has been provided (310). Such output may include a tensor produced by way of execution of a subgraph that includes node 310 and send node S.sub.3 by an assigned device.” and [0068]: “Execution of operations 340 represented by receive node R.sub.3 may involve sending one or more messages to that of corresponding send node S.sub.3 (344). Such messages may serve as indication that the subgraph to which the receive node R.sub.3 belongs is ready to receive input by way of execution of corresponding send node S.sub.3.”) The citation discloses at [0023] the outputs, as a result performing computational of an edge of the computational graph, are tensors, which is a multidimensional array of numeric or strings/resource type value. The citation discloses at [0068] that the R.sub.3 sends a message to request the output of S.sub.3 and at [0067] discloses the output includes the tensor that contains the resource type value.
Tucker, KO, Tucker9901, and Vasudevan do not explicitly teach further comprising: prior to receiving the resource message, the first REST server transmitting a resource discovery message comprising a particular resource type value.
However, Pignataro teaches prior to receiving the resource message, the first REST server transmitting a resource discovery message comprising a particular resource type value. (Pignataro - [0044]: “Generally, a DAG discovery request (e.g., DIO) message is transmitted from the root device(s) of the DAG downward toward the leaves, informing each successive receiving device how to reach the root device (that is, from where the request is received is generally the direction of the root). The DAG discovery reply (e.g., DAO) may then be returned from the leaves to the root device(s) (unless unnecessary, such as for UP flows only), informing each successive receiving device in the other direction how to reach the io leaves for downward routes.”) The citation discloses the root device/ first REST server, transmits the DAG discovery request/resource discovery message to the leaves before receiving the reply message from the leaves to the roots.
However, Pignataro does not explicitly teach the message comprising a particular resource type value. Therefore, by combining the teaching of Vasudevan, which teaches the message comprising a particular resource type value, with the teaching of Pignataro, which is the transmitting a resource discovery message, one with the ordinary skills in the art would be able to come up with the claim invention.
Both Tucker and Pignataro are in the same field of endeavor, and both references discloses the concept of computer networks, and therefore, are combinable/modifiable
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add further comprising: prior to receiving the resource message, the first REST server transmitting a resource discovery message comprising a particular resource type value, as taught in Pignataro’s invention into Tucker, KO, Tucker9901, and Vasudevan’s invention because by sending the resource discovery message that contains the resource type value before receiving the resource message from the receiver device, the sender device can notify the receiver about the type value of the resource in order to avoid the situation when the receiver receives the resource, but cannot perform the computational on the received resource.
Regarding claim 12, Tucker, in view of KO, Tucker9901, Vasudevan, and Pignataro, discloses the method of claim 10, and Tucker further teaches wherein transmitting the resource discovery message comprises transmitting the resource discovery message after producing the first output data corresponding to the first subset of operations. (Tucker - [0064]: “After devices are assigned to respective subgraphs, the devices perform operations of the respective subgraphs. Upon completing the operations, the devices can notify the system that the operations are complete or outputs of the operations, if any. The request received by the system can, in some cases, specify a response to include one or more outputs of particular nodes in the computational graph.”) The citation discloses after completing the operation, the device notify/transmit the resource discovery message.
Claims 11 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Tucker, KO, Tucker9901, Vasudevan, and Pignataro, in further view of Hsu Pub. No. US 20020141371 A1 (hereafter Hsu)
Regarding claim 11, Tucker, in view of KO, Tucker9901, Vasudevan, and Pignataro, discloses the method of claim 10, and Pignataro further teaches wherein transmitting the resource discovery message (Pignataro - [0044]: “Generally, a DAG discovery request (e.g., DIO) message is transmitted from the root device(s) of the DAG downward toward the leaves, informing each successive receiving device how to reach the root device”) The citation discloses the root device/first device transmits the DAG discovery request/resource discovery message to the leaves.
the resource message is transmitted by the second REST server in response to the resource discovery message (Pignataro - [0044]: “The DAG discovery reply (e.g., DAO) may then be returned from the leaves to the root device(s) (unless unnecessary, such as for UP flows only), informing each successive receiving device in the other direction how to reach the io leaves for downward routes.)”) The citation discloses the leave device/second device send the reply message/resource message to the roots in response to the DAG discovery request/resource discovery message.
However, Tucker, in view of KO, Tucker9901, Vasudevan, and Pignataro, fails to teach comprises multicasting the resource discovery message.
Hsu teaches multicasting the resource discovery message. (Hsu - [0096]: “destination address field uses a class-D multicast IP address.”)
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the multicasting the resource discovery message, as taught in Hsu’s invention into Tucker, KO, Tucker9901, Vasudevan, and Pignataro’s invention because using multicast IP addresses is the efficient use of network resources, minimizing network congestion and reducing the amount of duplicated data, since multicast address are designed for one-to-many communication, a single data packet can be sent from a sender to multiple recipients simultaneously.
Regarding claim 13, Tucker, in view of KO, Tucker9901, Vasudevan and Pignataro, discloses the method of claim 10, but fails to teach wherein receiving the resource message comprises receiving an IP packet transmitted by the second device, wherein the IP packet comprises: i) a header comprising an IP destination address and ii) a payload comprising the resource message, wherein the IP destination address is an IP multicast group address.
However, Hsu teaches the invention substantially as claimed: wherein receiving the resource message comprises receiving an IP packet transmitted by the second REST server, wherein the IP packet comprises: i) a header comprising an IP destination address (Hsu - [0096]: “The GRE packet is appended with the 20-byte IP packet header having a source address field identifying the IP address of the PDSN 1024, and destination address field”) the citation discloses the IP packet header contains the destination address field.
and ii) a payload comprising the resource message (Hsu - [0014] In another aspect, a communication signal transmitted via a carrier wave, having a payload portion corresponding to at least a portion of an Internet Protocol (IP) packet of digital information” and [0032]: “Attached to each frame of data (and each packet or message) is a header containing processing information that allows the receiver to understand the information contained in the frame(s) …… The information content is referred to as the payload.”) The citation discloses at [0032] that the payload is the information content filed and at [0014] discloses an IP packet contains a payload.
wherein the IP destination address is an IP multicast group address. (Hsu - [0096]: “destination address field uses a class-D multicast IP address.”)
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the receiving the resource message comprises receiving an IP packet transmitted by the second device, wherein the IP packet comprises: i) a header comprising an IP destination address, and ii) a payload comprising the resource message wherein the IP destination address is an IP multicast group address, as taught in Hsu’s invention into Tucker, KO, Tucker9901, Vasudevan, and Pignataro’s invention because using multicast IP addresses is the efficient use of network resources, minimizing network congestion and reducing the amount of duplicated data, since multicast address are designed for one-to-many communication, a single data packet can be sent from a sender to multiple recipients simultaneously.
Claims 14, 15, and 16 are rejected under 35 U.S.C. 103 as being unpatentable over Tucker, KO, Tucker9901, Vasudevan, Pignataro, in further view of Hong et al. US Pub. No. US 20160345283 A1 (hereafter Hong), and HONG et al. US Pub. No. US 20160218992 A1 (hereafter HONG)
Regarding claim 14, Tucker, in view of KO, Tucker9901, Vasudevan and Pignataro, disclose the method of claim 10, but do not explicitly teach wherein transmitting the resource discovery message comprises transmitting the resource discovery message toward a resource directory, and the resource message originated from the resource directory
However, Hong teaches: wherein transmitting the resource discovery message comprises transmitting the resource discovery message toward a resource directory (Hong - [0147]: “The AE sends a request message to the CSE1 for simplified registration, wherein a resource type parameter of the request message is set as an AE registration resource type”) The citation discloses the application entity(AE)/first device send/transmit the message to the CSE1/resource directory for registration/registration message that include the resource type.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the wherein transmitting the resource discovery message comprises transmitting the resource discovery message toward a resource directory, as taught in Hong’s invention into Tucker, KO, Tucker9901, Vasudevan, Pignataro’s invention because by providing registration message that contain the resource type value and the resource identifier corresponding to the output data, it helps to ensure the correct and appropriate output data is being registered and transferred toward the receiver node devices.
However, HONG teaches and the resource message originated from the resource directory (HONG - [0117]: “The resource directory generates a response message including a list of the IDs of the resources and node IP addresses.”) The citation discloses the resource directory generate a response message/the resource message.
It would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to add the resource message originated from the resource directory, as taught in HONG’s invention into Tucker, KO, Tucker9901, Vasudevan, Pignataro’s invention because by providing the resource directory as a middle man to validate the resource request from the client, it helps to ensure the correct resource or output data is transferred toward the requested node devices.
Regarding claim 15, Tucker, in view of KO, Tucker9901, Vasudevan, Pignataro, HONG, and Hong, discloses the method of claim 14, and Tucker further teaches wherein the first REST server generates the first output data after receiving the resource message, (Tucker - [0047]: “The system causes the devices to perform the operations of the nodes assigned to the devices (step 212). In some implementations, the system sends each device a request to start the operations. The device receives the request and in response, starts performing the operations of the nodes assigned to the device.”) The citations disclose the device stats performing the operations/generate the first output data after receive the request.
and the first REST server transmits the first output data toward the second REST server immediately after the first REST server generates the first output data. (Tucker - [0052]: “In some implementations, the system waits to assign the second subgraph 318 until receiving an indication that the operation represented by node 302 has completed. This allows the system to dynamically assign subgraphs based on current information, e.g., memory or device availability, which could improve efficiency. Upon receiving the indication, the system can assign the second subgraph 318 to a device capable of handling a size of the output of the node 302.”) The citation discloses when the operations at node 302/first device is completed, the output is transmitted to the second subgraph 318/second device for processing.
Regarding claim 16, Tucker, in view of Thambidorai, Li, Ng, Vasudevan, Pignataro, HONG, and Hong discloses the method of claim 14, and HONG further teaches: The method of claim 14, wherein the resource message is transmitted from the resource directory after the resource directory receives (HONG - [0117]: “The resource directory generates a response message including a list of the IDs of the resources and node IP addresses.”) The citation discloses the response message is generated and transmitted from the resource directory after.
(i) a resource registration message originated from the second REST server (HONG – FIG. 9 and [0115]: “Referring to FIG. 9, the client transmits, to the resource directory, a GET request, for example, a GET request message, including a resource type that the client desires to look up in the resource directory.”) The citations disclose the client/second device sends to the resource directory a GET request message/a resource discovery message, which is including the resource type/resource type value.
and the resource registration message includes the resource identifier identifying the first output data and a device identifier identifying the second REST server. (HONG – FIG. 9 and [0115]: “Referring to FIG. 9, the client transmits, to the resource directory, a GET request, for example, a GET request message, including a resource type that the client desires to look up in the resource directory.”) The citations disclose the client/second device sends to the resource directory a GET request message/a resource discovery message, which is including the resource type/resource type value.
and Hong further teaches and (ii) the resource discovery message originated from the first REST server, (Hong - [0147]: “The AE sends a request message to the CSE1 for simplified registration, wherein a resource type parameter of the request message is set as an AE registration resource type”) The citation discloses the application entity(AE)/first device send/transmit the message to the CSE1/resource directory for registration/registration message that include the resource type.
Allowable Subject Matter
Claims 3-5 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
US 20170124454 A1: Methods, systems, and apparatus, including computer programs encoded on computer storage media, for modifying a computational graph to include send and receive nodes. Communication between unique devices performing operations of different subgraphs of the computational graph can be handled efficiently by inserting send and receive nodes into each subgraph. When executed, the operations that these send and receive nodes represent may enable pairs of unique devices to conduct communication with each other in a self-sufficient manner.
US 20170132513 A1: Systems and Methods for training a neural network represented as a computational graph are disclosed. An example method begins with obtaining data representing a computational graph. The computational graph is then augmented to generate a training computational graph for training the neural network using a machine learning training algorithm that includes computing a gradient of an objective function with respect to each of the parameters of the neural network. Augmenting the computational graph includes inserting a plurality of gradient nodes and training edges into the computational graph to generate a backward path through the computational graph that represents operations for computing the gradients of the objective function with respect to the parameters of the neural network
US 10956500 B2: Methods, systems, and apparatus, including computer programs encoded on computer storage media, for efficiently processing dynamic length tensors of a machine learning model represented by a computational graph. A program is received that specifies a dynamic, iterative computation that can be performed on input data for processing by a machine learning model. A directed computational graph representing the machine learning model is generated that specifies the dynamic, iterative computation as one or more operations using a tensor array object. Input is received for processing by the machine learning model and the directed computational graph representation of the machine learning model is executed with the received input to obtain output.
Examiner has cited particular columns/paragraphs/sections and line numbers in the references applied and not relied upon to the claims above for the convenience of the applicant. Although the specified citations are representative of the teachings of the art and are applied to specific limitations within the individual claim, other passages and figures may apply as well. It is respectfully requested from the applicant in preparing responses, to fully consider the references in entirety 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.
When responding to the Office action, applicant is advised to clearly point out the patentable novelty the claims present in view of the state of the art disclosed by the reference(s) cited or the objections made. A showing of how the amendments avoid such references or objections must also be present. See 37 C.F.R. 1.111(c).
When responding to this Office action, applicant is advised to provide the line and page numbers in the application and/or reference(s) cited to assist in locating the appropriate paragraphs.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to TUAN M NGUYEN whose telephone number is (703)756-1599. The examiner can normally be reached Monday-Friday: 9:30am - 5:30PM ET.
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, Pierre Vital can be reached at (571) 272-4215. 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.
/TUAN M NGUYEN/ Examiner, Art Unit 2198
/PIERRE VITAL/Supervisory Patent Examiner, Art Unit 2198
Prosecution Insights