CTNF 18/657,062 CTNF 87538 DETAILED ACTION Claims 1-20 are pending. 07-03-aia AIA 15-10-aia The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA. Examiner’s Notes Examiner has cited particular columns and line numbers, paragraph numbers, or figures 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 from the applicant, in preparing the 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. Claim Rejections - 35 USC § 112 07-30-02 AIA 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. 07-34-01 Claim 5 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. 07-34-05 AIA Claim 5 recites the limitation " generating a response to the query based on the first container and/or the second container " in lines 4-5 . There is insufficient antecedent basis for this limitation in the claim. Claim Rejections - 35 USC § 103 07-06 AIA 15-10-15 In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status. 07-20-aia AIA 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. 07-21-aia AIA Claim (s) 1-20 are rejected under 35 U.S.C. 103 as being unpatentable over Gupta et al. (US-PGPUB-NO: 2022/0058005 A1) hereinafter Gupta, in further view of Koneru et al. (US-PGPUB-NO: 2019/0235917 A1) hereinafter Koneru . As per claim 1, Gupta teaches an operating method of an electronic device, the operating method comprising: generating, based on a hardware representation of a target device, a mapping, by mapping hardware components represented in the hardware representation of the target device to one or more hardware-component traits and to one or more drivers (see Gupta paragraph [0046], “In addition to forming a streaming network, the interconnect 205 may include a separate network for programming or configuring the hardware elements in the DPE 110. Although not shown, the interconnect 205 may include a memory mapped interconnect which includes different connections and switch elements used to set values of configuration registers in the DPE 110 that alter or set functions of the streaming network, the core 210, and the memory module 230”) ; wherein the hardware representation comprises representations of the hardware components tagged with the one or more hardware-component traits and representations of the one or more drivers and a hierarchical structure between the hardware components (see Gupta paragraph [0087], “FIG. 9 is an abstract view of implementing the dataflow graph 440 in FIG. 7, according to an example. FIG. 9 illustrates the kernels a-f as well as the communication links 620. Further, FIG. 9 illustrates the hardware on which the kernels are assigned in the SoC. As shown, the kernels a and f are disposed in the PL 125, the kernels b and c are implemented in the DPE 110A, and the kernels d and e are implemented in the DPE 110B”) . Gupta does not explicitly teach generating, based on the hardware representation, topology information representing a connection relationship and dependency between the hardware components of the target device represented in the hardware representation. However, Koneru teaches generating, based on the hardware representation, topology information representing a connection relationship and dependency between the hardware components of the target device represented in the hardware representation (see Koneru paragraph [0076], “For an embodiment, each node is processed at a depth, which can be represented by an acyclic graph. For an acyclic graph as represented by the complex dependent graph 200, a node is dependent only on nodes at a lower (that is, dispatched earlier in time from a previous stage) or same depth (dispatched earlier in time but from the same stage) In an embodiment, the topology comprises of nodes, data buffers, command buffers and constants buffers. Data buffers store data while command buffers store an index to the data buffer. In an embodiment, each node receives data from a data buffer and writes the results of the execution in another data buffer. Thus, data buffers are connected at the input and output of each node”). Gupta and Koneru are analogous art because they are in the same field of endeavor of software development. Therefore, it would have been obvious to one of ordinary skills in the art before the effective filing date of the claimed invention to modify Gupta’s teaching of generating dataflow graphs using source code for defining kernels and communication links between those kernels with Koneru’s teaching of scheduling threads comprising of code blocks in a graph streaming processor system to incorporate topology information between nodes in order to better interpret links between kernels/threads and dependencies between the kernels/threads. As per claim 2, Gupta modified with Koneru teaches wherein the one or more hardware-component traits indicate software executable by the hardware components (see Gupta paragraph [0109], “Returning to the method 500, a control program controls the execution of the dataflow graph on the SoC. That is, once the kernels and communication links have been assigned to the various hardware components and configured as illustrated in FIG. 10, the control program can provide instructions to the SoC for controlling the execution of the graph. As mentioned above, the control program can execute on a host computing system (as may be preferably in a datacenter) or within the PS of the SoC. In one embodiment, the control program is compiled using control source code”) . As per claim 3, Gupta modified with Koneru teaches wherein the one or more hardware-component traits are included in a first set in which traits of standardized hardware components are standardized (see Gupta paragraph [0064], “For example, the graph source code 420 can include a first plurality of kernels which the compiler assigns to a first chip (e.g., a SoC, FPGA, etc.)”) , the one or more drivers are included in a second set in which operations performable by the standardized hardware components are standardized (see Gupta paragraph [0064], “a second plurality of kernels the compiler assigns to a second chip”) , and wherein combinations of operations of the respective drivers in the second set are included in a third set (see Gupta paragraph [0064], “The first and second plurality of kernels can be part of the same dataflow graph, and as such, may communicate with each other when executed on the first and second chips”) . As per claim 4, Gupta modified with Koneru teaches wherein the mapping comprises a first mapping table mapping between the one or more hardware- component traits and the hardware components (see Gupta paragraph [0075], “The source code 420 also includes constraints 615 which include instructions to limit how the compiler maps the objects defined in the source code 420 (e.g., the kernels 605 and the communication links 620) to the hardware in the SoC”) and a second mapping table mapping between the one or more drivers and the hardware components (see Gupta paragraph [0140], “Advantageously, the compiler 435 can configure drivers 1910, registers, and other hardware in the SoC 100 so that the APIs 1905 can perform the desired function. For example, the drivers 1910 may be used to perform a DMA to read data in DDR memory in the SoC 100 into one of the DPEs 110 executing a kernel in the dataflow graph 440”) . As per claim 5, Gupta modified with Koneru teaches further comprising: receiving a query about the hardware components from a compiler compiling a target application to execute on the target device; generating a response to the query based on the first container and/or the second container (see Gupta paragraph [0082], “FIG. 8 is kernel source code 425 for defining a kernel in a dataflow graph, according to an example. In one embodiment, the wrapper 610 in the source code in FIG. 6 permits the arguments of the function defined by the kernel to be accessed as ports. In FIG. 8, the kernel source code 425 includes arguments 805 that specify a pointer (i.e., *inputw) to the input data and a pointer (*outputw) to the output data. When two kernels are communicatively coupled by a link as described above, the compiler can allocate data memory which is supplied to the kernel (or the function called by the kernel) when the kernel is called. In one embodiment, the kernel operates on the input data provided by the arguments 805 using an application programming interface (API)”) ; transmitting the response to the compiler; and optimizing, by the compiler, the compiling of the target application to execute on the target device based on the response (see Gupta paragraph [0085], “Returning to the method 500, at block 510 the compiler compiles the source code (e.g., the graph, kernel, and control source code). For ease of explanation, this compilation is divided into at least three sub-blocks. At block 515, the compiler assigns the kernels to the DPEs and programmable logic in the SoC. The compiler can use constraints provided by the programmer in the source code (e.g., the constraints 615 in FIG. 6), but absent constraints, can assign the kernels in the graph source code to the DPEs and the programmable logic in the SoC”) . As per claim 6, Gupta modified with Koneru teaches wherein the query is either a query regarding whether one of the hardware components comprises a predetermined hardware-component trait, a query regarding whether one of the hardware components comprises a predetermined driver, or a query regarding whether one of the hardware components is included in a predetermined topology (see Gupta paragraph [0085], “Returning to the method 500, at block 510 the compiler compiles the source code (e.g., the graph, kernel, and control source code). For ease of explanation, this compilation is divided into at least three sub-blocks. At block 515, the compiler assigns the kernels to the DPEs and programmable logic in the SoC. The compiler can use constraints provided by the programmer in the source code (e.g., the constraints 615 in FIG. 6), but absent constraints, can assign the kernels in the graph source code to the DPEs and the programmable logic in the SoC”) . As per claim 7, Gupta modified with Koneru teaches wherein the generating the response to the query is based on the mapping, which comprises a first mapping table mapping between the one or more hardware-component traits and the hardware components, a second mapping table comprising mapping information between the one or more drivers and the hardware components, or the hardware representation, which comprises the topology information (see Gupta paragraph [0086], “In one embodiment, the compiler evaluates the graph to determine how to assign the kernels to the hardware in the SoC. For example, if two kernels are communicatively coupled to each other in the graph, the compiler may assign the kernels to neighboring DPEs in the DPE array to take advantage of faster communication protocol such as shared memory between the DPEs. Further, the compiler may determine the cycle count and the fraction of time used by each of the kernels to determine whether multiple kernels can be assigned to the same DPE”) . As per claim 8, Gupta modified with Koneru teaches wherein the generating mapping and the topology information is performed based on compiling a target application for execution on the target device, and wherein the compiling optimizes the target application to execute on the target device based on the mapping and topology information (see Gupta paragraph [0115], “User-defined constraints are external constraints since they are generated by the programmer rather than the compiler when compiling the source code for implementation on the SoC. In one embodiment, the number of external constraints provided by the programmer may vary depending on the intelligence of the compiler. If the compiler has internal constraints that result in well-optimized implementations of the dataflow graph, the programmer may choose to provide few constraints. Thus, the capabilities of the compiler can affect the number of external constraints the programmer decides to use. As newer more intelligent versions of the compiler become available, the programmer may provide fewer constraints”) . As per claim 9, Gupta modified with Koneru teaches an operating method of an electronic device, the operating method comprising: receiving a target application and a hardware representation of a target device (see Gupta paragraph [0075], “The source code 420 also includes constraints 615 which include instructions to limit how the compiler maps the objects defined in the source code 420 (e.g., the kernels 605 and the communication links 620) to the hardware in the SoC”) ; generating a query on mapping tables and/or topology information, by a compiler; and compiling, by the compiler, the target application to execute on the target device based on a response to the query (see Gupta paragraph [0075], “In this example, the constraints 615 instruct the compiler to assign the kernels a and f to the fabric (e.g., the programmable logic) in the SoC rather than assigning these kernels to a DPE. For reasons described below, assigning the kernels a and f to the fabric rather than the DPEs can offer performance improvement. Thus, while the graph source code 420 does not require the programmer to assign the kernels 605 to the hardware in the SoC (and thus the programmer does not need to understand the underlying hardware architecture of the SoC), the namespace provided to the programmer permits her to use the constraints 615 to instruct the compiler how to assign one or all of the kernels 605 if the programmer knows doing so improves performance”) , wherein the mapping tables are based on the hardware representation and indicate which hardware components included in the target device are mapped to (i) which hardware-component traits and to (ii) which drivers (see Gupta paragraph [0140], “Advantageously, the compiler 435 can configure drivers 1910, registers, and other hardware in the SoC 100 so that the APIs 1905 can perform the desired function. For example, the drivers 1910 may be used to perform a DMA to read data in DDR memory in the SoC 100 into one of the DPEs 110 executing a kernel in the dataflow graph 440. While the drivers 1910 are illustrated as part of the PS 130, in other in other embodiments, the drivers 1910 could be implemented using controllers in the PL 125 or through control signals transmitted to the SoC 100 from a remote controller using a network”) , and the topology information is based on the hardware representation and indicates a connection relationship and dependency between the hardware components (see Koneru paragraph [0076], “For an embodiment, each node is processed at a depth, which can be represented by an acyclic graph. For an acyclic graph as represented by the complex dependent graph 200, a node is dependent only on nodes at a lower (that is, dispatched earlier in time from a previous stage) or same depth (dispatched earlier in time but from the same stage) In an embodiment, the topology comprises of nodes, data buffers, command buffers and constants buffers. Data buffers store data while command buffers store an index to the data buffer. In an embodiment, each node receives data from a data buffer and writes the results of the execution in another data buffer. Thus, data buffers are connected at the input and output of each node”) . As per claim 10, Gupta modified with Koneru teaches wherein the hardware representation comprises the hardware components tagged with the hardware-component traits and the drivers and a hierarchical structure between the hardware components (see Gupta paragraph [0087], “FIG. 9 is an abstract view of implementing the dataflow graph 440 in FIG. 7, according to an example. FIG. 9 illustrates the kernels a-f as well as the communication links 620. Further, FIG. 9 illustrates the hardware on which the kernels are assigned in the SoC. As shown, the kernels a and f are disposed in the PL 125, the kernels b and c are implemented in the DPE 110A, and the kernels d and e are implemented in the DPE 110B”) . As per claim 11, Gupta modified with Koneru teaches wherein the hardware-component traits indicate software executable by the hardware components (see Gupta paragraph [0109], “Returning to the method 500, a control program controls the execution of the dataflow graph on the SoC. That is, once the kernels and communication links have been assigned to the various hardware components and configured as illustrated in FIG. 10, the control program can provide instructions to the SoC for controlling the execution of the graph. As mentioned above, the control program can execute on a host computing system (as may be preferably in a datacenter) or within the PS of the SoC. In one embodiment, the control program is compiled using control source code”) . As per claim 12, Gupta modified with Koneru teaches wherein the hardware-component traits are included in a first set in which traits of the hardware components are standardized (see Gupta paragraph [0064], “For example, the graph source code 420 can include a first plurality of kernels which the compiler assigns to a first chip (e.g., a SoC, FPGA, etc.)”) , the drivers are included in a second set in which operations performable by the standardized hardware components are standardized (see Gupta paragraph [0064], “a second plurality of kernels the compiler assigns to a second chip”) , and an indication of a combination of operations of the respective drivers in the second set are included in a third set (see Gupta paragraph [0064], “The first and second plurality of kernels can be part of the same dataflow graph, and as such, may communicate with each other when executed on the first and second chips”) . As per claims 13-20, these are the electronic device claims to method claims 1-8, respectively. Therefore, they are rejected for the same reasons as above . Conclusion 07-96 AIA The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Zhao et al. (US-PGPUB-NO: 2020/0133735 A1) teaches assigning tasks to dedicated processing resources. Brady et al. (US-PGPUB-NO: 2019/0392296 A1) teaches hardware agnostic deep neural network compiler. S. (US-PGPUB-NO: 2019/0122415 A1) teaches graph based heterogeneous parallel processing system. Roy et al. (US-PGPUB-NO: 2018/0341493 A1) teaches machine intelligence and learning for graphic chip accessibility and execution. Any inquiry concerning this communication or earlier communications from the examiner should be directed to LENIN PAULINO whose telephone number is (571)270-1734. The examiner can normally be reached Week 1: Mon-Thu 7:30am - 5:00pm Week 2: Mon-Thu 7:30am - 5:00pm and Fri 7:30am - 4:00pm EST. 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, Bradley Teets can be reached at (571) 272-3338. 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. /LENIN PAULINO/Examiner, Art Unit 2197 Application/Control Number: 18/657,062 Page 2 Art Unit: 2197 Application/Control Number: 18/657,062 Page 3 Art Unit: 2197 Application/Control Number: 18/657,062 Page 5 Art Unit: 2197 Application/Control Number: 18/657,062 Page 6 Art Unit: 2197 Application/Control Number: 18/657,062 Page 7 Art Unit: 2197 Application/Control Number: 18/657,062 Page 8 Art Unit: 2197 Application/Control Number: 18/657,062 Page 10 Art Unit: 2197 Application/Control Number: 18/657,062 Page 11 Art Unit: 2197 Application/Control Number: 18/657,062 Page 12 Art Unit: 2197 Application/Control Number: 18/657,062 Page 13 Art Unit: 2197 Application/Control Number: 18/657,062 Page 14 Art Unit: 2197
Prosecution Insights