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
Regarding Applicant’s claim to Priority, Examiner has fully considered Applicant’s assertions. Examiner has withdrawn the request for priority documents.
Regarding the 35 USC 112(b) and 35 USC 112(a) rejections, Examiner has fully considered Applicant’s arguments and amendments.
Regarding Applicant’s assertion of “Applicant amends these Claims to recite a "using and used" mapping which is known in the art to represent a "using" mapping to define active relationships between source and target systems telling a system how to convert data, while a "used" mapping is a historical blueprint, i.e., what was mapped during a previous iteration.,” Examiner respectfully disagrees. Applicant has not provided any proof to support their assertion that this particular mapping scheme is known to one of ordinary skill in the art. Furthermore, the claim limitations render the metes and bounds of the claim unclear because it is unclear what weight is provided to the claim terms being in quotations. It is unclear if the quotations are intended to reproduce words verbatim, such as quoting from the specification, if the quotations are meant to highlight the specific words, or if the claim language is intended to be exemplary, or what other function the quotations could have on the metes and bounds of the claim. Examiner suggests amending the claims to remove the quotations in order to clarify the metes and bounds of the claim.
Therefore, the 35 USC 112(b) rejection is maintained for the claims comprising quoted claim language.
Regarding the 35 USC 112(b) rejection of claims 3 and 5, the claims have been amended to overcome the 35 USC 112(b) rejection with respect to the brackets. Therefore, these particular rejections have been withdrawn.
Regarding the 35 USC 112(b) rejection of claims 6 and 12, the claims have been amended to overcome the 35 USC 112(b) rejection with respect to the brackets. Therefore, these particular rejections have been withdrawn.
Regarding the 35 USC 112(b) and 35 USC 112(a) rejections of claim 9, the claims have been amended to overcome the 35 USC 112(a) and 35 USC 112(b) rejections with respect to claim 9. Therefore, these particular rejections have been withdrawn.
Regarding the 35 USC 101 rejection, Examiner has fully considered Applicant’s arguments and amendments.
Regarding Applicant’s assertion of “These claims are directed to a computer-implemented workflow recommendation solution based on stored determinate mappings, rather than to a mental process. Independent claim 1 now expressly recites a workflow recommendation method in which determinate mappings are stored in memory and searched using the current requirement entity as a search key. Independent claim 9 has been amended to recite a memory storing instructions and at least one processor configured to execute those instructions to perform the receiving, searching, and recommending operations. Independent claim 14 likewise recites a memory storing a computer program and at least one processor executing that program. These amendments directly address the Office Action's characterization in paragraphs 35-50 that the claims could be performed mentally but for generic device language.,” Examiner respectfully asserts that incorporating generic computing devices, such as a memory and processor, is not sufficient to prove integration into a practical application or anything significantly more. Use of a computer or other machinery in its ordinary capacity for tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., mental processes) does not integrate a judicial exception into a practical application. See MPEP 2106.05(f).
Regarding Applicant’s assertion of “Even if the Office maintains that the claims include an abstract concept, the amended claims integrate that concept into a practical application under Step 2A, Prong 2. The specification explains that the disclosed approach was developed "to avoid various problems associated with keyword mapping" by establishing a determinate mapping between a requirement entity and a workflow entity and recommending a corresponding workflow entity on the basis of that determinate mapping. The Detailed Description further states that, because a determinate mapping is established between a requirement entity and a workflow entity, "a determinate and accurate workflow entity can be recommended," "the efficiency and effectiveness of workflow recommendation may be improved," and "expansion with new mappings is possible." The amended claims implement this disclosed improvement by requiring stored determinate mappings, a search of those mappings using the current requirement entity as a search key, and recommendation of a candidate workflow entity for which a determinate mapping exists.,” Examiner respectfully disagrees. Examiner respectfully asserts that an improvement to the workflow recommendation process is not an improvement to the functioning of the computer itself, or any other technology or technical field. Rather, this type of improvement would be an improvement reflected in the abstract limitations for consideration under Step 2A, Prong 1. MPEP 2106.05(a): “It is important to note, the judicial exception alone cannot provide the improvement. The improvement can be provided by one or more additional elements...” Additionally, as discussed in 2106.05(a)(II) improvements to technology or technical fields, “an improvement in the abstract idea itself … is not an improvement in technology.”
Regarding Applicant’s assertion of “The dependent-claim amendments further reinforce this practical application. Claims 3 and 5 now recite the particular relationship conditions used to search the determinate mappings for edge applications or functional blocks. Claims 6 and 12 recite updating the stored determinate mappings with a new mapping record when the current requirement entity is not already present. This is not merely use of a computer to receive or transmit information. Rather, the claims apply a structured, expandable mapping repository to improve workflow recommendation in requirements engineering and to maintain the determinate mapping records used for later searches. The recited memory and processor are not appended after the fact; they are the components through which the stored mapping records are searched and updated.,” Examiner respectfully disagrees. Examiner respectfully asserts that the present claims do not reflect any particular improvements to the functioning of the memory, or any other technology or technical field. Examiner respectfully asserts that an improvement to the workflow recommendation process is not an improvement to the functioning of the computer itself, or any other technology or technical field. Rather, this type of improvement would be an improvement reflected in the abstract limitations for consideration under Step 2A, Prong 1. MPEP 2106.05(a): “It is important to note, the judicial exception alone cannot provide the improvement. The improvement can be provided by one or more additional elements...” Additionally, as discussed in 2106.05(a)(II) improvements to technology or technical fields, “an improvement in the abstract idea itself … is not an improvement in technology.”
Accordingly, the 35 USC 101 rejection is maintained.
Regarding the 35 USC 103 rejection, Examiner has fully considered Applicant’s arguments and amendments.
Regarding Applicant’s assertion of “Dautov does not disclose that claim architecture. The DIA-CEC knowledge base is described as a common semantic vocabulary for defining task requirements, device self- descriptions, and policies for match-making, task grouping, and aggregation. Dautov, § 4. Dautov further explains that the Reasoner performs match-making between task requirements and device properties, and that the mapping operation follows decomposition, discovery, and selection to allocate DIA tasks to CEC nodes, with the mapping driven by minimizing the number of involved nodes and maintaining spare nodes for churn. Dautov, §§ 3.1, 6, and 7. Thus, the "mapping" is runtime allocation of decomposed data-intensive application tasks to selected clustered edge computing nodes. It is not a pre-established determinate mapping between each requirement entity and each workflow entity, and it is not searched using a current requirement entity as a keyword to retrieve candidate workflow entities for requirements-engineering recommendation.,” Examiner respectfully disagrees. As can be seen in at least Pgs. 3-4, the Dautov reference discloses a DIA-CEC knowledge base that is utilized to store the common ontology that includes main ontological classes and properties that map the devices, tasks, suitability, and other aspects required for task assignment. As stated in Pg. 1 of Dautov: “To support the clusterisation process, the proposed solution relies on a unified semantic knowledge base that provides a common vocabulary of terms for modelling task requirements and edge device properties, as well as enables automated task grouping and match-making for device discovery and selection, using built-in reasoning capabilities.” The knowledge base is a unified semantic model that provides a common vocabulary of terms to represent task requirements and device properties, as well as to enable automated reasoning based node discovery and selection. The generation of this knowledge base is not performed instantaneously; rather, it is stored and utilized for task processing and allocation.
Regarding Applicant’s assertion of “The rejection therefore relies on an improper conflation of distinct concepts. Dautov uses semantic reasoning to discover and select suitable edge devices and then allocate tasks to nodes. Zhu scores edge servers for real-time workflow or subtask assignment. Neither reference teaches storing or searching the claimed determinate mapping between requirement entities and workflow entities, nor do they teach recommending the candidate workflow entity obtained through such a search. The Office Action's stated motivation-that incorporating Zhu would improve performance through real-time edge analysis and speed task allocation by identifying workflows and subtasks in real time-does not provide an articulated reason with rational underpinning to transform the edge-node allocation system of Dautov into Applicant's requirements-engineering recommendation system. See Office Action 55; MPEP § 2143; KSR Int'l Co. v. Teleflex Inc., 550 U.S. 398 (2007). At most, the stated rationale explains why one might use resource-aware scheduling in an edge computing environment; it does not explain why a skilled artisan would have modified Dautov and Zhu to provide the claimed pre-established determinate requirement- entity-to-workflow-entity mapping and candidate workflow entity recommendation.,” Examiner respectfully disagrees with Applicant’s assertion. Both the Dautov and Zhu references are related to the same field of endeavor, namely assigning devices to perform various tasks. Examiner notes that sufficient motivation to combine Zhu into Dautov was provided in the non-final office action dated 04/23/2026. In particular, Examiner stated that “One would have been motivated to do so in order to improve the overall performance of the cloud computing center by utilizing real time analysis through an edge computing device (Zhu, [0020]). By incorporating the teachings of Zhu, one would have been able to speed up effective task allocation by identifying workflows and subtasks in real time (Zhu, [0090-0092]).” Examiner maintains that this motivation would be sufficient to one of ordinary skill in order to combine the teachings of Zhu into Dautov. See MPEP 2141.
Accordingly, the 35 USC 103 rejection is maintained.
Claim Objections
Claim 12 is objected to because of the following informalities: Examiner suggests amending the claim for the sake of antecedence by reciting “…the human-machine interaction module provides the current requirement entity to a determinate mapping buildermodule, and the determinate mapping buildermodule then maps the current requirement entity to an existing workflow entity or a new workflow entity…”
Appropriate correction is required.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-14 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Regarding claims 1, 9, and 14, the metes and bounds of the claim are rendered unclear due to the limitation of “in the determinate mapping, establishing a connection between the requirement entity and the corresponding workflow entity by a "using and used" mapping.” The metes and bounds of the claims are rendered unclear because it is unclear what limitations are being imparted upon the claim through the use of quotations. It is unclear what function the quotations have on the metes and bounds of the claimed language. It is unclear if the quotations are intended to reproduce words verbatim, such as quoting from the specification, if the quotations are meant to highlight the specific words, or what other function the quotations could have on the metes and bounds of the claim. Therefore, the metes and bounds of the claim are rendered unclear because it is unclear what limitations the quoted language provides to the claims.
For the sake of compact prosecution, Examiner is interpreting the claim as though in the determinate mapping, establishing a connection between the requirement entity and the corresponding workflow entity by using a mapping. Examiner suggests amending the claims to remove the quotations and clearly define the metes and bounds of the claimed mapping.
Regarding claims 2, 4, 10, and 11 the metes and bounds of the claims are rendered unclear due to the limitations recited in quotations. Similar to claims 1 and 9 above, the metes and bounds of the claims are rendered unclear because it is unclear what limitations are being imparted upon the claim through the use of quotations. It is unclear what function the quotations around the claim terms of "using and used,” a “comprising and comprised,” and a “supporting and supported” have on the metes and bounds of the claimed language. It is unclear if the quotations are intended to reproduce words verbatim, such as quoting from the specification, if the quotations are meant to highlight the specific words, or what other function the quotations could have on the metes and bounds of the claim. Therefore, the metes and bounds of the claim are rendered unclear because it is unclear what limitations the quoted language provides to the claims.
For the sake of compact prosecution, Examiner is interpreting the claim as though in the claim recites that in determinate mapping, connections are established between the claimed elements through mappings. Examiner suggests amending the claims to remove the quotations and clearly define the metes and bounds of the claimed mappings.
Dependent claims 2-8 are rejected due to dependency on rejected base claim 1.
Dependent claims 10-13 are rejected due to dependency on rejected base claim 9.
Accordingly, claims 1-14 are rejected under 35 USC 112(b).
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-14 are rejected under 35 USC 101 because the claimed invention is directed to a judicial exception (i.e. abstract idea) without anything significantly more.
Step 1: Claims 1-8 are directed to a method, claims 9-13 are directed to a device, and claim 14 is directed to a device. Therefore, the claims are directed to patent eligible categories of invention.
Step 2A, Prong 1: Claims 1, 9, and 14 recite recommending a candidate workflow entity, constituting an abstract idea based on “Mental Processes” related to concepts performed in the human mind including observation, evaluation, judgment, and opinion. Claim 1 recites limitations, similarly recited in claim 14, including “receiving a current requirement entity; based on a pre-established determinate mapping between each requirement entity and each workflow entity, using the current requirement entity as a search key to search the determinate mappings, in order to obtain at least one candidate workflow entity, where a determinate mapping has been established between this at least one candidate workflow entity and the current requirement entity; in the determinate mapping, establishing a connection between the requirement entity and the corresponding workflow entity by a "using and used" mapping; and recommending the candidate workflow entity.” Claim 9 recites limitations including “receive a current requirement entity, provide the current requirement entity; recommend a candidate workflow entity; and based on a pre-established determinate mapping between each requirement entity and each workflow entity, search the determinate mappings using the current requirement entity as a keyword to obtain at least one candidate workflow entity, where a determinate mapping has been established between this at least one candidate workflow entity and the current requirement entity, and provide the at least one candidate workflow entity; in the determinate mapping, establish a connection between the requirement entity and the corresponding workflow entity with a "using and used” mapping.” These limitations, as drafted, but for the recitation of “device,” is a process that covers performance of the limitations in the mind but for the recitation of generic computer components. That is, but for the “device” language, nothing in the claim elements preclude the steps from practically being performed in the human mind. For example, with the exception of the “device” language, the claim steps in the context of the claim encompass a user mentally or manually performing the steps of the claim.
Dependent claims 2-8, 10-11, and 13 further narrow the abstract idea identified in the independent claims and do not introduce further additional elements for consideration.
Dependent claim 12 will be evaluated under Step 2A, Prong 2.
Step 2A, Prong 2: The claims do not integrate the judicial exception into a practical application. Claim 1 is directed to a method that includes the steps of “receiving a current requirement entity at a processor” and “based on a pre-established determinate mapping between each requirement entity and each workflow entity stored in a memory…” Claim 9 is directed to a device comprising “a memory storing instructions; and at least one processor configured to execute the instructions to,” as well as “provide the current requirement entity to the workflow entity search module, and recommend a candidate workflow entity from the workflow search module.” Claim 14 is directed to a device comprising “a memory storing a computer program; and at least one processor used to retrieve the computer program stored in the memory and execute the computer program, the program including.” Use of a computer or other machinery in its ordinary capacity for tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., mental processes) does not integrate a judicial exception into a practical application. See MPEP 2106.05(f).
Therefore, the additional elements of the independent claims, when considered both individually and in combination, are not sufficient to prove integration into a practical application.
Dependent claims 2-8, 10-11, and 13 further narrow the abstract idea identified in the independent claims and do not introduce further additional elements for consideration.
Dependent claim 12 further recites the additional element of “upon receiving a search failure indication from the workflow entity search module, the human-machine interaction module provides the current requirement entity to the determinate mapping builder module, and the determinate mapping builder module then maps the current requirement entity to an existing workflow entity or a new workflow entity, forms a new mapping record and provides the new mapping record to the workflow entity search module, so that the workflow entity search module updates the determinate mappings with the new mapping record. [Examiner’s Note: See the 35 USC 112(f) claim interpretation above.]” Use of a computer or other machinery in its ordinary capacity for tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., mental processes) does not integrate a judicial exception into a practical application. See MPEP 2106.05(f).
Therefore, the additional elements of the dependent claims, when considered both individually and in the context of the independent claims above, are not sufficient to prove integration into a practical application.
Step 2B: The claims do not comprise anything significantly more. Claim 1 is directed to a method that includes the steps of “receiving a current requirement entity at a processor” and “based on a pre-established determinate mapping between each requirement entity and each workflow entity stored in a memory…” Claim 9 is directed to a device comprising “a memory storing instructions; and at least one processor configured to execute the instructions to,” as well as “provide the current requirement entity to the workflow entity search module, and recommend a candidate workflow entity from the workflow search module.” Claim 14 is directed to a device comprising “a memory storing a computer program; and at least one processor used to retrieve the computer program stored in the memory and execute the computer program, the program including.” Use of a computer or other machinery in its ordinary capacity for tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., mental processes) is not anything significantly more. See MPEP 2106.05(f).
Therefore, the additional elements of the independent claims, when considered both individually and in combination, are not anything significantly more.
Dependent claims 2-8, 10-11, and 13 further narrow the abstract idea identified in the independent claims and do not introduce further additional elements for consideration, which is not anything significantly more.
Dependent claim 12 further recites the additional element of “upon receiving a search failure indication from the workflow entity search module, the human-machine interaction module provides the current requirement entity to the determinate mapping builder module, and the determinate mapping builder module then maps the current requirement entity to an existing workflow entity or a new workflow entity, forms a new mapping record and provides the new mapping record to the workflow entity search module, so that the workflow entity search module updates the determinate mappings with the new mapping record. [Examiner’s Note: See the 35 USC 112(f) claim interpretation above.]” Use of a computer or other machinery in its ordinary capacity for tasks (e.g., to receive, store, or transmit data) or simply adding a general purpose computer or computer components after the fact to an abstract idea (e.g., mental processes) is not anything significantly more. See MPEP 2106.05(f).
Therefore, the additional elements of the dependent claims, when considered both individually and in the context of the independent claims above, are not anything significantly more.
Accordingly, claims 1-14 are rejected under 35 USC 101.
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-6, 9-12, and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Dautov et al. ("Automating IoT data-intensive application allocation in clustered edge computing." 2019) in view of Zhu et al. (US 20210096911 A1).
Regarding claim 1, Dautov teaches a workflow recommendation method comprising (Pg. 3, Fig. 2):
receiving a current requirement entity at a processor (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, as well as in Pgs. 6-7, teach utilizing the Frontend to receive an input workflow definition and parsing the file to identify tasks constituting the workflow, along with the functional and non-functional requirements, and translating this definition to OWL, wherein this translation from a workflow process specification to the DIA-CEC ontology is performed by the Frontend, wherein “6, Semantic Reasoner” teaches a semantic reasoner is a software component able to infer logical consequences from the asserted facts or axioma, wherein the inference rules are specified by means of OWL in the DIA-CEC ontology, wherein the responsibility of the Reasoner in the proposed system is to perform match making between task requirements and device properties, wherein one can programmatically invoke the Reasoner and manipulate the DIA-CEC ontology using the OWL API, as well as in Pgs. 11-12 teach searching for network devices matching specific query parameters through the use of semantic modeling that describes all involved system elements using the same semantic vocabulary, thereby minimizing the semantic heterogeneity between them, and wherein Pg. 4 teaches the DIA-CEC system modular architecture including the orchestration engine, mapper, reasoner, and more, wherein Pg. 10 teaches the ISS scenario can be implemented on an edge cluster, wherein Pg. 3 teaches the ISS system includes a database to store the processing results, and wherein Pg. 2 teaches utilizing multiple middleware frameworks for batch and stream processing that can be used to interconnect computing nodes into local area clusters for executing complex DIAs; see also: Pgs. 1, 5);
based on a pre-established determinate mapping between each requirement entity and each workflow entity stored in a memory (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the DIA-CEC knowledge base stores the common ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein the selection step groups the discovered nodes according to matching tasks, and ranks them based on their non-functional properties, thereby selecting the best suitable nodes, wherein mapping finalizes the selection process and aims to allocate the DIA workflow to the identified nodes, wherein this activity tries to match functional and non-functional task requirements to discovered and ranked devices, aiming to minimize the number of nodes involved, in this way, a waiting list of spare available nodes is maintained to handle a node churn, wherein the task nodes are mapped in order to perform functional match making through semantic discovery, as well as in Pgs. 6-7, teach the translation from a workflow process specification to the DIA-CEC ontology is performed by the Frontend, wherein the responsibility of the Reasoner in the proposed system is to perform match making between task requirements and device properties, wherein one can programmatically invoke the Reasoner and manipulate the DIA-CEC ontology using the OWL API, wherein Pgs. 8-9 teach mapping follows the decomposition, discovery, and selection steps and finally allocates the DIA tasks to CEC nodes, wherein it is driven by the requirement to minimize the number of involved nodes in order to reserve spare nodes, wherein mapping is considered an optimization problem, as well as in Pgs. 11-12 teach searching for network devices matching specific query parameters through the use of semantic modeling that describes all involved system elements using the same semantic vocabulary, thereby minimizing the semantic heterogeneity between them, and wherein Pg. 4 teaches the DIA-CEC system modular architecture including the orchestration engine, mapper, reasoner, and more, wherein Pg. 10 teaches the ISS scenario can be implemented on an edge cluster, wherein Pg. 3 teaches the ISS system includes a database to store the processing results, and wherein Pg. 2 teaches utilizing multiple middleware frameworks for batch and stream processing that can be used to interconnect computing nodes into local area clusters for executing complex DIAs; see also: Pgs. 1, 5),
using the current requirement entity as a search key to search the determinate mappings (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein the selection step groups the discovered nodes according to matching tasks, and ranks them based on their non-functional properties, thereby selecting the best suitable nodes, wherein mapping finalizes the selection process and aims to allocate the DIA workflow to the identified nodes, wherein this activity tries to match functional and non-functional task requirements to discovered and ranked devices, aiming to minimize the number of nodes involved, in this way, a waiting list of spare available nodes is maintained to handle a node churn, wherein the task nodes are mapped in order to perform functional match making through semantic discovery, as well as in Pgs. 6-7, teach the translation from a workflow process specification to the DIA-CEC ontology is performed by the Frontend, wherein the responsibility of the Reasoner in the proposed system is to perform match making between task requirements and device properties, wherein one can programmatically invoke the Reasoner and manipulate the DIA-CEC ontology using the OWL API, wherein Pgs. 8-9 teach mapping follows the decomposition, discovery, and selection steps and finally allocates the DIA tasks to CEC nodes, wherein it is driven by the requirement to minimize the number of involved nodes in order to reserve spare nodes, wherein mapping is considered an optimization problem, as well as in Pgs. 11-12 teach searching for network devices matching specific query parameters through the use of semantic modeling that describes all involved system elements using the same semantic vocabulary, thereby minimizing the semantic heterogeneity between them; see also: Pgs. 1, 5, 10),
in order to obtain at least one candidate workflow entity (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein the selection step groups the discovered nodes according to matching tasks, and ranks them based on their non-functional properties, thereby selecting the best suitable nodes, wherein mapping finalizes the selection process and aims to allocate the DIA workflow to the identified nodes, wherein this activity tries to match functional and non-functional task requirements to discovered and ranked devices, aiming to minimize the number of nodes involved, in this way, a waiting list of spare available nodes is maintained to handle a node churn, wherein the task nodes are mapped in order to perform functional match making through semantic discovery, as well as in Pgs. 6-7, teach the translation from a workflow process specification to the DIA-CEC ontology is performed by the Frontend, wherein the responsibility of the Reasoner in the proposed system is to perform match making between task requirements and device properties, wherein one can programmatically invoke the Reasoner and manipulate the DIA-CEC ontology using the OWL API, wherein Pgs. 8-9 teach mapping follows the decomposition, discovery, and selection steps and finally allocates the DIA tasks to CEC nodes, wherein it is driven by the requirement to minimize the number of involved nodes in order to reserve spare nodes, wherein mapping is considered an optimization problem, as well as in Pgs. 11-12 teach searching for network devices matching specific query parameters through the use of semantic modeling that describes all involved system elements using the same semantic vocabulary, thereby minimizing the semantic heterogeneity between them; see also: Pgs. 1, 5, 10),
where a determinate mapping has been established between this at least one candidate workflow entity and the current requirement entity (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein the selection step groups the discovered nodes according to matching tasks, and ranks them based on their non-functional properties, thereby selecting the best suitable nodes, wherein mapping finalizes the selection process and aims to allocate the DIA workflow to the identified nodes, wherein this activity tries to match functional and non-functional task requirements to discovered and ranked devices, aiming to minimize the number of nodes involved, in this way, a waiting list of spare available nodes is maintained to handle a node churn, wherein the task nodes are mapped in order to perform functional match making through semantic discovery, as well as in Pgs. 6-7, teach the translation from a workflow process specification to the DIA-CEC ontology is performed by the Frontend, wherein the responsibility of the Reasoner in the proposed system is to perform match making between task requirements and device properties, wherein one can programmatically invoke the Reasoner and manipulate the DIA-CEC ontology using the OWL API, wherein Pgs. 8-9 teach mapping follows the decomposition, discovery, and selection steps and finally allocates the DIA tasks to CEC nodes, wherein it is driven by the requirement to minimize the number of involved nodes in order to reserve spare nodes, wherein mapping is considered an optimization problem, as well as in Pgs. 11-12 teach searching for network devices matching specific query parameters through the use of semantic modeling that describes all involved system elements using the same semantic vocabulary, thereby minimizing the semantic heterogeneity between them; see also: Pgs. 1, 5, 10);
in the determinate mapping, establishing a connection between the requirement entity and the corresponding workflow entity by a "using and used" mapping (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein the selection step groups the discovered nodes according to matching tasks, and ranks them based on their non-functional properties, thereby selecting the best suitable nodes, wherein mapping finalizes the selection process and aims to allocate the DIA workflow to the identified nodes, wherein this activity tries to match functional and non-functional task requirements to discovered and ranked devices, aiming to minimize the number of nodes involved, in this way, a waiting list of spare available nodes is maintained to handle a node churn, wherein the task nodes are mapped in order to perform functional match making through semantic discovery, as well as in Pgs. 6-7, teach the translation from a workflow process specification to the DIA-CEC ontology is performed by the Frontend, wherein the responsibility of the Reasoner in the proposed system is to perform match making between task requirements and device properties, wherein one can programmatically invoke the Reasoner and manipulate the DIA-CEC ontology using the OWL API, wherein Pg. 5 teaches the DIA-CEC knowledge base includes dia-cec:Task that is used to represent an atomic processing step within a workflow– an acyclic pipeline of tasks, wherein when mapped to cluster nodes, tasks may either run in parallel on multiple nodes, or as a stand-alone process on a single node. The former applies to usual data processing operations executed on worker nodes, whereas the latter typically refers to sensing nodes that act as data stream sources within a workflow topology, wherein dia-cec:SuitableDevice is another dia-cec:Device subclass that serves to express task requirements that have be satisfied by a device in order to be classified as suitable for a given task, wherein is further subclassed into dia-cec: FunctionallySuitableDevice to express software (e.g. specific components, libraries, middleware, etc.) and hardware (e.g. the traditional CPU, RAM, GPU, HDD, and Networking, as well as the IoT-related Sensing and Actuating resources, Power and Location) requirements, and NonFunctionallySuitableDevice to quantitatively ex press the volume, velocity, and variety metrics of data processing involved in the given task, wherein these two types of requirements are expressed using FunctionalProperty and NonFunctionalProperty, respectively, as well as in Pgs. 11-12 teach searching for network devices matching specific query parameters through the use of semantic modeling that describes all involved system elements using the same semantic vocabulary, thereby minimizing the semantic heterogeneity between them; see also: Pgs. 1, 5, 8-10).
However, Dautov does not explicitly teach and recommending the candidate workflow entity.
From the same or similar field of endeavor, Zhu to include and recommending the candidate workflow entity ([0062-0063] teach the workflow assignment module prioritizes the assignment of a single edge server, wherein the edge servers can be assigned based on the recommendation scores, wherein [0082-0083] teach assigning the subtask workflow to a computing server and using resource information and waiting queue of each edge server to calculate the recommendation score of each edge server, wherein the workflow allocation step prioritizes the allocation of a single edge server and can assign edge servers based on their recommendation score; see also: [0057-0061]).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify Dautov to incorporate the teachings of Zhu to include and recommending the candidate workflow entity. One would have been motivated to do so in order to improve the overall performance of the cloud computing center by utilizing real time analysis through an edge computing device (Zhu, [0020]). By incorporating the teachings of Zhu, one would have been able to speed up effective task allocation by identifying workflows and subtasks in real time (Zhu, [0090-0092]).
Regarding claim 14, the claims recite limitations already addressed by the rejection of claim 1. Regarding claim 14, Dautov teaches a workflow recommendation device comprising (Pgs. 3-4): a memory storing a computer program (Pg. 4 teaches the DIA-CEC system modular architecture including the orchestration engine, mapper, reasoner, and more, wherein Pg. 10 teaches the ISS scenario can be implemented on an edge cluster, wherein Pg. 3 teaches the ISS system includes a database to store the processing results, and wherein Pg. 2 teaches utilizing multiple middleware frameworks for batch and stream processing that can be used to interconnect computing nodes into local area clusters for executing complex DIAs); and at least one processor used to retrieve the computer program stored in the memory and execute the computer program, the program including (Pg. 4 teaches the DIA-CEC system modular architecture including the orchestration engine, mapper, reasoner, and more, wherein Pg. 10 teaches the ISS scenario can be implemented on an edge cluster, wherein Pg. 3 teaches the ISS system includes a database to store the processing results, and wherein Pg. 2 teaches utilizing multiple middleware frameworks for batch and stream processing that can be used to interconnect computing nodes into local area clusters for executing complex DIAs). Accordingly, claim 14 is rejected as being unpatentable over Dautov in view of Zhu.
Regarding claims 2 and 10, the combination of Dautov and Zhu teaches all the limitations of claims 1 and 9 above.
Dautov further teaches wherein: each said requirement entity comprises a use case and a task (Pg. 3, “2.2” teaches the Intelligent Surveillance System scenario has applications including recognizing human faces and license plates in outdoor locations, wherein Pg. 7 teaches the grouping operation looks for tasks with identical functional requirements within a workflow and groups them together, wherein the system can checked for subsequent tasks following given tasks, wherein the tasks include DetectFace, RecogniseFace, or alternatively DetectLicensePlate and RecogniseLicensePlate; see also: Pg. 5);
each said workflow entity comprises an edge application and a skill (Pg. 5 teaches the ontology includes dia-cec:Device is introduced to represent an edge device characterized by its functional and non-functional properties. It is further subclassed into dia-cec:SensingDevice and dia-cec:ActuatingDevice, wherein dia-cec:hasVolume, dia-cec:hasVelocity, and dia-cec:hasVariety are data properties used to quantitatively express non-functional properties of edge devices in terms of the volume, velocity, and variety metrics, respectively, wherein Pg. 7 teaches the grouping operation looks for tasks with identical functional requirements within a workflow and groups them together, wherein the system can checked for subsequent tasks following given tasks, wherein the tasks include DetectFace, RecogniseFace, or alternatively DetectLicensePlate and RecogniseLicensePlate);
the current requirement entity comprises a current use case or a current task of a current use case (Pg. 3, “2.2” teaches the Intelligent Surveillance System scenario has applications including recognizing human faces and license plates in outdoor locations, wherein Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein the selection step groups the discovered nodes according to matching tasks, and ranks them based on their non-functional properties, thereby selecting the best suitable nodes, wherein mapping finalizes the selection process and aims to allocate the DIA workflow to the identified nodes, wherein this activity tries to match functional and non-functional task requirements to discovered and ranked devices, wherein Pg. 7 teaches the grouping operation looks for tasks with identical functional requirements within a workflow and groups them together, wherein the system can checked for subsequent tasks following given tasks, wherein the tasks include DetectFace, RecogniseFace, or alternatively DetectLicensePlate and RecogniseLicensePlate; see also: Pg. 5);
in the determinate mapping, a "comprising and comprised" mapping is provided between a use case representing a requirement entity and a task comprised in the use case (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein the selection step groups the discovered nodes according to matching tasks, and ranks them based on their non-functional properties, thereby selecting the best suitable nodes, wherein mapping finalizes the selection process and aims to allocate the DIA workflow to the identified nodes, wherein this activity tries to match functional and non-functional task requirements to discovered and ranked devices, wherein Pg. 5 teaches the ontology includes dia-cec:hasTask serves to hierarchically associate one task with another, thereby representing an overall workflow, wherein the subject of this property represents an overall DIA workflow, whereas the object represents a specific atomic task constituting the workflow, wherein Pg. 7 teaches the grouping operation looks for tasks with identical functional requirements within a workflow and groups them together, wherein the system can checked for subsequent tasks following given tasks, wherein the tasks include DetectFace, RecogniseFace, or alternatively DetectLicensePlate and RecogniseLicensePlate; see also: Pgs. 6, 12),
a "providing and provided" mapping is provided between an edge application representing a workflow entity and a skill provided by the edge application (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein the selection step groups the discovered nodes according to matching tasks, and ranks them based on their non-functional properties, thereby selecting the best suitable nodes, wherein mapping finalizes the selection process and aims to allocate the DIA workflow to the identified nodes, wherein this activity tries to match functional and non-functional task requirements to discovered and ranked devices, wherein Pg. 5 teaches the ontology includes dia-cec:Device is introduced to represent an edge device characterized by its functional and non-functional properties, wherein it is further subclassed into dia-cec:SensingDevice and dia-cec:ActuatingDevice, wherein dia-cec:hasVolume, dia-cec:hasVelocity, and dia-cec:hasVariety are data properties used to quantitatively express non-functional properties of edge devices in terms of the volume, velocity, and variety metrics, respectively), and
the "using and used" mapping is provided between the task and the skill (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein the selection step groups the discovered nodes according to matching tasks, and ranks them based on their non-functional properties, thereby selecting the best suitable nodes, wherein mapping finalizes the selection process and aims to allocate the DIA workflow to the identified nodes, wherein this activity tries to match functional and non-functional task requirements to discovered and ranked devices, wherein Pg. 5 teaches the ontology includes dia-cec:Task is used to represent an atomic processing step within a workflow– an acyclic pipeline of tasks, wherein when mapped to cluster nodes, tasks may either run in parallel on multiple nodes, or as a stand-alone process on a single node. The former applies to usual data processing operations executed on worker nodes, whereas the latter typically refers to sensing nodes that act as data stream sources within a workflow topology, wherein dia-cec:SuitableDevice is another dia-cec:Device subclass that serves to express task requirements that have be satisfied by a device in order to be classified as suitable for a given task, wherein these two types of requirements are expressed using FunctionalProperty and NonFunctionalProperty, respectively; see also: Pgs. 1-2, 8); and
using the current requirement entity as a keyword to search the determinate mappings comprises using the current use case or the current task of the current use case as a keyword to search the determinate mappings to obtain at least one candidate edge application providing a skill used by the current use case or the current task of the current use case (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein the selection step groups the discovered nodes according to matching tasks, and ranks them based on their non-functional properties, thereby selecting the best suitable nodes, wherein mapping finalizes the selection process and aims to allocate the DIA workflow to the identified nodes, wherein this activity tries to match functional and non-functional task requirements to discovered and ranked devices, aiming to minimize the number of nodes involved, in this way, a waiting list of spare available nodes is maintained to handle a node churn, wherein the task nodes are mapped in order to perform functional match making through semantic discovery, as well as in Pgs. 6-7, teach the translation from a workflow process specification to the DIA-CEC ontology is performed by the Frontend, wherein the responsibility of the Reasoner in the proposed system is to perform match making between task requirements and device properties, wherein Pg. 5 teaches the DIA-CEC knowledge base includes dia-cec:Task that is used to represent an atomic processing step within a workflow– an acyclic pipeline of tasks, wherein when mapped to cluster nodes, tasks may either run in parallel on multiple nodes, or as a stand-alone process on a single node. The former applies to usual data processing operations executed on worker nodes, whereas the latter typically refers to sensing nodes that act as data stream sources within a workflow topology, wherein dia-cec:SuitableDevice is another dia-cec:Device subclass that serves to express task requirements that have be satisfied by a device in order to be classified as suitable for a given task, wherein is further subclassed into dia-cec: FunctionallySuitableDevice to express software (e.g. specific components, libraries, middleware, etc.) and hardware (e.g. the traditional CPU, RAM, GPU, HDD, and Networking, as well as the IoT-related Sensing and Actuating resources, Power and Location) requirements, and NonFunctionallySuitableDevice to quantitatively ex press the volume, velocity, and variety metrics of data processing involved in the given task, wherein these two types of requirements are expressed using FunctionalProperty and NonFunctionalProperty, respectively, , wherein Pg. 7 teaches the grouping operation looks for tasks with identical functional requirements within a workflow and groups them together, wherein the system can checked for subsequent tasks following given tasks, wherein the tasks include DetectFace, RecogniseFace, or alternatively DetectLicensePlate and RecogniseLicensePlate, as well as in Pgs. 11-12 teach searching for network devices matching specific query parameters through the use of semantic modeling that describes all involved system elements using the same semantic vocabulary, thereby minimizing the semantic heterogeneity between them; see also: Pgs. 1, 5, 8-10).
Regarding claim 3, the combination of Dautov and Zhu teaches all the limitations of claim 2 above.
Dautov wherein: using the current use case as a keyword to search the determinate mappings comprise searching for edge applications which meet the following conditions (Pgs. 2-3, “2.1-2.2” teach the Intelligent Surveillance System scenario has applications including recognizing human faces and license plates in outdoor locations, wherein the CEC processing model assumes that the DIA workflow tasks are executed by various edge devices present in the environment, wherein edge devices have many capabilities that must be specified as a requirement for a given workflow, wherein Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein the selection step groups the discovered nodes according to matching tasks, and ranks them based on their non-functional properties, thereby selecting the best suitable nodes, wherein mapping finalizes the selection process and aims to allocate the DIA workflow to the identified nodes, wherein this activity tries to match functional and non-functional task requirements to discovered and ranked devices, wherein Pg. 7 teaches the grouping operation looks for tasks with identical functional requirements within a workflow and groups them together, wherein the system can checked for subsequent tasks following given tasks, wherein the tasks include DetectFace, RecogniseFace, or alternatively DetectLicensePlate and RecogniseLicensePlate; see also: Pgs. 5-6, 11-12):
the edge applications provide the skills (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein Pg. 5 teaches the ontology includes Pg. 5 teaches the ontology includes dia-cec:Device is introduced to represent an edge device characterized by its functional and non-functional properties. It is further subclassed into dia-cec:SensingDevice and dia-cec:ActuatingDevice, wherein dia-cec:hasVolume, dia-cec:hasVelocity, and dia-cec:hasVariety are data properties used to quantitatively express non-functional properties of edge devices in terms of the volume, velocity, and variety metrics, respectively; see also: Pgs. 2, 11-12), and
the skills are used by the tasks (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein Pg. 5 teaches the ontology includes dia-cec:Task is used to represent an atomic processing step within a workflow– an acyclic pipeline of tasks. When mapped to cluster nodes, tasks may either run in parallel on multiple nodes, or as a stand-alone process on a single node. The former applies to usual data processing operations executed on worker nodes, whereas the latter typically refers to sensing nodes that act as data stream sources within a workflow topology, wherein dia-cec:SuitableDevice is another dia-cec:Device subclass that serves to express task requirements that have be satisfied by a device in order to be classified as suitable for a given task. It is further subclassed into dia-cec:FunctionallySuitableDevice to express software (e.g. specific components, libraries, middleware, etc.) and hardware (e.g. the traditional CPU, RAM, GPU, HDD, and Networking, as well as the IoT-related Sensing and Actuating resources, Power and Location) requirements, and NonFunctionallySuitableDevice to quantitatively ex press the volume, velocity, and variety metrics of data processing involved in the given task, wherein these two types of requirements are expressed using FunctionalProperty and NonFunctionalProperty, respectively, wherein Pg. 7 teaches the grouping operation looks for tasks with identical functional requirements within a workflow and groups them together, wherein the system can checked for subsequent tasks following given tasks, wherein the tasks include DetectFace, RecogniseFace, or alternatively DetectLicensePlate and RecogniseLicensePlate; see also: Pgs. 2, 11-12),
and the tasks are included in the current use case (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein Pg. 5 teaches the ontology includes dia-cec:hasTask serves to hierarchically associate one task with another, thereby representing an overall workflow, wherein the subject of this property represents an overall DIA workflow, whereas the object represents a specific atomic task constituting the workflow, as well as dia-cec:Task is used to represent an atomic processing step within a workflow– an acyclic pipeline of tasks. When mapped to cluster nodes, tasks may either run in parallel on multiple nodes, or as a stand-alone process on a single node. The former applies to usual data processing operations executed on worker nodes, whereas the latter typically refers to sensing nodes that act as data stream sources within a workflow topology, wherein Pg. 7 teaches the grouping operation looks for tasks with identical functional requirements within a workflow and groups them together, wherein the system can checked for subsequent tasks following given tasks, wherein the tasks include DetectFace, RecogniseFace, or alternatively DetectLicensePlate and RecogniseLicensePlate; see also: Pgs. 2, 11-12), and
using the current task of the current use case as a keyword to search the determinate mappings comprises searching for edge applications which meet the following conditions (Pgs. 2-3, “2.1-2.2” teach the Intelligent Surveillance System scenario has applications including recognizing human faces and license plates in outdoor locations, wherein the CEC processing model assumes that the DIA workflow tasks are executed by various edge devices present in the environment, wherein edge devices have many capabilities that must be specified as a requirement for a given workflow, wherein Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein the selection step groups the discovered nodes according to matching tasks, and ranks them based on their non-functional properties, thereby selecting the best suitable nodes, wherein mapping finalizes the selection process and aims to allocate the DIA workflow to the identified nodes, wherein this activity tries to match functional and non-functional task requirements to discovered and ranked devices, wherein Pg. 7 teaches the grouping operation looks for tasks with identical functional requirements within a workflow and groups them together, wherein the system can checked for subsequent tasks following given tasks, wherein the tasks include DetectFace, RecogniseFace, or alternatively DetectLicensePlate and RecogniseLicensePlate; see also: Pgs. 5-6, 11-12):
the edge applications provide the skills (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein Pg. 5 teaches the ontology includes Pg. 5 teaches the ontology includes dia-cec:Device is introduced to represent an edge device characterized by its functional and non-functional properties. It is further subclassed into dia-cec:SensingDevice and dia-cec:ActuatingDevice, wherein dia-cec:hasVolume, dia-cec:hasVelocity, and dia-cec:hasVariety are data properties used to quantitatively express non-functional properties of edge devices in terms of the volume, velocity, and variety metrics, respectively; see also: Pgs. 2, 11-12), and
the skills are used by the current task (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein Pg. 5 teaches the ontology includes dia-cec:Task is used to represent an atomic processing step within a workflow– an acyclic pipeline of tasks. When mapped to cluster nodes, tasks may either run in parallel on multiple nodes, or as a stand-alone process on a single node. The former applies to usual data processing operations executed on worker nodes, whereas the latter typically refers to sensing nodes that act as data stream sources within a workflow topology, wherein dia-cec:SuitableDevice is another dia-cec:Device subclass that serves to express task requirements that have be satisfied by a device in order to be classified as suitable for a given task. It is further subclassed into dia-cec:FunctionallySuitableDevice to express software (e.g. specific components, libraries, middleware, etc.) and hardware (e.g. the traditional CPU, RAM, GPU, HDD, and Networking, as well as the IoT-related Sensing and Actuating resources, Power and Location) requirements, and NonFunctionallySuitableDevice to quantitatively ex press the volume, velocity, and variety metrics of data processing involved in the given task, wherein these two types of requirements are expressed using FunctionalProperty and NonFunctionalProperty, respectively, wherein Pg. 7 teaches the grouping operation looks for tasks with identical functional requirements within a workflow and groups them together, wherein the system can checked for subsequent tasks following given tasks, wherein the tasks include DetectFace, RecogniseFace, or alternatively DetectLicensePlate and RecogniseLicensePlate; see also: Pgs. 2, 11-12), and
the current task is included in the current use case (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein Pg. 5 teaches the ontology includes dia-cec:hasTask serves to hierarchically associate one task with another, thereby representing an overall workflow, wherein the subject of this property represents an overall DIA workflow, whereas the object represents a specific atomic task constituting the workflow, as well as dia-cec:Task is used to represent an atomic processing step within a workflow– an acyclic pipeline of tasks. When mapped to cluster nodes, tasks may either run in parallel on multiple nodes, or as a stand-alone process on a single node. The former applies to usual data processing operations executed on worker nodes, whereas the latter typically refers to sensing nodes that act as data stream sources within a workflow topology, wherein Pg. 7 teaches the grouping operation looks for tasks with identical functional requirements within a workflow and groups them together, wherein the system can checked for subsequent tasks following given tasks, wherein the tasks include DetectFace, RecogniseFace, or alternatively DetectLicensePlate and RecogniseLicensePlate; see also: Pgs. 2, 11-12).
Regarding claims 4 and 11, the combination of Dautov and Zhu teaches all the limitations of claims 1 and 9 above.
Dautov further teaches wherein: each said requirement entity comprises a use case and a task (Pg. 3, “2.2” teaches the Intelligent Surveillance System scenario has applications including recognizing human faces and license plates in outdoor locations, wherein Pg. 7 teaches the grouping operation looks for tasks with identical functional requirements within a workflow and groups them together, wherein the system can checked for subsequent tasks following given tasks, wherein the tasks include DetectFace, RecogniseFace, or alternatively DetectLicensePlate and RecogniseLicensePlate; see also: Pg. 5);
each said workflow entity comprises a functional block and a device (Pg. 3, “2.2” teaches the Intelligent Surveillance System scenario has applications including recognizing human faces and license plates in outdoor locations, wherein Pg. 7 teaches the grouping operation looks for tasks with identical functional requirements within a workflow and groups them together, wherein the system can checked for subsequent tasks following given tasks, wherein the tasks include DetectFace, RecogniseFace, or alternatively DetectLicensePlate and RecogniseLicensePlate, wherein Pg. 5 teaches the ontology includes dia-cec:Device is introduced to represent an edge device characterized by its functional and non-functional properties, wherein it is further subclassed into dia-cec:SensingDevice and dia-cec:ActuatingDevice, wherein dia-cec:hasVolume, dia-cec:hasVelocity, and dia-cec:hasVariety are data properties used to quantitatively express non-functional properties of edge devices in terms of the volume, velocity, and variety metrics, respectively, and wherein ssn:Property is a class used to represent any functional (dia-cec:FunctionalProperty) and non-functional (dia-cec:NonFunctionalProperty) property of an edge device; see also: Pg. 6); and
the current requirement entity comprises a current use case or a current task of a current use case (Pg. 3, “2.2” teaches the Intelligent Surveillance System scenario has applications including recognizing human faces and license plates in outdoor locations, wherein Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein the selection step groups the discovered nodes according to matching tasks, and ranks them based on their non-functional properties, thereby selecting the best suitable nodes, wherein mapping finalizes the selection process and aims to allocate the DIA workflow to the identified nodes, wherein this activity tries to match functional and non-functional task requirements to discovered and ranked devices, wherein Pg. 7 teaches the grouping operation looks for tasks with identical functional requirements within a workflow and groups them together, wherein the system can checked for subsequent tasks following given tasks, wherein the tasks include DetectFace, RecogniseFace, or alternatively DetectLicensePlate and RecogniseLicensePlate; see also: Pg. 5);
in the determinate mapping, a "comprising and comprised" mapping is provided between a use case representing a requirement entity and a task comprised in the use case (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein the selection step groups the discovered nodes according to matching tasks, and ranks them based on their non-functional properties, thereby selecting the best suitable nodes, wherein mapping finalizes the selection process and aims to allocate the DIA workflow to the identified nodes, wherein this activity tries to match functional and non-functional task requirements to discovered and ranked devices, wherein Pg. 5 teaches the ontology includes dia-cec:hasTask serves to hierarchically associate one task with another, thereby representing an overall workflow, wherein the subject of this property represents an overall DIA workflow, whereas the object represents a specific atomic task constituting the workflow, wherein Pg. 7 teaches the grouping operation looks for tasks with identical functional requirements within a workflow and groups them together, wherein the system can checked for subsequent tasks following given tasks, wherein the tasks include DetectFace, RecogniseFace, or alternatively DetectLicensePlate and RecogniseLicensePlate; see also: Pgs. 6, 12),
a "supporting and supported" mapping is provided between a functional block representing a workflow entity and a device supported by the functional block (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein the selection step groups the discovered nodes according to matching tasks, and ranks them based on their non-functional properties, thereby selecting the best suitable nodes, wherein mapping finalizes the selection process and aims to allocate the DIA workflow to the identified nodes, wherein this activity tries to match functional and non-functional task requirements to discovered and ranked devices, wherein Pg. 5 teaches the ontology includes dia-cec:Device is introduced to represent an edge device characterized by its functional and non-functional properties, wherein it is further subclassed into dia-cec:SensingDevice and dia-cec:ActuatingDevice, wherein dia-cec:hasVolume, dia-cec:hasVelocity, and dia-cec:hasVariety are data properties used to quantitatively express non-functional properties of edge devices in terms of the volume, velocity, and variety metrics, respectively, wherein ssn:Property is a class used to represent any functional (dia-cec:FunctionalProperty) and non-functional (dia-cec:NonFunctionalProperty) property of an edge device), and
the "using and used" mapping is provided between the task and the device (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein the selection step groups the discovered nodes according to matching tasks, and ranks them based on their non-functional properties, thereby selecting the best suitable nodes, wherein mapping finalizes the selection process and aims to allocate the DIA workflow to the identified nodes, wherein this activity tries to match functional and non-functional task requirements to discovered and ranked devices, wherein Pg. 5 teaches the ontology includes dia-cec:Task is used to represent an atomic processing step within a workflow– an acyclic pipeline of tasks, wherein when mapped to cluster nodes, tasks may either run in parallel on multiple nodes, or as a stand-alone process on a single node. The former applies to usual data processing operations executed on worker nodes, whereas the latter typically refers to sensing nodes that act as data stream sources within a workflow topology, wherein dia-cec:SuitableDevice is another dia-cec:Device subclass that serves to express task requirements that have be satisfied by a device in order to be classified as suitable for a given task, wherein these two types of requirements are expressed using FunctionalProperty and NonFunctionalProperty, respectively; see also: Pgs. 1-2, 8);
using the current requirement entity as a keyword to search the determinate mappings to obtain a workflow entity comprises using the current use case or the current task of the current use case as a keyword to search the determinate mappings to obtain at least one candidate functional block supporting a device used by the current use case or the current task of the current use case (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein the selection step groups the discovered nodes according to matching tasks, and ranks them based on their non-functional properties, thereby selecting the best suitable nodes, wherein mapping finalizes the selection process and aims to allocate the DIA workflow to the identified nodes, wherein this activity tries to match functional and non-functional task requirements to discovered and ranked devices, aiming to minimize the number of nodes involved, in this way, a waiting list of spare available nodes is maintained to handle a node churn, wherein the task nodes are mapped in order to perform functional match making through semantic discovery, as well as in Pgs. 6-7, teach the translation from a workflow process specification to the DIA-CEC ontology is performed by the Frontend, wherein the responsibility of the Reasoner in the proposed system is to perform match making between task requirements and device properties, wherein Pg. 5 teaches the DIA-CEC knowledge base includes ssn:Property is a class used to represent any functional (dia-cec:FunctionalProperty) and non-functional (dia-cec:NonFunctionalProperty) property of an edge device, wherein dia-cec:Task that is used to represent an atomic processing step within a workflow– an acyclic pipeline of tasks, wherein when mapped to cluster nodes, tasks may either run in parallel on multiple nodes, or as a stand-alone process on a single node. The former applies to usual data processing operations executed on worker nodes, whereas the latter typically refers to sensing nodes that act as data stream sources within a workflow topology, wherein dia-cec:SuitableDevice is another dia-cec:Device subclass that serves to express task requirements that have be satisfied by a device in order to be classified as suitable for a given task, wherein is further subclassed into dia-cec: FunctionallySuitableDevice to express software (e.g. specific components, libraries, middleware, etc.) and hardware (e.g. the traditional CPU, RAM, GPU, HDD, and Networking, as well as the IoT-related Sensing and Actuating resources, Power and Location) requirements, and NonFunctionallySuitableDevice to quantitatively ex press the volume, velocity, and variety metrics of data processing involved in the given task, wherein these two types of requirements are expressed using FunctionalProperty and NonFunctionalProperty, respectively, wherein Pg. 7 teaches the grouping operation looks for tasks with identical functional requirements within a workflow and groups them together, wherein the system can checked for subsequent tasks following given tasks, wherein the tasks include DetectFace, RecogniseFace, or alternatively DetectLicensePlate and RecogniseLicensePlate, as well as in Pgs. 11-12 teach searching for network devices matching specific query parameters through the use of semantic modeling that describes all involved system elements using the same semantic vocabulary, thereby minimizing the semantic heterogeneity between them; see also: Pgs. 1, 5, 8-10).
Regarding claim 5, the combination of Dautov and Zhu teaches all the limitations of claim 4 above.
Dautov further teaches wherein: using the current use case as a keyword to search the determinate mappings comprises searching for any functional blocks which meet the following conditions (Pgs. 2-3, “2.1-2.2” teach the Intelligent Surveillance System scenario has applications including recognizing human faces and license plates in outdoor locations, wherein the CEC processing model assumes that the DIA workflow tasks are executed by various edge devices present in the environment, wherein edge devices have many capabilities that must be specified as a requirement for a given workflow, wherein Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein the selection step groups the discovered nodes according to matching tasks, and ranks them based on their non-functional properties, thereby selecting the best suitable nodes, wherein mapping finalizes the selection process and aims to allocate the DIA workflow to the identified nodes, wherein this activity tries to match functional and non-functional task requirements to discovered and ranked devices, wherein Pg. 7 teaches the grouping operation looks for tasks with identical functional requirements within a workflow and groups them together, wherein the system can checked for subsequent tasks following given tasks, wherein the tasks include DetectFace, RecogniseFace, or alternatively DetectLicensePlate and RecogniseLicensePlate; see also: Pgs. 5-6, 11-12):
the functional blocks support the devices (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein Pg. 5 teaches the ontology includes Pg. 5 teaches the ontology includes dia-cec:Device is introduced to represent an edge device characterised by its functional and non-functional properties. It is further subclassed into dia-cec:SensingDevice and dia-cec:ActuatingDevice, wherein dia-cec:hasVolume, dia-cec:hasVelocity, and dia-cec:hasVariety are data properties used to quantitatively express non-functional properties of edge devices in terms of the volume, velocity, and variety metrics, respectively, wherein ssn:Property is a class used to represent any functional (dia-cec:FunctionalProperty) and non-functional (dia-cec:NonFunctionalProperty) property of an edge device; see also: Pgs. 2, 11-12), and
the devices are used by the tasks (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein Pg. 5 teaches the ontology includes dia-cec:Device is introduced to represent an edge device characterised by its functional and non-functional properties. It is further subclassed into dia-cec:SensingDevice and dia-cec:ActuatingDevice, wherein dia-cec:hasTask serves to hierarchically associate one task with another, thereby representing an overall workflow, wherein the subject of this property represents an overall DIA workflow, whereas the object represents a specific atomic task constituting the workflow, as well as dia-cec:Task is used to represent an atomic processing step within a workflow– an acyclic pipeline of tasks. When mapped to cluster nodes, tasks may either run in parallel on multiple nodes, or as a stand-alone process on a single node. The former applies to usual data processing operations executed on worker nodes, whereas the latter typically refers to sensing nodes that act as data stream sources within a workflow topology, wherein Pg. 7 teaches the grouping operation looks for tasks with identical functional requirements within a workflow and groups them together, wherein the system can checked for subsequent tasks following given tasks, wherein the tasks include DetectFace, RecogniseFace, or alternatively DetectLicensePlate and RecogniseLicensePlate; see also: Pgs. 2, 11-12), and
the tasks are included in the current use case (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein Pg. 5 teaches the ontology includes dia-cec:hasTask serves to hierarchically associate one task with another, thereby representing an overall workflow, wherein the subject of this property represents an overall DIA workflow, whereas the object represents a specific atomic task constituting the workflow, as well as dia-cec:Task is used to represent an atomic processing step within a workflow– an acyclic pipeline of tasks. When mapped to cluster nodes, tasks may either run in parallel on multiple nodes, or as a stand-alone process on a single node. The former applies to usual data processing operations executed on worker nodes, whereas the latter typically refers to sensing nodes that act as data stream sources within a workflow topology, wherein Pg. 7 teaches the grouping operation looks for tasks with identical functional requirements within a workflow and groups them together, wherein the system can checked for subsequent tasks following given tasks, wherein the tasks include DetectFace, RecogniseFace, or alternatively DetectLicensePlate and RecogniseLicensePlate; see also: Pgs. 2, 11-12); and
using the current task of the current use case as a keyword to search the determinate mappings comprises searching for functional blocks which meet the following conditions (Pgs. 2-3, “2.1-2.2” teach the Intelligent Surveillance System scenario has applications including recognizing human faces and license plates in outdoor locations, wherein the CEC processing model assumes that the DIA workflow tasks are executed by various edge devices present in the environment, wherein edge devices have many capabilities that must be specified as a requirement for a given workflow, wherein Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein the selection step groups the discovered nodes according to matching tasks, and ranks them based on their non-functional properties, thereby selecting the best suitable nodes, wherein mapping finalizes the selection process and aims to allocate the DIA workflow to the identified nodes, wherein this activity tries to match functional and non-functional task requirements to discovered and ranked devices, wherein Pg. 7 teaches the grouping operation looks for tasks with identical functional requirements within a workflow and groups them together, wherein the system can checked for subsequent tasks following given tasks, wherein the tasks include DetectFace, RecogniseFace, or alternatively DetectLicensePlate and RecogniseLicensePlate; see also: Pgs. 5-6, 11-12):
the functional blocks support the devices (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein Pg. 5 teaches the ontology includes Pg. 5 teaches the ontology includes dia-cec:Device is introduced to represent an edge device characterised by its functional and non-functional properties. It is further subclassed into dia-cec:SensingDevice and dia-cec:ActuatingDevice, wherein dia-cec:hasVolume, dia-cec:hasVelocity, and dia-cec:hasVariety are data properties used to quantitatively express non-functional properties of edge devices in terms of the volume, velocity, and variety metrics, respectively, wherein ssn:Property is a class used to represent any functional (dia-cec:FunctionalProperty) and non-functional (dia-cec:NonFunctionalProperty) property of an edge device; see also: Pgs. 2, 11-12), and
the devices are used by the current task (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein Pg. 5 teaches the ontology includes dia-cec:Device is introduced to represent an edge device characterised by its functional and non-functional properties. It is further subclassed into dia-cec:SensingDevice and dia-cec:ActuatingDevice, wherein dia-cec:hasTask serves to hierarchically associate one task with another, thereby representing an overall workflow, wherein the subject of this property represents an overall DIA workflow, whereas the object represents a specific atomic task constituting the workflow, as well as dia-cec:Task is used to represent an atomic processing step within a workflow– an acyclic pipeline of tasks. When mapped to cluster nodes, tasks may either run in parallel on multiple nodes, or as a stand-alone process on a single node. The former applies to usual data processing operations executed on worker nodes, whereas the latter typically refers to sensing nodes that act as data stream sources within a workflow topology, wherein Pg. 7 teaches the grouping operation looks for tasks with identical functional requirements within a workflow and groups them together, wherein the system can checked for subsequent tasks following given tasks, wherein the tasks include DetectFace, RecogniseFace, or alternatively DetectLicensePlate and RecogniseLicensePlate; see also: Pgs. 2, 11-12), and
the current task is included in the current use case (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein Pg. 5 teaches the ontology includes dia-cec:hasTask serves to hierarchically associate one task with another, thereby representing an overall workflow, wherein the subject of this property represents an overall DIA workflow, whereas the object represents a specific atomic task constituting the workflow, as well as dia-cec:Task is used to represent an atomic processing step within a workflow– an acyclic pipeline of tasks. When mapped to cluster nodes, tasks may either run in parallel on multiple nodes, or as a stand-alone process on a single node. The former applies to usual data processing operations executed on worker nodes, whereas the latter typically refers to sensing nodes that act as data stream sources within a workflow topology, wherein Pg. 7 teaches the grouping operation looks for tasks with identical functional requirements within a workflow and groups them together, wherein the system can checked for subsequent tasks following given tasks, wherein the tasks include DetectFace, RecogniseFace, or alternatively DetectLicensePlate and RecogniseLicensePlate; see also: Pgs. 2, 11-12).
Regarding claim 6, the combination of Dautov and Zhu teaches all the limitations of claim 4 above.
Dautov further teaches further comprising upon determining, after using the current requirement entity as a keyword to search the determinate mappings, that the current requirement entity is not in the determinate mappings:
mapping the current requirement entity to an existing workflow entity or a new workflow entity, forming a new mapping record, and updating the determinate mappings with the new mapping record (Pg. 13 teaches the OWL ontology can be seamlessly extended with new concepts without breaking the integrity of the existing knowledge base and already existing queries, wherein Pg. 4 teaches the deployment and orchestration step finally establishes the edge cluster, provided that a feasible mapping solution is found, and deploys corresponding tasks on participating nodes, wherein otherwise, it restarts the algorithm from the discovery step to enroll new available devices that can replace missing ones, wherein if one or more tasks cannot be assigned available nodes, no feasible mapping solution for deployment can be identified, wherein two options are thus proposed in Fig. 2, either i) retry the node discovery, or ii) to completely restart the process from the design step, wherein in the latter case, the information from the discovery step, i.e. the sets of available nodes categorized by their functional property, are sent back to the Architect, who is then required to re-design the workflow, wherein the re-design should take into account the underlying CEC infrastructure and may range from local changes of non-functional task requirements to global modifications of the overall DIA logic, wherein in this activity, the Architect can also resort to Fog or Cloud Computing resources for computational task offloading, even combining both CEC and Fog/Cloud offloading patterns, wherein the DIA-CEC knowledge base facilitates seamless information exchange and interoperability between individual steps, wherein the common semantic vocabulary is required to define task requirements and device self-descriptions, as well as policies for matching-matching, task grouping, and aggregation, wherein as an outcome of the design process, the Architect generates an enhanced workflow definition that contains custom annotations specifying individual task requirements, wherein the Architect can upload the extended workload configuration to the available edge node in order to initiate the discovery, selection, and integration into a cluster for further task allocation and collaborative data processing, wherein Pg. 6 teaches the Architect provides an extended workflow definition for parsing that can be parsed to identify individual tasks constituting the workflow and translates this description in OWL, wherein class equivalence can be used to define classes in terms of object and data property constraints, wherein if the network discovery and semantic discovery is unsuccessful, this will trigger a non-functional property driven selection and mapping operation, wherein Pg. 5 teaches the high-level models collectively provide a vocabulary to describe IoT devices, as well as their sensing and actuating capabilities, wherein the DIA-CEC domain requires these ontological models to be extended with concepts relevant to the proposed clusterization process including functional and non-functional task requirements and device properties, wherein Pg. 10 teaches the system can provide feedback to the Architect to change the workflow design, wherein as a result, a given task may be changed into two new tasks, such as DetectObject and RecognizeObject, wherein multiple iterations can be performed to provide a feasible task allocation; see also: Pgs. 2, 7, 11-12).
Regarding claim 9, Dautov teaches a workflow recommendation device comprising (Pgs. 3-4):
a memory storing instructions (Pg. 2 teaches utilizing a NiFi interface to enable faster DIA workflow design, as well as Pg. 4 teaches the Frontend provides an interface for the Architect to interact with the clustered node edges, wherein Pg. 10 teaches the DIA architect can access the initiator’s NiFi web interface in order to design a workflow topology); and
at least one processor configured to execute the instructions to (Pg. 2 teaches utilizing a NiFi interface to enable faster DIA workflow design, as well as Pg. 4 teaches the Frontend provides an interface for the Architect to interact with the clustered node edges, wherein Pg. 10 teaches the DIA architect can access the initiator’s NiFi web interface in order to design a workflow topology):
receive a current requirement entity (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, as well as in Pgs. 6-7, teach utilizing the Frontend to receive an input workflow definition and parsing the file to identify tasks constituting the workflow, along with the functional and non-functional requirements, and translating this definition to OWL, wherein this translation from a workflow process specification to the DIA-CEC ontology is performed by the Frontend, wherein “6, Semantic Reasoner” teaches a semantic reasoner is a software component able to infer logical consequences from the asserted facts or axioma, wherein the inference rules are specified by means of OWL in the DIA-CEC ontology, wherein the responsibility of the Reasoner in the proposed system is to perform match making between task requirements and device properties, wherein one can programmatically invoke the Reasoner and manipulate the DIA-CEC ontology using the OWL API, as well as in Pgs. 11-12 teach searching for network devices matching specific query parameters through the use of semantic modeling that describes all involved system elements using the same semantic vocabulary, thereby minimizing the semantic heterogeneity between them; see also: Pgs. 1, 5, 10),
provide the current requirement entity to the workflow entity search module (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, as well as in Pgs. 6-7, teach utilizing the Frontend to receive an input workflow definition and parsing the file to identify tasks constituting the workflow, along with the functional and non-functional requirements, and translating this definition to OWL, wherein this translation from a workflow process specification to the DIA-CEC ontology is performed by the Frontend, wherein “6, Semantic Reasoner” teaches a semantic reasoner is a software component able to infer logical consequences from the asserted facts or axioma, wherein the inference rules are specified by means of OWL in the DIA-CEC ontology, wherein the responsibility of the Reasoner in the proposed system is to perform match making between task requirements and device properties, wherein one can programmatically invoke the Reasoner and manipulate the DIA-CEC ontology using the OWL API, as well as in Pgs. 11-12 teach searching for network devices matching specific query parameters through the use of semantic modeling that describes all involved system elements using the same semantic vocabulary, thereby minimizing the semantic heterogeneity between them; see also: Pgs. 1, 5, 10), and
based on a pre-established determinate mapping between each requirement entity and each workflow entity, search the determinate mappings using the current requirement entity as a keyword to obtain at least one candidate workflow entity (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein the selection step groups the discovered nodes according to matching tasks, and ranks them based on their non-functional properties, thereby selecting the best suitable nodes, wherein mapping finalizes the selection process and aims to allocate the DIA workflow to the identified nodes, wherein this activity tries to match functional and non-functional task requirements to discovered and ranked devices, aiming to minimize the number of nodes involved, in this way, a waiting list of spare available nodes is maintained to handle a node churn, wherein the task nodes are mapped in order to perform functional match making through semantic discovery, as well as in Pgs. 6-7, teach the translation from a workflow process specification to the DIA-CEC ontology is performed by the Frontend, wherein the responsibility of the Reasoner in the proposed system is to perform match making between task requirements and device properties, wherein one can programmatically invoke the Reasoner and manipulate the DIA-CEC ontology using the OWL API, wherein Pgs. 8-9 teach mapping follows the decomposition, discovery, and selection steps and finally allocates the DIA tasks to CEC nodes, wherein it is driven by the requirement to minimize the number of involved nodes in order to reserve spare nodes, wherein mapping is considered an optimization problem, as well as in Pgs. 11-12 teach searching for network devices matching specific query parameters through the use of semantic modeling that describes all involved system elements using the same semantic vocabulary, thereby minimizing the semantic heterogeneity between them; see also: Pgs. 1, 5, 10),
where a determinate mapping has been established between this at least one candidate workflow entity and the current requirement entity (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein the selection step groups the discovered nodes according to matching tasks, and ranks them based on their non-functional properties, thereby selecting the best suitable nodes, wherein mapping finalizes the selection process and aims to allocate the DIA workflow to the identified nodes, wherein this activity tries to match functional and non-functional task requirements to discovered and ranked devices, aiming to minimize the number of nodes involved, in this way, a waiting list of spare available nodes is maintained to handle a node churn, wherein the task nodes are mapped in order to perform functional match making through semantic discovery, as well as in Pgs. 6-7, teach the translation from a workflow process specification to the DIA-CEC ontology is performed by the Frontend, wherein the responsibility of the Reasoner in the proposed system is to perform match making between task requirements and device properties, wherein one can programmatically invoke the Reasoner and manipulate the DIA-CEC ontology using the OWL API, wherein Pgs. 8-9 teach mapping follows the decomposition, discovery, and selection steps and finally allocates the DIA tasks to CEC nodes, wherein it is driven by the requirement to minimize the number of involved nodes in order to reserve spare nodes, wherein mapping is considered an optimization problem, as well as in Pgs. 11-12 teach searching for network devices matching specific query parameters through the use of semantic modeling that describes all involved system elements using the same semantic vocabulary, thereby minimizing the semantic heterogeneity between them; see also: Pgs. 1, 5, 10), and
provide the at least one candidate workflow entity (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein the selection step groups the discovered nodes according to matching tasks, and ranks them based on their non-functional properties, thereby selecting the best suitable nodes, wherein mapping finalizes the selection process and aims to allocate the DIA workflow to the identified nodes, wherein this activity tries to match functional and non-functional task requirements to discovered and ranked devices, aiming to minimize the number of nodes involved, in this way, a waiting list of spare available nodes is maintained to handle a node churn, wherein the task nodes are mapped in order to perform functional match making through semantic discovery, as well as in Pgs. 6-7, teach the translation from a workflow process specification to the DIA-CEC ontology is performed by the Frontend, wherein the responsibility of the Reasoner in the proposed system is to perform match making between task requirements and device properties, wherein one can programmatically invoke the Reasoner and manipulate the DIA-CEC ontology using the OWL API, wherein Pgs. 8-9 teach mapping follows the decomposition, discovery, and selection steps and finally allocates the DIA tasks to CEC nodes, wherein it is driven by the requirement to minimize the number of involved nodes in order to reserve spare nodes, wherein mapping is considered an optimization problem, as well as in Pgs. 11-12 teach searching for network devices matching specific query parameters through the use of semantic modeling that describes all involved system elements using the same semantic vocabulary, thereby minimizing the semantic heterogeneity between them; see also: Pgs. 1, 5, 10);
in the determinate mapping, establish a connection between the requirement entity and the corresponding workflow entity with a "using and used” mapping (Pgs. 3-4, “3.1” teach the allocation of DIA workflows to CEC infrastructures can be split into steps including discovery related to performing queries based on functional task properties expressed using the DIA-CEC ontology, wherein the Frontend is used for discovery using a semantic Reasoner that manages the request by parsing and translating it into Semantic Web languages, wherein the selection step groups the discovered nodes according to matching tasks, and ranks them based on their non-functional properties, thereby selecting the best suitable nodes, wherein mapping finalizes the selection process and aims to allocate the DIA workflow to the identified nodes, wherein this activity tries to match functional and non-functional task requirements to discovered and ranked devices, aiming to minimize the number of nodes involved, in this way, a waiting list of spare available nodes is maintained to handle a node churn, wherein the task nodes are mapped in order to perform functional match making through semantic discovery, as well as in Pgs. 6-7, teach the translation from a workflow process specification to the DIA-CEC ontology is performed by the Frontend, wherein the responsibility of the Reasoner in the proposed system is to perform match making between task requirements and device properties, wherein one can programmatically invoke the Reasoner and manipulate the DIA-CEC ontology using the OWL API, wherein Pg. 5 teaches the DIA-CEC knowledge base includes dia-cec:Task that is used to represent an atomic processing step within a workflow– an acyclic pipeline of tasks, wherein when mapped to cluster nodes, tasks may either run in parallel on multiple nodes, or as a stand-alone process on a single node. The former applies to usual data processing operations executed on worker nodes, whereas the latter typically refers to sensing nodes that act as data stream sources within a workflow topology, wherein dia-cec:SuitableDevice is another dia-cec:Device subclass that serves to express task requirements that have be satisfied by a device in order to be classified as suitable for a given task, wherein is further subclassed into dia-cec: FunctionallySuitableDevice to express software (e.g. specific components, libraries, middleware, etc.) and hardware (e.g. the traditional CPU, RAM, GPU, HDD, and Networking, as well as the IoT-related Sensing and Actuating resources, Power and Location) requirements, and NonFunctionallySuitableDevice to quantitatively ex press the volume, velocity, and variety metrics of data processing involved in the given task, wherein these two types of requirements are expressed using FunctionalProperty and NonFunctionalProperty, respectively, as well as in Pgs. 11-12 teach searching for network devices matching specific query parameters through the use of semantic modeling that describes all involved system elements using the same semantic vocabulary, thereby minimizing the semantic heterogeneity between them; see also: Pgs. 1, 5, 8-10).
However, Dautov does not explicitly teach recommend a candidate workflow entity from the workflow search module.
From the same or similar field of endeavor, Zhu to include recommend a candidate workflow entity from the workflow search module ([0062-0063] teach the workflow assignment module prioritizes the assignment of a single edge server, wherein the edge servers can be assigned based on the recommendation scores, wherein [0082-0083] teach assigning the subtask workflow to a computing server and using resource information and waiting queue of each edge server to calculate the recommendation score of each edge server, wherein the workflow allocation step prioritizes the allocation of a single edge server and can assign edge servers based on their recommendation score; see also: [0057-0061]).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify Dautov to incorporate the teachings of Zhu to include recommend a candidate workflow entity from the workflow search module. One would have been motivated to do so in order to improve the overall performance of the cloud computing center by utilizing real time analysis through an edge computing device (Zhu, [0020]). By incorporating the teachings of Zhu, one would have been able to speed up effective task allocation by identifying workflows and subtasks in real time (Zhu, [0090-0092]).
Regarding claim 12, the combination of Dautov and Zhu teaches all the limitations of claim 9 above.
Dautov further teaches wherein, upon receiving a search failure indication from the workflow entity search module, the human-machine interaction module provides the current requirement entity to a determinate mapping builder (Pg. 13 teaches the OWL ontology can be seamlessly extended with new concepts without breaking the integrity of the existing knowledge base and already existing queries, wherein Pg. 4 teaches the deployment and orchestration step finally establishes the edge cluster, provided that a feasible mapping solution is found, and deploys corresponding tasks on participating nodes, wherein otherwise, it restarts the algorithm from the discovery step to enroll new available devices that can replace missing ones, wherein if one or more tasks cannot be assigned available nodes, no feasible mapping solution for deployment can be identified, wherein two options are thus proposed in Fig. 2, either i) retry the node discovery, or ii) to completely restart the process from the design step, wherein in the latter case, the information from the discovery step, i.e. the sets of available nodes categorized by their functional property, are sent back to the Architect, who is then required to re-design the workflow, wherein the re-design should take into account the underlying CEC infrastructure and may range from local changes of non-functional task requirements to global modifications of the overall DIA logic, wherein in this activity, the Architect can also resort to Fog or Cloud Computing resources for computational task offloading, even combining both CEC and Fog/Cloud offloading patterns, wherein the DIA-CEC knowledge base facilitates seamless information exchange and interoperability between individual steps, wherein the common semantic vocabulary is required to define task requirements and device self-descriptions, as well as policies for matching-matching, task grouping, and aggregation, wherein as an outcome of the design process, the Architect generates an enhanced workflow definition that contains custom annotations specifying individual task requirements, wherein the Architect can upload the extended workload configuration to the available edge node in order to initiate the discovery, selection, and integration into a cluster for further task allocation and collaborative data processing, wherein Pg. 6 teaches the Architect provides an extended workflow definition for parsing that can be parsed to identify individual tasks constituting the workflow and translates this description in OWL, wherein class equivalence can be used to define classes in terms of object and data property constraints, wherein if the network discovery and semantic discovery is unsuccessful, this will trigger a non-functional property driven selection and mapping operation, wherein Pg. 5 teaches the high-level models collectively provide a vocabulary to describe IoT devices, as well as their sensing and actuating capabilities, wherein the DIA-CEC domain requires these ontological models to be extended with concepts relevant to the proposed clusterization process including functional and non-functional task requirements and device properties, wherein Pg. 10 teaches the system can provide feedback to the Architect to change the workflow design, wherein as a result, a given task may be changed into two new tasks, such as DetectObject and RecognizeObject, wherein multiple iterations can be performed to provide a feasible task allocation; see also: Pgs. 2, 7, 11-12), and
the determinate mapping builder then maps the current requirement entity to an existing workflow entity or a new workflow entity, forms a new mapping record and provides the new mapping record to the workflow entity search module (Pg. 13 teaches the OWL ontology can be seamlessly extended with new concepts without breaking the integrity of the existing knowledge base and already existing queries, wherein Pg. 4 teaches the deployment and orchestration step finally establishes the edge cluster, provided that a feasible mapping solution is found, and deploys corresponding tasks on participating nodes, wherein otherwise, it restarts the algorithm from the discovery step to enroll new available devices that can replace missing ones, wherein if one or more tasks cannot be assigned available nodes, no feasible mapping solution for deployment can be identified, wherein two options are thus proposed in Fig. 2, either i) retry the node discovery, or ii) to completely restart the process from the design step, wherein in the latter case, the information from the discovery step, i.e. the sets of available nodes categorized by their functional property, are sent back to the Architect, who is then required to re-design the workflow, wherein the re-design should take into account the underlying CEC infrastructure and may range from local changes of non-functional task requirements to global modifications of the overall DIA logic, wherein in this activity, the Architect can also resort to Fog or Cloud Computing resources for computational task offloading, even combining both CEC and Fog/Cloud offloading patterns, wherein the DIA-CEC knowledge base facilitates seamless information exchange and interoperability between individual steps, wherein the common semantic vocabulary is required to define task requirements and device self-descriptions, as well as policies for matching-matching, task grouping, and aggregation, wherein as an outcome of the design process, the Architect generates an enhanced workflow definition that contains custom annotations specifying individual task requirements, wherein the Architect can upload the extended workload configuration to the available edge node in order to initiate the discovery, selection, and integration into a cluster for further task allocation and collaborative data processing, wherein Pg. 6 teaches the Architect provides an extended workflow definition for parsing that can be parsed to identify individual tasks constituting the workflow and translates this description in OWL, wherein class equivalence can be used to define classes in terms of object and data property constraints, wherein if the network discovery and semantic discovery is unsuccessful, this will trigger a non-functional property driven selection and mapping operation, wherein Pg. 5 teaches the high-level models collectively provide a vocabulary to describe IoT devices, as well as their sensing and actuating capabilities, wherein the DIA-CEC domain requires these ontological models to be extended with concepts relevant to the proposed clusterization process including functional and non-functional task requirements and device properties, wherein Pg. 10 teaches the system can provide feedback to the Architect to change the workflow design, wherein as a result, a given task may be changed into two new tasks, such as DetectObject and RecognizeObject, wherein multiple iterations can be performed to provide a feasible task allocation; see also: Pgs. 2, 7, 11-12),
so that the workflow entity search module updates the determinate mappings with the new mapping record (Pg. 13 teaches the OWL ontology can be seamlessly extended with new concepts without breaking the integrity of the existing knowledge base and already existing queries, wherein Pg. 4 teaches the deployment and orchestration step finally establishes the edge cluster, provided that a feasible mapping solution is found, and deploys corresponding tasks on participating nodes, wherein otherwise, it restarts the algorithm from the discovery step to enroll new available devices that can replace missing ones, wherein if one or more tasks cannot be assigned available nodes, no feasible mapping solution for deployment can be identified, wherein two options are thus proposed in Fig. 2, either i) retry the node discovery, or ii) to completely restart the process from the design step, wherein in the latter case, the information from the discovery step, i.e. the sets of available nodes categorized by their functional property, are sent back to the Architect, who is then required to re-design the workflow, wherein the re-design should take into account the underlying CEC infrastructure and may range from local changes of non-functional task requirements to global modifications of the overall DIA logic, wherein in this activity, the Architect can also resort to Fog or Cloud Computing resources for computational task offloading, even combining both CEC and Fog/Cloud offloading patterns, wherein the DIA-CEC knowledge base facilitates seamless information exchange and interoperability between individual steps, wherein the common semantic vocabulary is required to define task requirements and device self-descriptions, as well as policies for matching-matching, task grouping, and aggregation, wherein as an outcome of the design process, the Architect generates an enhanced workflow definition that contains custom annotations specifying individual task requirements, wherein the Architect can upload the extended workload configuration to the available edge node in order to initiate the discovery, selection, and integration into a cluster for further task allocation and collaborative data processing, wherein Pg. 6 teaches the Architect provides an extended workflow definition for parsing that can be parsed to identify individual tasks constituting the workflow and translates this description in OWL, wherein class equivalence can be used to define classes in terms of object and data property constraints, wherein if the network discovery and semantic discovery is unsuccessful, this will trigger a non-functional property driven selection and mapping operation, wherein Pg. 5 teaches the high-level models collectively provide a vocabulary to describe IoT devices, as well as their sensing and actuating capabilities, wherein the DIA-CEC domain requires these ontological models to be extended with concepts relevant to the proposed clusterization process including functional and non-functional task requirements and device properties, wherein Pg. 10 teaches the system can provide feedback to the Architect to change the workflow design, wherein as a result, a given task may be changed into two new tasks, such as DetectObject and RecognizeObject, wherein multiple iterations can be performed to provide a feasible task allocation; see also: Pgs. 2, 7, 11-12).
Claim(s) 7-8 and 13 are rejected under 35 U.S.C. 103 as being unpatentable over Dautov et al. ("Automating IoT data-intensive application allocation in clustered edge computing." 2019) in view of Zhu et al. (US 20210096911 A1) in view of Khoury et al. (US 20190026786 A1).
Regarding claim 7, the combination of Dautov and Zhu teaches all the limitations of claim 4 above.
However, Dautov does not explicitly teach further comprising: receiving a selection result of selection by a user from the candidate workflow entity; and increasing a weighting of a mapping between a candidate workflow entity selected by the user and the current requirement entity according to the selection result.
From the same or similar field of endeavor, Khoury teaches further comprising: receiving a selection result of selection by a user from the candidate workflow entity ([0230] teaches the system can generate a list of action items for approval, which may be performed electronically by user interaction, wherein the approval may be required by the user over the interface, wherein [0268] teaches the system may then be adapted to produce rules or metrics that may be employed in generating a communication that capitalizes on influences, such as the predictive intelligence platform increasing or decreasing a weighting scale used to weight both content and the connections between the content and its effect on the actions of communication recipients, wherein the system can also account for various influencing factors and other user actions, wherein [0258] teaches the weights may change based on user selection, as well as in [0269-0270] teach the weight can be increased between a connection with a higher prediction of their effectiveness, wherein [0276] teaches mapping and scoring weighted items on the knowledge graph, wherein [0032] teaches the suggestions are generated for workflow management in order to schedule the various workflow parameters of the system, wherein [0111] teaches a mapping function can be used to provide a content item score, which can be a standardized measure of the performance of the content item, wherein a mapping function can be provided to the raw score by providing weighting coefficients, wherein [0118] teaches weighting and scoring data in order to make a recommendation for generating content that a user may then select and to deliver to their employees, as well as in [0165] teaches receiving and aggregating all feedback so as to automatically provide a suggested plan of action; see also: [0148-0150, 0229]); and
increasing a weighting of a mapping between a candidate workflow entity selected by the user and the current requirement entity according to the selection result ([0230] teaches the system can generate a list of action items for approval, which may be performed electronically by user interaction, wherein the approval may be required by the user over the interface, wherein [0268] teaches the system may then be adapted to produce rules or metrics that may be employed in generating a communication that capitalizes on influences, such as the predictive intelligence platform increasing or decreasing a weighting scale used to weight both content and the connections between the content and its effect on the actions of communication recipients, wherein the system can also account for various influencing factors and other user actions, wherein [0258] teaches the weights may change based on user selection, as well as in [0269-0270] teach the weight can be increased between a connection with a higher prediction of their effectiveness, wherein [0276] teaches mapping and scoring weighted items on the knowledge graph, wherein [0032] teaches the suggestions are generated for workflow management in order to schedule the various workflow parameters of the system, wherein [0111] teaches a mapping function can be used to provide a content item score, which can be a standardized measure of the performance of the content item, wherein a mapping function can be provided to the raw score by providing weighting coefficients, wherein [0118] teaches weighting and scoring data in order to make a recommendation for generating content that a user may then select and to deliver to their employees, as well as in [0165] teaches receiving and aggregating all feedback so as to automatically provide a suggested plan of action; see also: [0148-0150, 0229]).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Dautov and Zhu to incorporate the teachings of Khoury to include further comprising: receiving a selection result of selection by a user from the candidate workflow entity; and increasing a weighting of a mapping between a candidate workflow entity selected by the user and the current requirement entity according to the selection result. One would have been motivated to do so in order to determine optimal configurations for generating workflow suggestions (Khoury, [0148]). By incorporating the teachings of Khoury, one would have been able to enable more efficient and accurate searching (Khoury, [0288]).
Regarding claim 8, the combination of Dautov, Zhu, and Khoury teaches all the limitations of claim 7 above.
However, Dautov does not explicitly teach further comprising decreasing a weighting of a mapping between a candidate workflow entity not selected by the user and the current requirement entity according to the selection result.
From the same or similar field of endeavor, Khoury further teaches further comprising decreasing a weighting of a mapping between a candidate workflow entity not selected by the user and the current requirement entity according to the selection result ([0230] teaches the system can generate a list of action items for approval, which may be performed electronically by user interaction, wherein the approval may be required by the user over the interface, wherein [0268] teaches the system may then be adapted to produce rules or metrics that may be employed in generating a communication that capitalizes on influences, such as the predictive intelligence platform increasing or decreasing a weighting scale used to weight both content and the connections between the content and its effect on the actions of communication recipients, wherein the system can also account for various influencing factors and other user actions, wherein [0258] teaches the weights may change based on user selection, as well as in [0269-0270] teach the weight can be increased between a connection with a higher prediction of their effectiveness, wherein [0276] teaches mapping and scoring weighted items on the knowledge graph, wherein [0032] teaches the suggestions are generated for workflow management in order to schedule the various workflow parameters of the system, wherein [0111] teaches a mapping function can be used to provide a content item score, which can be a standardized measure of the performance of the content item, wherein a mapping function can be provided to the raw score by providing weighting coefficients, wherein [0118] teaches weighting and scoring data in order to make a recommendation for generating content that a user may then select and to deliver to their employees, as well as in [0165] teaches receiving and aggregating all feedback so as to automatically provide a suggested plan of action; see also: [0148-0150, 0229]).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Dautov, Zhu, and Khoury to incorporate the further teachings of Khoury to include further comprising decreasing a weighting of a mapping between a candidate workflow entity not selected by the user and the current requirement entity according to the selection result. One would have been motivated to do so in order to determine optimal configurations for generating workflow suggestions (Khoury, [0148]). By incorporating the teachings of Khoury, one would have been able to enable more efficient and accurate searching (Khoury, [0288]).
Regarding claim 13, the combination of Dautov and Zhu teaches all the limitations of claim 9 above.
However, Dautov does not explicitly teach wherein: the human-machine interaction module receives a selection result of selection by a user from the candidate workflow entity and provides the selection result to the workflow entity search module; the workflow entity search module increases a weighting of a mapping between a candidate workflow entity selected by the user and the current requirement entity, and decreases a weighting of a mapping between a candidate workflow entity not selected by the user and the current requirement entity, according to the selection result.
From the same or similar field of endeavor, Khoury teaches wherein: the human-machine interaction module receives a selection result of selection by a user from the candidate workflow entity and provides the selection result to the workflow entity search module ([0230] teaches the system can generate a list of action items for approval, which may be performed electronically by user interaction, wherein the approval may be required by the user over the interface, wherein [0268] teaches the system may then be adapted to produce rules or metrics that may be employed in generating a communication that capitalizes on influences, such as the predictive intelligence platform increasing or decreasing a weighting scale used to weight both content and the connections between the content and its effect on the actions of communication recipients, wherein the system can also account for various influencing factors and other user actions, wherein [0258] teaches the weights may change based on user selection, as well as in [0269-0270] teach the weight can be increased between a connection with a higher prediction of their effectiveness, wherein [0276] teaches mapping and scoring weighted items on the knowledge graph, wherein [0032] teaches the suggestions are generated for workflow management in order to schedule the various workflow parameters of the system, wherein [0111] teaches a mapping function can be used to provide a content item score, which can be a standardized measure of the performance of the content item, wherein a mapping function can be provided to the raw score by providing weighting coefficients, wherein [0118] teaches weighting and scoring data in order to make a recommendation for generating content that a user may then select and to deliver to their employees, as well as in [0165] teaches receiving and aggregating all feedback so as to automatically provide a suggested plan of action; see also: [0148-0150, 0229]);
the workflow entity search module increases a weighting of a mapping between a candidate workflow entity selected by the user and the current requirement entity ([0230] teaches the system can generate a list of action items for approval, which may be performed electronically by user interaction, wherein the approval may be required by the user over the interface, wherein [0268] teaches the system may then be adapted to produce rules or metrics that may be employed in generating a communication that capitalizes on influences, such as the predictive intelligence platform increasing or decreasing a weighting scale used to weight both content and the connections between the content and its effect on the actions of communication recipients, wherein the system can also account for various influencing factors and other user actions, wherein [0258] teaches the weights may change based on user selection, as well as in [0269-0270] teach the weight can be increased between a connection with a higher prediction of their effectiveness, wherein [0276] teaches mapping and scoring weighted items on the knowledge graph, wherein [0032] teaches the suggestions are generated for workflow management in order to schedule the various workflow parameters of the system, wherein [0111] teaches a mapping function can be used to provide a content item score, which can be a standardized measure of the performance of the content item, wherein a mapping function can be provided to the raw score by providing weighting coefficients, wherein [0118] teaches weighting and scoring data in order to make a recommendation for generating content that a user may then select and to deliver to their employees, as well as in [0165] teaches receiving and aggregating all feedback so as to automatically provide a suggested plan of action; see also: [0148-0150, 0229]), and
decreases a weighting of a mapping between a candidate workflow entity not selected by the user and the current requirement entity, according to the selection result ([0230] teaches the system can generate a list of action items for approval, which may be performed electronically by user interaction, wherein the approval may be required by the user over the interface, wherein [0268] teaches the system may then be adapted to produce rules or metrics that may be employed in generating a communication that capitalizes on influences, such as the predictive intelligence platform increasing or decreasing a weighting scale used to weight both content and the connections between the content and its effect on the actions of communication recipients, wherein the system can also account for various influencing factors and other user actions, wherein [0258] teaches the weights may change based on user selection, as well as in [0269-0270] teach the weight can be increased between a connection with a higher prediction of their effectiveness, wherein [0276] teaches mapping and scoring weighted items on the knowledge graph, wherein [0032] teaches the suggestions are generated for workflow management in order to schedule the various workflow parameters of the system, wherein [0111] teaches a mapping function can be used to provide a content item score, which can be a standardized measure of the performance of the content item, wherein a mapping function can be provided to the raw score by providing weighting coefficients, wherein [0118] teaches weighting and scoring data in order to make a recommendation for generating content that a user may then select and to deliver to their employees, as well as in [0165] teaches receiving and aggregating all feedback so as to automatically provide a suggested plan of action; see also: [0148-0150, 0229]).
It would have been obvious to a person having ordinary skill in the art before the effective filing date of the claimed invention to modify the combination of Dautov and Zhu to incorporate the teachings of Khoury to include wherein: the human-machine interaction module receives a selection result of selection by a user from the candidate workflow entity and provides the selection result to the workflow entity search module; the workflow entity search module increases a weighting of a mapping between a candidate workflow entity selected by the user and the current requirement entity, and decreases a weighting of a mapping between a candidate workflow entity not selected by the user and the current requirement entity, according to the selection result. One would have been motivated to do so in order to determine optimal configurations for generating workflow suggestions (Khoury, [0148]). By incorporating the teachings of Khoury, one would have been able to enable more efficient and accurate searching (Khoury, [0288]).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure:
Moova et al. (US 20190020952 A1) discloses generating a vocabulary task map
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). 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 Sara G Brown whose telephone number is (469)295-9145. The examiner can normally be reached M-F 8:00 am- 5:00 pm.
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, Brian Epstein can be reached at (571) 270-5389. 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.
/SARA GRACE BROWN/Primary Examiner, Art Unit 3625
