DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are:
“presetting module”, “graphical interface module” and editing and processing module” in claim 8.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof. According to Applicant’s disclosure in FIG.s 5 and 6, those modules are interpreted as a computer with software and/or hardware to implement their functions.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Objections
In claim 4, the phrase “in as operation templates” should be amended to “[[in]] as operation templates”, to correct the grammatical error.
Appropriate correction is required.
Claim Rejections - 35 USC § 102
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale or otherwise available to the public before the effective filing date of the claimed invention.
(a)(2) the claimed invention was described in a patent issued under section 151, or in an application for patent published or deemed published under section 122(b), in which the patent or application, as the case may be, names another inventor and was effectively filed before the effective filing date of the claimed invention.
Claim 1-4 and 8-9 are rejected under 35 U.S.C. 102(a)(1)) as being unpatentable over Kibbar (US 20150106153 A1, hereinafter as “Kibbar”).
Regarding claim 1, Kibbar teaches:
A workflow creation method, comprising :
storing preset behavior tree nodes (“steps”) in a node library ([0011]), the behavior tree nodes comprising main control nodes and function block nodes (FIG.s 4A and 4B), the main control nodes for controlling a running state of a workflow, the main control nodes comprising a start node (step 313 in FIG. 4B), an end node (step 350 in FIG. 4A), and a loop node, and each function block node (step 316 in FIG. 4B) operable for implementing operations of a resource in a workcell (workers in [0014]);
displaying the node library on a graphical user interface (GUI 14/16 in FIG. 1 and [0023-0024]; and [0011]);
receiving construction of a behavior tree and an instantiation configuration operation performed by a user on the graphical user interface based on the node library, the behavior tree representing a workflow used for defining operations to be executed by a workcell (FIG.s 4A and 4B, and [0011-0012]);
wherein construction of the behavior tree based on the node library comprises: connecting the start node, the function block nodes, and the end node sequentially, or, connecting the start node, the function block nodes, and the loop node sequentially (FIG.s 4A and 4B, and [0011-0012]); and
generating a behavior tree instance corresponding to a workflow in response to the construction of the behavior tree ([0017]).
Kibbar teaches specifically (underlines are added by Examiner for emphasis):
PNG
media_image1.png
542
754
media_image1.png
Greyscale
PNG
media_image2.png
604
450
media_image2.png
Greyscale
[0011] A workflow management application that applies an example of workflow compilation as described herein may provide a user interface for graphical definition of a workflow. A user may thus operate the graphical user interface so as to define the workflow in the form of steps. The workflow management application may include a library of types of steps and relationships among steps. For example, a user interface may enable a user to graphically select or manipulate screen objects that represent various types of steps for inclusion in the workflow.
[0012] A user interface of a workflow management application may further enable a user to define connections among the steps, e.g. by connecting the screen objects that represent the steps with a selected connector that represents a connection (e.g. sequence flow showing an order of execution, flow of a message or information, or other association). The user interface may enable a user to input data that characterizes a step or a connection.
[0014] Various defined steps of the workflow may be executed by different "workers," e.g. by different machines, by different execution modules within a single machine, or by various instances of programs or applications that are running on a single machine. In some examples of workflows, two or more steps may be executed in parallel while in others, steps are executed sequentially.
[0017] In accordance with examples of workflow compilation, a workflow is compiled to a representation that is referred to herein as an "execution plan". The execution plan includes a series of execution units. A single execution unit may represent a particular sub-operation or task of a step of the workflow. Compilation of the workflow may be performed by a compiler module of a workflow management system. Execution units of the workflow are selected from a limited library of execution units. The execution units in the library each represent a basic operation that could be combined into a step. A compiler module may analyze each step (or phase of a step) and identify the execution units that are to be executed in order to execute the step.
[0023] Processor 12 may communicate with output device 14. For example, output device 14 may include a computer monitor or screen. Processor 12 may communicate with a screen of output device 14 to display a result or progress of a managed workflow. Processor 12 may communicate with a screen of output device 14 to display elements of a user interface for enabling a user to define a workflow. In another example, output device 14 may include a printer, display panel, speaker, or another device capable of producing visible, audible, or tactile output.
[0024] Processor 12 may communicate with input device 16. For example, input device 16 may include one or more of a keyboard, keypad, or pointing device for enabling a user to inputting data or instructions for operation of processor 12, A user may operate input device 16 so as to define a workflow, or to initiate or control execution of a workflow.
Regarding claim 2, Kibbar teach(es) all the limitations of its base claim from which the claim depends.
Kibbar further teaches:
generating a behavior tree instance corresponding to a workflow comprises:
generating an instance of a main control node (FIG. 4B: adding start step 313 in the behavior tree); and
instantiating the function block node into operations to be executed by the corresponding resource based on the user's instantiation configuration operation (FIG. 4B and [0011-0012]: adding action step 316 in the behavior tree).
Regarding claim 3, Kibbar teach(es) all the limitations of its base claim from which the claim depends.
Kibbar further teaches:
after generating a behavior tree instance corresponding to a workflow, parsing the behavior tree instance, and deploying the workflow corresponding to the behavior tree instance to the runtime of a main controller of the corresponding workcell, so that the resources in the workcell connected to the main controller execute operations according to the workflow ([0014]: “Various defined steps of the workflow may be executed by different "workers," e.g. by different machines, by different execution modules within a single machine, or by various instances of programs or applications that are running on a single machine”).
Regarding claim 4, Kibbar teach(es) all the limitations of its base claim from which the claim depends.
Kibbar further teaches:
storing the function block nodes in the node library as operation templates , each function block node corresponding to one operation template, the operation template predefining the operations that can be executed by a class of resources, and the operations comprising actions, methods, or skills ([0011]: “The workflow management application may include a library of types of steps and relationships among steps”; and [0014]: “Various defined steps of the workflow may be executed by different "workers," e.g. by different machines, by different execution modules within a single machine, or by various instances of programs or applications that are running on a single machine”).
Claim 8 recites a workflow creation apparatus conducting operational steps of method in claim 1 with patentably the same limitations. Therefore, claim 8 is rejected for the same reason recited in the rejection of claim 1.
Regarding claim 9, Kibbar teach(es) all the limitations of its base claim from which the claim depends.
Kibbar further teaches:
at least one memory (memory 18 in FIG. 1) storing computer-readable code; and
at least one processor (processor 12 in FIG. 1) to call the computer-readable code to execute the method according to claim 1.
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.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Kibbar in view of Rits (US 20080282318 A1, hereinafter as “Rits”).
Regarding claim 7, Kibbar teach(es) all the limitations of its base claim from which the claim depends, but does not teach when generating a behavior tree instance corresponding to a workflow, adding labels unique in the behavior tree instance to all behavior tree nodes selected by a user, the labels comprising numbers, letters, or Chinese characters.
However, Rits teaches in an analogous art:
when generating a tree instance corresponding to a workflow, adding labels unique in the behavior tree instance to behavior tree nodes, the labels comprising numbers ([0011]: “A node in a tree may be associated with a label (such as a string or a number), e.g. specifying the position of the node in the tree”), letters, or Chinese characters.
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to have modified Kibbar based on the teaching of Rits, to make the method to further comprise when generating a behavior tree instance corresponding to a workflow, adding labels unique in the behavior tree instance to all behavior tree nodes selected by a user, the labels comprising numbers, letters, or Chinese characters. One of ordinary skill in the art would have been motivated to do this modification since it can help “specify[ing] the position of the node in the tree”, as Rits suggests in [0011].
Allowable Subject Matter
Claims 5-6 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 arts made of record and not relied upon are considered pertinent to applicant's disclosure.
Makhija (US 20220327006 A1): teaches a method to codelessly design a workflow.
Shukla (US 20060074735 A1): teaches to create a workflow through a GUI by connecting many work activity blocks.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to CHARLES CAI whose telephone number is (571)272-7192. The examiner can normally be reached on M-F 8-5 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, Kamini Shah can be reached on 571-272-2279. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of an application may be obtained from the Patent Application Information Retrieval (PAIR) system. Status information for published applications may be obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is available through Private PAIR only. For more information about the PAIR system, see http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative or access to the automated information system, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/CHARLES CAI/Primary Patent Examiner, Art Unit 2115
Prosecution Insights