DETAILED ACTION
This final Office action is responsive to amendments filed July 21st, 2026. Claims 1-2, 4-5, and 7-11 have been amended. Claims 3 and 6 have been cancelled. Claims 1-2, 4-5, and 7-11 are presented for examination.
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 .
Priority
Receipt is acknowledged of certified copies of papers required by 37 CFR 1.55.
Response to Arguments
Applicants’ arguments, see page 6, filed 07/21/26, with respect to claims 1-9 have been fully considered and are persuasive. The claim objections of 04/21/26 has been withdrawn.
Applicants’ arguments regarding 35 USC 112(f) interpretation filed 07/21/26 have been fully considered but they are not persuasive.
On pages 6-7 of the provided remarks, Applicant argues that amended claim 1 has overcome these defects through corresponding modifications to the claim language. Beginning on page 6 of the provided remarks, Applicant argues “as a matter of law, when a claim does not use the term "means," there is a rebuttable presumption that 35 U.S.C. § 112(f) does not apply. The Examiner must provide sufficient evidence to rebut this presumption.” Examiner respectfully disagrees and asserts, per MPEP 2181(I)(A), “When the claim limitation does not use the term "means," examiners should determine whether the presumption that 35 U.S.C. 112(f) does not apply is overcome. The presumption may be overcome if the claim limitation uses a generic placeholder (a term that is simply a substitute for the term "means"). The following is a list of non-structural generic placeholders that may invoke 35 U.S.C. 112(f): "mechanism for," "module for," "device for," "unit for," "component for," "element for," "member for," "apparatus for," "machine for," or "system for." Welker Bearing Co., v. PHD, Inc., 550 F.3d 1090, 1096, 89 USPQ2d 1289, 1293-94 (Fed. Cir. 2008); Mass. Inst. of Tech. v. Abacus Software, 462 F.3d 1344, 1354, 80 USPQ2d 1225, 1228 (Fed. Cir. 2006); Personalized Media, 161 F.3d at 704, 48 USPQ2d at 1886–87; Mas-Hamilton Group v. LaGard, Inc., 156 F.3d 1206, 1214-1215, 48 USPQ2d 1010, 1017 (Fed. Cir. 1998).” As seen within amended claim 1, the “workflow modules” are analogous to the listed generic placeholder “module for” and therefore invokes the application of 35 USC 112(f) interpretation. Applicants’ arguments are not persuasive.
Continuing on pages 6-7 of the provided remarks, Applicant argues, “in the field of computer science, "module" has a well-recognized structural meaning-it is an independently deployable software unit that encapsulates data and functionality. A person of ordinary skill in the art would clearly understand its structure and boundaries.” Examiner respectfully disagrees and cites, MPEP 2181(I)(C), “Examiners will apply 35 U.S.C. 112(f) to a claim limitation that uses the term "means" or generic placeholder associated with functional language, unless that term is (1) preceded by a structural modifier, defined in the specification as a particular structure or known by one skilled in the art, that denotes the type of structural device (e.g., "filters"), or (2) otherwise modified by sufficient structure or material for achieving the claimed function.” While Applicant argues that the term module has a well-recognized structural meaning as an independently deployable software unit, amended claim 1 recites “a plurality of workflow modules” within sufficient structure to perform the argued module functions. Additionally, the specification does not state that the argued modules operate independently as argued by Applicant. Previously cited paragraph [0077] recites the use of a computing unit to perform the argued construction of the workflow modules, and therefore the claim is lacking the structure necessary to perform the claimed functions. Applicants’ arguments are not persuasive.
Finally, on page 7 of the provided remarks, Applicant argues, “the specification has described in detail its specific implementation: constructed based on node configuration content, subjected to legality checks, and loaded with operation code. These disclosures are sufficient to support its structural features.” Examiner respectfully disagrees and asserts that the above argued specific implementation does not present “structural features” as argued by Applicant. Additionally, per MPEP 2181(I) “Application of 35 U.S.C. 112(f) is driven by the claim language, not by applicant’s intent or mere statements to the contrary included in the specification or made during prosecution. See In re Donaldson Co., 16 F.3d at 1194, 29 USPQ2d at 1850 (stating that 35 U.S.C. 112, sixth paragraph "merely sets a limit on how broadly the PTO may construe means-plus-function language under the rubric of reasonable interpretation’").” Therefore, the 35 USC 112(f) interpretation of claims 1-2 and 4-5 is maintained. Applicants’ arguments are not persuasive.
Applicants’ arguments regarding claim rejections under 35 USC 103 filed 07/21/26 have been fully considered but they are not persuasive.
On pages 7-9 of the provided remarks, Applicant argues that the cited prior art does not disclose the claimed limitations. Beginning on page 7 of the provided remarks, Applicant argues that the primary and secondary references solve different technical problems than the present application. Examiner respectfully disagrees and asserts, paragraph [0004], “there is an urgent need to provide an operation workflow generation method so that operation functional services can be quickly generated and efficiently organized and orchestrated, reducing the complexity of workflow construction and improving user experience”. This is analogous to paragraph [0012] of argued Hatanaka “With this type of system, the configuration of the workflow modules can be done without requiring the configuration pages for an administration console to be designed specifically for a workflow module.” This is further analogous to argued Werner use of workflow management services which may lead toward greater cost savings and/or more efficient use of development resources for application providers within [Col 1 lines 35-40]. Further, while Applicant has argued that the different technical problems present a lack of motivation to combine the references listed above, citing MPEP 2143.01, “A "motivation to combine may be found explicitly or implicitly in market forces; design incentives; the ‘interrelated teachings of multiple patents’; ‘any need or problem known in the field of endeavor at the time of invention and addressed by the patent’; and the background knowledge, creativity, and common sense of the person of ordinary skill." Zup v. Nash Mfg., 896 F.3d 1365, 1371, 127 USPQ2d 1423, 1427 (Fed. Cir. 2018) (quoting Plantronics, Inc. v. Aliph, Inc., 724 F.3d 1343, 1354 [107 USPQ2d 1706] (Fed. Cir. 2013) (citing Perfect Web Techs., Inc. v. InfoUSA, Inc., 587 F.3d 1324, 1328 [92 USPQ2d 1849] (Fed. Cir. 2009) (quoting KSR, 550 U.S. at 418-21))” Therefore, the technical problem argument is not the sole motivation to combine rationale and as stated above, the cited references provide not only interrelated teachings but also similar problems in the field of workflow configuration. Applicants’ arguments are not persuasive.
Applicant continues on pages 7-9 of the provided remarks to argue the cited Sun (U.S 2007/0094211 A1) in relation to the amended claim limitations. However, Applicants’ argument is moot as the argued Sun was not cited to disclose the previously amended limitations of claims 3 and 6 now found in amended claim 1. Further, regarding the motivation to combine the argued references, Examiner looks to the above argument regarding the rationale for motivation to combine the cited references. The 35 USC 103 rejection is maintained. Applicants’ arguments are not persuasive.
Applicants’ arguments regarding claim rejections under 35 USC 101 filed 07/21/26 have been fully considered but they are not persuasive.
On pages 9-10 of the provided remarks, Applicant argues that the amended claims present statutory subject matter. Beginning on page 9 of the provided remarks, Applicant argues that the amended claims are not directed to an abstract idea. Specifically, Applicant argues that the amended technical ends provides “a clear end-to-end information transfer relationship among the three ends – the framework flows from the platform end to the development end, and the functional services flow from the development end to the manipulating end”. Examiner respectfully disagrees and asserts that the functional services provided by the technical ends argued recite the abstract idea of both certain methods of organizing human activity as well as mental process. Further, the argued “three different technical ends” are recited with a high-level of generality as mere elements of the claimed processor and are described in paragraph [0079] of the as-filed Specification as, “the specific functions implemented by the memory 520 and the processor 510 of the device 500 for generating an operation workflow provided in the Detailed Description of the specification may be explained in comparison with the aforementioned Detailed Description in the specification, and can achieve the technical effects of the aforementioned Detailed Description”. Per MPEP 2106.04(a)(2)(III)(C) “In evaluating whether a claim that requires a computer recites a mental process, examiners should carefully consider the broadest reasonable interpretation of the claim in light of the specification. For instance, examiners should review the specification to determine if the claimed invention is described as a concept that is performed in the human mind and applicant is merely claiming that concept performed 1) on a generic computer, or 2) in a computer environment, or 3) is merely using a computer as a tool to perform the concept.” Examiner asserts that the argued “different technical ends” are merely using the computer as a tool to perform the concept. Applicants’ arguments are not persuasive.
Applicant continues on pages 9-10 of the provided remarks to argue that the three-tier architecture presents a specific improvement to the architecture of a computer workflow generation system. On page 10 of the provided remarks, Applicant argues “this architecture design changes the collaborative relationships and organizational manner among functional modules in the workflow generation system, and decomposes the workflow generation tasks traditionally undertaken by a single system into collaborative work of three independent technical ends”. Examiner respectfully disagrees and begins by asserting that the argued tiered architecture design is not an improvement to the architecture of a computer workflow generation system. As cited above, the support regarding the configuration of the computer workflow generation system into a three-tiered system merely recites, per paragraph [0079] “the specific functions implemented by the memory 520 and the processor 510 of the device 500 for generating an operation workflow provided in the Detailed Description of the specification may be explained in comparison with the aforementioned Detailed Description in the specification, and can achieve the technical effects of the aforementioned Detailed Description”. The argued improvement to the configuration of a computer is not detailed or specified by the Specification. Per MPEP 2106.05(a), “If it is asserted that the invention improves upon conventional functioning of a computer, or upon conventional technology or technological processes, a technical explanation as to how to implement the invention should be present in the specification. That is, the disclosure must provide sufficient details such that one of ordinary skill in the art would recognize the claimed invention as providing an improvement.” As Applicant’s disclosure does not provide technical explanation regarding the tiered configuration or an explanation of argued improvement, Examiner maintains that the claims are directed to an abstract idea. Applicants’ arguments are not persuasive.
Finally, on page 10 of the provided remarks, Applicant argues that claims solve a specific problem in the computer technology field. Specifically, Applicant argues the division of three independent technical ends and information transfer among the ends “reducing system coupling through separation of responsibilities, allowing each end to operate and optimize independently”. Examiner respectfully disagrees and asserts, citing MPEP 2106.05(a) “An indication that the claimed invention provides an improvement can include a discussion in the specification that identifies a technical problem and explains the details of an unconventional technical solution expressed in the claim, or identifies technical improvements realized by the claim over the prior art.” Looking to the as-filed Specification, the following is listed as the aforementioned technical problem, per paragraph [0004] “In view of this, there is an urgent need to provide an operation workflow generation method so that operation functional services can be quickly generated and efficiently organized and orchestrated, reducing the complexity of workflow construction and improving user experience.” Therefore, the argued “reducing of system coupling” and tiered architecture improvement of Applicant is not aligned with the presented technical problem of the as-filed Specification. Additionally, as stated above, the argued tiered architecture does not present a technical improvement to computer system. The 35 USC 101 rejection is maintained. Applicants’ arguments are not persuasive.
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 following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
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: workflow module in claims 1-2 and 4-5.
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.
When looking to the specification, the hardware structure associated with the “workflow module” is being interpreted as “computing unit,” please see at least Fig. 5 and [0077] of the instant specification. The corresponding algorithm of the “workflow module” can be found in at least Fig. 5 and corresponding paragraphs [0077]. This is to be the structure and algorithm required for the claim, or equivalents thereof.
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 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 1-2, 4-5, and 7-9 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.
Amended claim 1 recites the following elements, “platform development end”, “operation development end”, and “operation manipulating end”. However, it is unclear to Examiner whether the various ends are operating as structure or mere execution/order steps of the claimed method. The as-filed Specification does not link the claimed ends to the claimed structure listed and supported within Figure 5. Examiner requests clarification and support for the intended application of the claimed “platform development end”, “operation development end”, and “operation manipulating end”. In the interest of furthering prosecution, the claimed elements are interpreted as execution order of the claimed method. Dependent claims 2, 4-5, and 7-9 are rejected due to their dependency on independent claim 1.
Claim Rejections - 35 USC § 101
35 U.S.C. 101 reads as follows:
Whoever invents or discovers any new and useful process, machine, manufacture, or composition of matter, or any new and useful improvement thereof, may obtain a patent therefor, subject to the conditions and requirements of this title.
Claims 1-2, 4-5, and 7-11 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter;
When considering subject matter eligibility under 35 U.S.C. 101, it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter. If the claim does fall within one of the statutory categories, it must then be determined whether the claim is directed to a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea), and if so, it must additionally be determined whether the claim is a patent-eligible application of the exception. If an abstract idea is present in the claim, any element or combination of elements in the claim must be sufficient to ensure that the claim amounts to significantly more than the abstract idea itself.
Step 1: Independent claims 1 (method), 10 (device), and 11 (non-transitory machine-readable medium) and dependent claims 2, 4-5, and 7-9, respectively, fall within at least one of the four statutory categories of 35 U.S.C. 101: (i) process; (ii) machine; (iii) manufacture; or (iv) composition of matter. Claim 1 is directed to a method (i.e. process), claim 10 is directed to a device (i.e. machine), and claim 11 is directed to a non-transitory machine-readable medium (i.e. manufacture).
Step 2A Prong 1: The independent claims recite generating an operation workflow, the method comprising: at a platform development end, i) acquiring a workflow configuration content; ii) constructing a plurality of workflow modules based on node configuration contents in the workflow configuration content; iii) combining each workflow module, based on a workflow description in the workflow configuration content, to obtain an execution workflow framework; and at an operation development end, i) loading an operation code for each workflow module in the execution workflow framework, based on the execution workflow framework and operation contents, to obtain operation functional services; and at an operation manipulating end: i) performing functional services combination based on operation requirements and at least one or the operation functionals services, to obtain the operation workflow; and ii) saving the operation workflow that has passed verification to obtain a target execution workflow (Certain Method of Organizing Human Activity & Mental Process), which are considered to be abstract ideas (See PEG 2019 and MPEP 2106.05). [Examiner notes the underlined limitations above recite the abstract idea].
The steps/functions disclosed above and in the independent claims recite the abstract idea of Certain Methods of Organizing Human Activity because the claimed limitations are generating an operation workflow comprising: combining a plurality of workflow modules, based on a workflow description in the workflow configuration content, to obtain an execution workflow framework; performing functional services combination based on operation requirements and the at least one operation functional services, to obtain an operation workflow which is managing personal behavior, relationships, and interactions. The Applicant’s claimed limitations are generating an operation workflow, which recite the abstract idea of Organizing Human Activity.
The steps/functions disclosed above and in the independent claims recite the abstract idea of Mental Process because the claimed limitations are generating an operation workflow comprising: constructing the plurality of workflow modules based on node configuration contents in the workflow configuration content; combining each workflow module, based on a workflow description in the workflow configuration content, to obtain an execution workflow framework; and performing functional services combination based on operation requirements and the at least one operation functional services, to obtain an operation workflow, which are observations, judgments, and evaluations of the human mind. The Applicant’s claimed limitations are generating an operation workflow, which recites the abstract idea of Mental Process.
In addition, dependent claims 2, 5, and 7-9 further narrow the abstract idea and recite further defining the constructing the plurality of workflow modules based on each node configuration content in the workflow configuration content; semantically mapping the framework name of the corresponding workflow module with the name of each operation module in the operation content; assigning a workflow number to the target execution workflow; and performing functional services combination based on operation requirements. These processes are similar to the abstract idea noted in the independent claims because they further the limitations of the independent claims which recite a certain method of organizing human activity which include managing personal behavior, relationships, and interactions as well as mental processes. Accordingly, these claim elements do not serve to confer subject matter eligibility to the claims since they recite abstract ideas. Dependent claim 4 will be discussed in Prong 2 analysis below.
Step 2A Prong 2: In this application, the above “acquiring a workflow configuration content; loading an operation code for each workflow module in the execution workflow framework, based on the execution workflow framework and the operation content, to obtain operation functional services; saving the operation workflow that has passed the verification to obtain the target execution workflow” steps/functions of the independent claims would not account for additional elements that integrate the judicial exception (e.g. abstract idea) into a practical application because receiving/storing data and displaying data merely add insignificant extra-solution activity and merely adds the words to apply it with the judicial exception. Also, the claimed “a plurality of workflow modules; A device for generating an operation workflow, comprising: memory; and at least one processor; A non-transitory machine-readable medium having stored thereon a program code for operation workflow generation, wherein when the program code is executed by at least one processor, the code guides the execution operation of the at least one processor” would not account for additional elements that integrate the judicial exception (e.g. abstract idea) into a practical application because the claimed structure merely adds the words to apply it with the judicial exception and mere instructions to implement an abstract idea on a computer (See PEG 2019 and MPEP 2106.05).
In addition, dependent claims 2, 5, and 7-9 further narrow the abstract idea and dependent claim 4 additionally recites “loading the operation code for each workflow module in the execution workflow framework based on the execution workflow framework and the operation content through a preset design pattern” which do not account for additional elements that integrate the judicial exception (e.g. abstract idea) into a practical application because receiving/storing data and displaying data merely add insignificant extra-solution activity (See PEG 2019 and MPEP 2106.05).
The claimed “a plurality of workflow modules; A device for generating an operation workflow, comprising: memory; and at least one processor; A non-transitory machine-readable medium having stored thereon a program code for operation workflow generation, wherein when the program code is executed by at least one processor, the code guides the execution operation of the at least one processor” are recited so generically (no details whatsoever are provided other than that they are general purpose computing components and regular office supplies) that they represent no more than mere instructions to apply the judicial exception on a computer. These limitations can also be viewed as nothing more than an attempt to generally link the use of the judicial exception to the technological environment of a computer. Even when viewed in combination, the additional elements in the claims do no more than use the computer components as a tool. There is no change to the computers and other technology that is recited in the claim, and thus the claims do not improve computer functionality or other technology (See PEG 2019).
Step 2B: When analyzing the additional element(s) and/or combination of elements in the claim(s) other than the abstract idea per se the claim limitations amount(s) to no more than: a general link of the use of an abstract idea to a particular technological environment and merely amounts to the application or instructions to apply the abstract idea on a computer (See MPEP 2106.05 and PEG 2019). Further, method claims 1-2, 4-5, and 7-9; device claim 10; and non-transitory computer-readable medium claim 11 recite “a plurality of workflow modules; A device for generating an operation workflow, comprising: memory; and at least one processor; A non-transitory machine-readable medium having stored thereon a program code for operation workflow generation, wherein when the program code is executed by at least one processor, the code guides the execution operation of the at least one processor”; however, these elements merely facilitate the claimed functions at a high level of generality and they perform conventional functions and are considered to be general purpose computer components which is supported by Applicant’s specification in Paragraphs 0075-81 and Figure 5. The Applicant’s claimed additional elements are mere instructions to implement the abstract idea on a general purpose computer and generally link of the use of an abstract idea to a particular technological environment. Also, the above “acquiring a workflow configuration content; loading an operation code for each workflow module in the execution workflow framework, based on the execution workflow framework and the operation content, to obtain operation functional services; saving the operation workflow that has passed the verification to obtain the target execution workflow” steps/functions of the independent claims would not account for significantly more than the abstract idea because receiving data and displaying/presenting data (See MPEP 2106.05) have been identified as well-known, routine, and conventional steps/functions to one of ordinary skill in the art. When viewed as a whole, these additional claim element(s) do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself.
In addition, claims 2, 5, and 7-9 further narrow the abstract idea identified in the independent claims. The Examiner notes that the dependent claims merely further define the data being analyzed and how the data is being analyzed. Similarly, claim 4 additionally recites “loading the operation code for each workflow module in the execution workflow framework based on the execution workflow framework and the operation content through a preset design pattern” which do not account for additional elements that amount to significantly more than the abstract idea because receiving data and displaying/presenting data (See MPEP 2106.05) have been identified as well-known, routine, and conventional steps/functions to one of ordinary skill in the art. The additional limitations of the independent and dependent claim(s) when considered individually and as an ordered combination do not amount to significantly more than the abstract idea. The examiner has considered the dependent claims in a full analysis including the additional limitations individually and in combination as analyzed in the independent claim(s). Therefore, the claim(s) are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
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.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1, 4-5, and 7-11 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hatanaka (U.S 2007/0288520 A1) in view of Werner (U.S 10,891,569 B1).
Claims 1, 10, and 11
Regarding Claim 1, Hatanaka discloses the following:
A method for generating an operation workflow, the method comprising [see at least Paragraph 0003 for reference to present invention relates to systems that use workflow logic at a Radio Frequency Identification (RFID) edge server wherein the workflows can be used to obtain RFID data and do operations at a site]
at a platform development end: i) acquiring a workflow configuration content [see at least Paragraph 0011 for reference to metadata indicating configurable elements; Paragraph 0012 for reference to different types of workflow modules using different metadata that can indicate the different configurable elements; Paragraph 0028 for reference to the workflow module exposing a configuration parameter that the user sets to the name of the other WM instance; Figure 1 and related text regarding items 102 ‘workflow module’, item 103 ‘workflow modules’, and item 105 ‘workflow’; Examiner notes the ‘workflow module’ as analogous to the ’platform development end’]
ii) constructing a plurality of workflow modules based on configuration contents in the workflow configuration content [see at least Paragraph 0024 for reference to WM class can have an associated descriptor ("plugin meta') that defines the names and types of its configuration parameters, and that WM instances can be created, redefined, and destroyed through a config API; Paragraph 0028 for reference to WM interaction can allow customers to assemble several WM instances into a larger workflow, and thereby also gives a degree of workflow customization beyond merely changing configuration parameters; Paragraph 0030 for reference to a workflow system can provide the building blocks for rapid creation and deployment of workflow applications; Paragraph 0346 for reference to a Workflow Manager module providing service for configuring workflow parameters; Figure 1 and related text regarding items 102 ‘workflow module’, item 103 ‘workflow modules’, and item 105 ‘workflow’; Examiner notes the ‘workflow module’ as analogous to the ’platform development end’]
iii) combining each workflow module, based on a workflow description in the workflow configuration content, to obtain an execution workflow framework [see at least Paragraph 0016 for reference to the workflow module being combined with other workflow modules to create a workflow; Paragraph 0020 for reference to workflow modules 202, 204, 206, and 208 can be combined to form a workflow; Paragraphs 0034-35 for reference to the workflow framework including a set of libraries, deployment modules, and services for workflows; Paragraph 0042 for reference to the plugin framework instantiates configured modules and provides a naming service to each module so the modules can interact with each other; Figure 1 and related text regarding items 102 ‘workflow module’, item 103 ‘workflow modules’, and item 105 ‘workflow’; Examiner notes the ‘workflow module’ as analogous to the ’platform development end’]
at an operation manipulating end: performing functional services combination based on operation requirements and the at least one operation functional services, to obtain an operation workflow [see at least Paragraph 0395-0400 for reference to a standard tag and verify workflow supporting the following features; Figure 3F and related text regarding a workflow naming service interface that defines the services a Workflow Naming Service can provide; Figure 4B and related text regarding ‘Tag and Verify Workflow’ and ‘Label Reader’; Examiner notes the ‘WorkflowNamingService’ as analogous to the ‘operation manipulating end’]
saving the operation workflow that has passed the verification to obtain the target execution workflow [see at least Paragraph 0425 for reference to the Naming service can be a workflow engine piece that allows client to retrieve module instance by referring its instance name wherein the registering module within the workflow engine; Figure 4B and related text regarding the ‘Workflow Engine’ containing ‘Registry’; Examiner notes the ‘WorkflowNamingService’ as analogous to the ‘operation manipulating end’]
While Hatanaka discloses the limitations above, it does not disclose at a platform development end: constructing a plurality of workflow modules based on node configuration contents in the workflow configuration content.
However, Werner discloses the following:
A method for generating an operation workflow, the method comprising [see at least Col 2 lines 31-33 for reference to methods for implementing dynamic task discovery for workflow tasks; Figure 7 and related text regarding methods and techniques for setting or modifying configuration data for discoverable workflow task versions]
at a platform development end: constructing a plurality of workflow modules based on node configuration contents in the workflow configuration content [see at least Col 7 lines 65-67 and Col 8 lines 1-4 for reference to the workflow engine service providing different workflow engine to clients being implemented by multiple computing nodes; Col 8 lines 12-20 for reference to the workflow engine service implementing various different components or modules to provide workflow engines to clients by implementing a workflow generation/registration module to create (e.g., provide various information to generate one or more workflows); Col 9 lines 25-46 for reference to the workflow generation request utilizing configuration information; Figure 2 and related text regarding item 212 ‘workflow generation/registration module’; Figure 4 and related text regarding item 410 ‘workflow generation request’ and item 416 ‘other workflow configuration information’; Examiner notes the ‘workflow generation/registration module’ as analogous to the ‘platform development end’]
at an operation development end: loading an operation code for each workflow module in the execution workflow framework, based on the execution workflow framework and the operation content, to obtain operation functional services [see at least Col 9 lines 59-63 for reference to workflow generation confirmation including individual task templates for each workflow task in the generated workflow (e.g., included executable code modules or source code for tasks in the workflow); Col 14 lines 11-14 for reference to the dynamically determined task version may be a code module which may be loaded or invoked to perform the version of the task; Examiner notes the ‘code module’ as analogous to the ‘operation development end’]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the workflow logic of Hatanaka to include the module configuration based on node configuration content of Werner. Doing so would provide workflow management services for a broad number of application services or products may lead toward greater cost savings and/or more efficient use of development resources for application providers, as stated by Werner (Col 1 lines 35-40).
Regarding claims 10 and 11, the claims recite limitations already addressed by the rejection of claim 1. Regarding claim 10, Hatanaka teaches a device for generating an operation workflow comprising a memory and at least one processor [Paragraph 0994 & 995]. Regarding claim 11, Hatanaka teaches a non-transitory machine-readable medium having stored thereon a program code for operation workflow generation, wherein when the program code is executed by at least one processor, the code guides the execution operation of the at least one processor [Paragraph 0995]. Therefore, claims 10 and 11 are rejected as being unpatentable over the combination of Hatanaka and Werner.
Claim 4
While the combination of Hatanaka and Werner disclose the limitations above, Hatanaka does not disclose wherein said loading an operation code for each workflow module in the execution workflow framework, based on the execution workflow framework and operation contents comprises: loading the operation code for each workflow module in the execution workflow framework based on the execution workflow framework and the operation content through a preset design pattern.
Regarding Claim 4, Werner discloses the following:
wherein said loading an operation code for each workflow module in the execution workflow framework, based on the execution workflow framework and operation contents comprises: loading the operation code for each workflow module in the execution workflow framework based on the execution workflow framework and the operation content through a preset design pattern [see at least Col 9 lines 59-63 for reference to workflow generation confirmation including individual task templates for each workflow task in the generated workflow (e.g., included executable code modules or source code for tasks in the workflow); Col 13 lines 48-61 for reference to dynamic task configurations exposing a code module or executable configured to perform a version of a specific task then the dynamic determination of the task may be performed according to some lookup or other technique accessing the dynamic task configuration locally; Col 14 lines 11-14 for reference to the dynamically determined task version may be a code module which may be loaded or invoked to perform the version of the task]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the workflow logic of Hatanaka to include the operation code loading of Werner. Doing so would provide workflow management services for a broad number of application services or products may lead toward greater cost savings and/or more efficient use of development resources for application providers, as stated by Werner (Col 1 lines 35-40).
Claim 5
While the combination of Hatanaka and Werner disclose the limitations above, regarding Claim 5, Hatanaka discloses the following:
semantically mapping a framework name of each workflow module with a name of corresponding operation module in the operation content [see at least Paragraph 0046 for reference to class maintains the mapping between work flow module names and their corresponding Module objects; Paragraph 0233 for reference to Device Name can map to module instance name because there would be one module instance per data display (LED) physical device]
Claim 7
While the combination of Hatanaka and Werner disclose the limitations above, regarding Claim 7, Hatanaka discloses the following:
after said saving the operation workflow that has passed verification, the said method further comprises: assigning a workflow number to the target execution workflow [see at least Paragraph 0395-0400 for reference to a standard tag and verify workflow supporting the following features; Figure 3F and related text regarding a workflow naming service interface that defines the services a Workflow Naming Service can provide; Figure 4B and related text regarding ‘Tag and Verify Workflow’ and ‘Label Reader’]
Claim 8
While the combination of Hatanaka and Werner disclose the limitations above, regarding Claim 8, Hatanaka discloses the following:
wherein said performing functional services combination based on operation requirements and at least one of the operation functional services comprises: selecting a required operation functional service, based on the operation requirements, from at least one of the operation functional services through a visualization view tool, to perform functional services combination [see at least Paragraph 0934 for reference to the Visual Editor defining workflows; Paragraph 0945 for reference to All Workflow modules can implement the Module interface—these are the hooks the Workflow infrastructure uses to configure the module and inform the module of changes; Figure 3E and related text regarding a workflow module interface which can implement the Module interface can be the hooks the Workflow infrastructure uses to configure the module and inform the module of changes]
Claim 9
While the combination of Hatanaka and Werner disclose the limitations above, regarding Claim 9, Hatanaka discloses the following:
wherein, after performing functional services combination based on operation requirements and at least one of the operation functional services, to obtain the operation workflow, the method further comprises: verifying the operation workflow [see at least Paragraph 0395-0400 for reference to a standard tag and verify workflow supporting the following features; Figure 3F and related text regarding a workflow naming service interface that defines the services a Workflow Naming Service can provide; Figure 4B and related text regarding ‘Tag and Verify Workflow’ and ‘Label Reader’]
Claim(s) 2 is/are rejected under 35 U.S.C. 103 as being unpatentable over Hatanaka (U.S 2007/0288520 A1) in view of Werner (U.S 10,891,569 B1), as applied in claim 1, in view of Sun (U.S 2007/0094211 A1).
Claim 2
While the combination of Hatanaka and Werner disclose the limitations above, they do not disclose wherein said constructing a plurality of workflow modules based on node configuration contents in the workflow configuration content comprises: performing a legality check on the workflow configuration content to determine that a workflow structure corresponding to the workflow configuration content is a directed acyclic graph; and constructing each workflow module according to each node configuration content in the workflow structure, and performing a legality check on each workflow module.
Regarding Claim 2, Sun discloses the following:
wherein said constructing a plurality of workflow modules based on node configuration contents in the workflow configuration content comprises: performing a legality check on the workflow configuration content to determine that a workflow structure corresponding to the workflow configuration content is a directed acyclic graph [see at least Paragraph 0045 for reference to a workflow is mapped to a PetriNet, certain proper ties dealing with the correctness of workflows, such as deadlocks, liveliness, and bounded-ness, can be verified using graph analysis; Paragraph 0071 for reference to the workflows considered are acyclic graphs; Paragraph 0076 for reference to an extended DAG structure: Hierarchical Dependence Graph (HDG), which represents a workflow 120, for example JDF, through exploring the process and resource dependences; Paragraph 0079 for reference to a directed acyclic graph being directed to a graph were no path starts and ends at the same vertex]
constructing each workflow module according to each node configuration content in the workflow structure, and performing a legality check on each workflow module [see at least Paragraph 0052 for reference to the inference engine generates all the possible workflows by checking valid connections between various services; Paragraph 0053 for reference to inference engine initially generates a permutation of valid paths by matching valid service and user requirements, and then generates all the combinations of all the valid paths which would generate possible workflow structures]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the workflow module construction of Hatanaka to include the legality check of the workflow configuration using directed acyclic graphs of Sun. Doing so provides a formal way of modeling and evaluating workflows, which obviates the current intuitive, trial-and-error approach, as stated by Sun (Paragraph 0043).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Rozinat, Anne, et al. "Workflow simulation for operational decision support." Data & Knowledge Engineering 68.9 (2009): 834-850.
DOCUMENT ID
INVENTOR(S)
TITLE
US 2003/0135384 A1
Nguyen, Huy
Workflow Process Method And System For Iterative And Dynamic Command Generation And Dynamic Task Execution Sequencing Including External Command Generator And Dynamic Task Execution Sequencer
EP 1643435 B1
Shukla et al.
Workflow Modeling System Arranges Displayed Selection Of Activities In Display Area In Accordance With Structure Information Received From User, To Create Workflow
THIS ACTION IS MADE FINAL. Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KRISTIN ELIZABETH GAVIN whose telephone number is (571)270-7019. The examiner can normally be reached M-F 7:30-4:30 PM 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, Jerry O'Connor can be reached at 571-272-6787. 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.
/KRISTIN E GAVIN/Primary Examiner, Art Unit 3624
