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 Arguments
Applicant’s arguments have been considered but are moot because the new ground of rejection does not rely on any reference applied in the prior rejection of record for any teaching or matter specifically challenged in the argument.
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 (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 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, 3-8, 11 and 13-18 are rejected under 35 U.S.C. 103 as being unpatentable over “HipaccVX: Wedding of OpenVX and DSL-based Code Generation” by Ozkan et al. (Ozkan) in view of US 8,826,255 to Avadhanula et al. (Avadhanula) in view of US 2021/0382754 to Nimmagadda et al. (Nimmagadda).
Claims 1 and 11: Ozkan discloses:
receiving a graph application programming interface (API) call to add a control flow node to a main graph representing an image processing pipeline (see e.g. pg. 4, Listing 1), the graph API call identifying the node, wherein the main graph is an OpenVX graph (see e.g. pg. 4, Fig. 2, pg. 2, col. 1, 1st full par. “OpenVX”);
compiling, by a graph compiler, the main graph into executable code (pg. 5, par. bridging the cols. “compiled with the target architecture compiler”); and
executing, by one or more target devices, the executable code to perform operations of the image processing pipeline (pg. 4, col. 1, last full par. “A verified graph can be executed”).
Ozkan does not disclose:
receiving a graph API call to add a control flow node representing a while loop to a main graph, the graph API call identifying the control flow node, a condition subgraph for evaluating a condition based on a state, and a body subgraph for updating the state and generating an output;
evaluating the condition iteratively according to the executable code of the condition subgraph and executing the executable code of the body subgraph until the condition is evaluated to be false.
Avadhanula teaches:
a control flow node representing a while loop (col. 7, lines 1-12 “structured loop”, also see col. 7, lines 19-29 “WHILE loop”, Fig. 1D), a condition subgraph for evaluating a condition based on a state (col. 7, lines 1-12 “CONDITION node 186”, Fig. 1D, Cond 186), and a body subgraph for updating the state and generating an output (col. 7, lines 1-12 “block of code 182”, Fig. 1D R 182);
evaluating the condition iteratively according to the executable code of the condition subgraph and executing the executable code of the body subgraph until the condition is evaluated to be false (col. 7, lines 1-12 “If the condition is satisfied, the flow of control proceeds to block of code 182”).
It would have been obvious before the effective filing date of the claimed invention to have an API call to add a node representing a wile loop. Those of ordinary skill in the art would have been motivated to do so as a known control structure which would have produced only the expected results.
Ozkan and Avadhanula do not explicitly teach:
a graph API call identifying a condition subgraph and a body subgraph.
OpenVX teaches:
a graph API call identifying a subgraph (see pg. 195, vxProcessGraph “vx_graph graph”).
It would have been obvious before the effective filing date of the claimed invention to identify condition and body subgraphs in a graph API call. Those of ordinary skill in the art would have been motivated to do so as known means of indicating a condition node should be added to the graph which would have produced only the expected results.
Ozkan, Avadhanula and OpenVX do not explicitly teach one or more target devices in an artificial intelligence (AI) processing unit.
Nimmagadda teaches
one or more target devices in an artificial intelligence (AI) processing unit (par. [0019] “a hardware accelerator such as a vision processing unit (VPU) (or another type of hardware AP accelerator)”).
It would have been obvious at the time of filing to execute the code on a AI processing unit. Those of ordinary skill in the art would have been motivated to do so for the improved performance.
Claim 3 and 13: Ozkan, Avadhanula and Nimmagadda teach claims 1 and 11, further comprising:
receiving a second graph API to add a second control flow node to the main graph (Fig. 1A, at least obvious to add an “IF” node if the associated processing is desired); and
evaluating an if-condition at runtime at the second control flow node to determine which one of conditional branches to execute (Avadhanula col. 5, lines 55-61 “depending on the value of the conditional expression … control may flow to trueRegion 104 or falseRegion 114”).
Claim 4 and 14: Ozkan, Avadhanula and Nimmagadda teach claims 3 and 13, wherein the conditional branches correspond to a then_graph and an else_graph (Avadhanula col. 5, lines 55-61 “depending on the value of the conditional expression … control may flow to trueRegion 104 or falseRegion 114”).
Claims 5 and 15: Ozkan, Avadhanula and Nimmagadda teach claims 1 and 11, further comprising:
receiving a second graph API to add a second control flow node to the main graph (Fig. 1B); and
evaluating a switch-condition at runtime at the second control flow node to determine which one of conditional branches to execute, wherein different ones of the conditional branches correspond to different outcomes of the switch-condition (Avadhanula col. 6, lines 11-30 “CASE node 130 has three conditions, with flow of control passing to one of regions 134, 144 or 154, depending on satisfaction of one of the conditions”).
Claim 6 and 16: Ozkan, Avadhanula and Nimmagadda teach claims 1 and 11, wherein evaluating the condition comprises:
determining whether the loop terminates by evaluating a condition node that follows the control flow node (Avadhanula Fig. 1C, R 162, Cond 166).
Claims 7 and 17: Ozkan, Avadhanula and Nimmagadda teach claims 1 and 11, wherein the condition is evaluated by comparing a constant with the state (Avadhanula Fig. 12C “if ((Boolean_T)c1 !=0”).
Claims 8 and 18: Ozkan, Avadhanula and Nimmagadda teach claims 1 and 11, both the condition subgraph and the body subgraph are attached to the control flow node (Avadhanula Fig. 1D Merge 180).
Claims 10 and 20 are rejected under 35 U.S.C. 103 as being unpatentable over “HipaccVX: Wedding of OpenVX and DSL-based Code Generation” in view of US 8,826,255 to Avadhanula et al. (Avadhanula) in view of US 2021/0382754 to Nimmagadda et al. (Nimmagadda) in view of US 2022/0375033 to Suzuki et al. (Suzuki).
Claims 10 and 20: Ozkan, Avadhanula and Nimmagadda teach claims 1 and 11, but do not explicitly teach wherein the body subgraph includes a node corresponding to operations of a multi-layered neural network model.
Suzuki teaches image processing including operations of a multi-layered neural network model (par. [0036] “multi-layer neural network used of image processing”).
It would have been obvious at the time of filing to include a node corresponding to operations of a multi-layered neural network model. Those of ordinary skill in the art would have been motivated to do so as a standard means of processing images which would have produced only the expected results.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JASON D MITCHELL whose telephone number is (571)272-3728. The examiner can normally be reached Monday through Thursday 7:00am - 4:30pm and alternate Fridays 7:00am 3:30pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Lewis Bullock can be reached at (571)272-3759. 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.
/JASON D MITCHELL/Primary Examiner, Art Unit 2199