Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Priority
Acknowledgment is made of applicant's claim for foreign priority based on an application filed in China on 04/29/2022. It is noted, however, that applicant has not filed a certified copy of the PCT/CN2022/090642 application as required by 37 CFR 1.55.
Information Disclosure Statement
The information disclosure statements (IDS) filed on 10/28/2024 and 03/13/2026 have been fully considered.
Claim Objections
Claim 6 is objected to because of the following informalities: Examiner suggests amending the claim to correct a minor typographical error by reciting “The workflow recommendation method as claimed in claim 1, further comprising: ”
Appropriate correction is required.
Claim Interpretation
The following is a quotation of 35 U.S.C. 112(f):
(f) Element in Claim for a Combination. – An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The following is a quotation of pre-AIA 35 U.S.C. 112, sixth paragraph:
An element in a claim for a combination may be expressed as a means or step for performing a specified function without the recital of structure, material, or acts in support thereof, and such claim shall be construed to cover the corresponding structure, material, or acts described in the specification and equivalents thereof.
The claims in this application are given their broadest reasonable interpretation using the plain meaning of the claim language in light of the specification as it would be understood by one of ordinary skill in the art. The broadest reasonable interpretation of a claim element (also commonly referred to as a claim limitation) is limited by the description in the specification when 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is invoked.
As explained in MPEP § 2181, subsection I, claim limitations that meet the following three-prong test will be interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph:
(A) the claim limitation uses the term “means” or “step” or a term used as a substitute for “means” that is a generic placeholder (also called a nonce term or a non-structural term having no specific structural meaning) for performing the claimed function;
(B) the term “means” or “step” or the generic placeholder is modified by functional language, typically, but not always linked by the transition word “for” (e.g., “means for”) or another linking word or phrase, such as “configured to” or “so that”; and
(C) the term “means” or “step” or the generic placeholder is not modified by sufficient structure, material, or acts for performing the claimed function.
Use of the word “means” (or “step”) in a claim with functional language creates a rebuttable presumption that the claim limitation is to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites sufficient structure, material, or acts to entirely perform the recited function.
Absence of the word “means” (or “step”) in a claim creates a rebuttable presumption that the claim limitation is not to be treated in accordance with 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph. The presumption that the claim limitation is not interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, is rebutted when the claim limitation recites function without reciting sufficient structure, material or acts to entirely perform the recited function.
Claim limitations in this application that use the word “means” (or “step”) are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action. Conversely, claim limitations in this application that do not use the word “means” (or “step”) are not being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, except as otherwise indicated in an Office action.
This application includes one or more claim limitations that do not use the word “means,” but are nonetheless being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, because the claim limitation(s) uses a generic placeholder that is coupled with functional language without reciting sufficient structure to perform the recited function and the generic placeholder is not preceded by a structural modifier. Such claim limitation(s) is/are: “human-machine interaction module” in claim 9, “workflow entity search module” in claim 9, and “determinate mapping builder” of claims 6 and 12.
Because this/these claim limitation(s) is/are being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, it/they is/are being interpreted to cover the corresponding structure described in the specification as performing the claimed function, and equivalents thereof.
If applicant does not intend to have this/these limitation(s) interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph, applicant may: (1) amend the claim limitation(s) to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph (e.g., by reciting sufficient structure to perform the claimed function); or (2) present a sufficient showing that the claim limitation(s) recite(s) sufficient structure to perform the claimed function so as to avoid it/them being interpreted under 35 U.S.C. 112(f) or pre-AIA 35 U.S.C. 112, sixth paragraph.
Claim Rejections - 35 USC § 112
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-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. Furthermore, the metes and bounds of the claims are rendered unclear because it is unclear what “a "using" and "used" mapping” is within the claims. It is unclear if there is a singular mapping that is both using or used, or if there are two distinct mappings, one for using and one for used. It is further unclear if the mapping is “using” or “used” information in order to generate the mapping, or if the “using” and “used” is a label provided for the mapping. 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 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. Furthermore, the metes and bounds of the claims are rendered unclear because it is unclear what “a "using" and "used" mapping,” a “comprising” and “comprised” mapping, and a “supporting” and “supported” mapping are within the claims. It is unclear if there is a singular mapping that is both using or used, or if there are two distinct mappings, one for using and one for used. It is further unclear if the quoted language is a label or is functionally tied to the mapping within 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.
Additionally, with further respect to claims 2 and 4, the metes and bounds of the claim are rendered further unclear because the claims do not rely antecedently upon the previous recitation of “a “using” and “used” mapping in claim 1. It is unclear if the “using” and “used” mapping of claim 1 between the requirement entity and the corresponding workflow entity is the same “using” and “used” mapping of claims 2 and 4 between the task and the skill are the same mapping, or if the mapping of the dependent claims are distinct from that of the mapping of the independent claim. Therefore, the metes and bounds of the claim are rendered further unclear due to the lack of clear antecedent basis.
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.
Regarding claims 3 and 5, the metes and bounds of the claim are rendered unclear due to the limitations comprised within brackets. It is unclear what limitations are imparted onto the claimed subject matter through the use of brackets. It is unclear if the brackets are intended to indicate programming syntax, pseudocode, or are intended to impart some other type of limitations upon the claimed subject matter. Additionally, these bracketed limitations do not utilize antecedent basis. It is unclear if the two conditional searches are seeking the same conditions multiple times due to the lack of clear antecedent basis. For example, with respect to claim 2, the first step of both conditional searches include “[edge applications] provide [skills].” There is no clear antecedent basis in the claims provided in order to distinguish between the first step of each search. It is unclear if the two first steps are repeated or are searching for distinct conditions. Therefore, the metes and bounds of the claims are rendered unclear due to the bracketed language.
For the sake of compact prosecution, Examiner is interpreting the claim as though a search is conducted including the elements provided in the brackets. Examiner suggests amending the claims to remove the brackets and clarify the conditions of the search.
Regarding claims 6 and 12, the limitation of “the determinate mapping builder maps the current requirement entity to an existing workflow entity or a new workflow entity, forms a new mapping record, and update the determinate mappings with the new mapping record,” the metes and bounds of the claims are rendered unclear. It is unclear what the “determinate mapping builder” is within the claims. The present claims invoke 35 USC 112(f) and the specification does not describe the structure/materials/acts associated with the claimed “determinate mapping builder.” Upon viewing the specification, the specification does not describe or define the structure and algorithm associated with the claimed builder. The specification, such as Pgs. 17-18, merely recite the limitations of the claims and do not describe any particular hardware or algorithm associated with the claimed builder. The present claims are indefinite because the specification, whether expressly, implicitly, or inherently, does not describe the structure/materials/acts associated with the claimed builder. Therefore, the present claims invoke 35 USC 112(f) and render the metes and bounds of the claims unclear because the specification does not sufficiently describe the structure/materials/acts associated with the claims.
For the sake of compact prosecution, Examiner is interpreting the “determinate mapping builder” as any structure capable of performing the claimed function.
Regarding claim 9, the limitation of “the human-machine interaction module recommends a candidate workflow entity from the workflow search module,” the metes and bounds of the claim are unclear. It is unclear what the “human-machine interaction module” is within the claim. The present claim invokes 35 USC 112(f) and the specification does not describe the algorithm associated with the claimed “human-machine interaction module.” Upon viewing the specification, the specification discloses the structure associated with the claimed module as being at computer in at least Pgs. 22-24. However, the specification does not disclose or describe an algorithm associated with the claimed “human-machine interaction module.” The original disclosure, such as in Pgs. 21-22, merely recite the same limitations as the claim and do not describe the algorithm associated with the claimed functions. The present claims are indefinite because the specification does not describe the algorithm associated with the claimed “human-machine interaction module.” Therefore, the present claims invoke 35 USC 112(f) and render the metes and bounds of the claim unclear because the specification does not sufficiently disclose the algorithm associated with the claimed module.
For the sake of compact prosecution, Examiner is interpreting the “human-machine interaction module” as any computer capable of performing the claimed function.
Regarding claim 9, the limitation of “the workflow entity search module, based on a pre-established determinate mapping between each requirement entity and each workflow entity, searches the determinate mappings using the current requirement entity as a keyword to obtain at least one candidate workflow entity,” the metes and bounds of the claim are unclear. It is unclear what the “workflow entity search module” is within the claim. The present claim invokes 35 USC 112(f) and the specification does not describe the algorithm associated with the claimed “workflow entity search module.” Upon viewing the specification, the specification discloses the structure associated with the claimed module as being at computer in at least Pgs. 22-24. However, the specification does not disclose or describe an algorithm associated with the claimed “workflow entity search module.” The original disclosure, such as in Pgs. 21-22, merely recite the same limitations as the claim and do not describe the algorithm associated with the claimed functions. The present claims are indefinite because the specification does not describe the algorithm associated with the claimed “workflow entity search module.” Therefore, the present claims invoke 35 USC 112(f) and render the metes and bounds of the claim unclear because the specification does not sufficiently disclose the algorithm associated with the claimed module.
For the sake of compact prosecution, Examiner is interpreting the claimed “workflow entity search module” as any computer capable of performing the claimed function.
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).
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
(a) IN GENERAL.—The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor or joint inventor of carrying out the invention.
The following is a quotation of the first paragraph of pre-AIA 35 U.S.C. 112:
The specification shall contain a written description of the invention, and of the manner and process of making and using it, in such full, clear, concise, and exact terms as to enable any person skilled in the art to which it pertains, or with which it is most nearly connected, to make and use the same, and shall set forth the best mode contemplated by the inventor of carrying out his invention.
Claims 6 and 9-13 are rejected under 35 U.S.C. 112(a) or 35 U.S.C. 112 (pre-AIA ), first paragraph, as failing to comply with the written description requirement. The claim(s) contains subject matter which was not described in the specification in such a way as to reasonably convey to one skilled in the relevant art that the inventor or a joint inventor, or for applications subject to pre-AIA 35 U.S.C. 112, the inventor(s), at the time the application was filed, had possession of the claimed invention.
Regarding claims 6 and 12, the limitation of “the determinate mapping builder maps the current requirement entity to an existing workflow entity or a new workflow entity, forms a new mapping record, and update the determinate mappings with the new mapping record,” invokes 35 USC 112(f) or pre-AIA 35 USC 112, sixth paragraph. However, the written description fails to disclose the corresponding structure, materials, or acts for performing the entire claimed function. The specification, in at least Pgs. 17-18, merely describe the same description of the builder as the claims and does not provide any particular structure/materials/acts in order to perform the entire claimed function. However, the specification is devoid of any disclosure or description of the structure/materials/acts associated with performing the entire claimed function. As the instant disclosure fails to disclose, whether expressly, implicitly, or inherently, the structure, materials, or acts associated with the claimed builder, the present claims are rejected for lacking adequate written description of the claimed invention.
Regarding claim 9, the limitation of “the human-machine interaction module recommends a candidate workflow entity from the workflow search module,” invokes 35 USC 112(f) or pre-AIA 35 USC 112, sixth paragraph. However, the written description fails to disclose the corresponding algorithm for performing the entire claimed function and to clearly link the algorithm to the function. The specification, in at least Pgs. 22-24, discloses the structure as being a device comprising a processor and memory. However, the specification is devoid of any disclosure or description of the algorithm associated with the claimed function. As the instant disclosure, whether expressly, implicitly, or inherently, the algorithm associated with the claimed module, the present claims are rejected for lacking adequate written description of the claimed invention.
Regarding claim 9, the limitation of “the workflow entity search module, based on a pre-established determinate mapping between each requirement entity and each workflow entity, searches the determinate mappings using the current requirement entity as a keyword to obtain at least one candidate workflow entity,” ” invokes 35 USC 112(f) or pre-AIA 35 USC 112, sixth paragraph. However, the written description fails to disclose the corresponding algorithm for performing the entire claimed function and to clearly link the algorithm to the function. The specification, in at least Pgs. 22-24, discloses the structure as being a device comprising a processor and memory. However, the specification is devoid of any disclosure or description of the algorithm associated with the claimed function. As the instant disclosure, whether expressly, implicitly, or inherently, the algorithm associated with the claimed module, the present claims are rejected for lacking adequate written description of the claimed invention.
Dependent claims 10-13 are rejected due to dependency on rejected base claim 9.
Accordingly, claims 6 and 9-13 are rejected under 35 USC 112(a).
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 claims 9 and 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 keyword 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.” 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-5, 7-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 claims 6 and 12 will be evaluated under Step 2A, Prong 2.
Step 2A, Prong 2: Claims 1, 9, and 14 do not integrate the judicial exception into a practical application. Claim 1 do not recite any particular additional elements for consideration. Claim 9 recites a device comprising “a human-machine interaction module; and a workflow entity search module. [Examiner’s Note: See the 35 USC 112(f) claim interpretation above.]” Claim 14 is directed to a method 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-5, 7-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 does not integrate the judicial exception into a practical application.
Dependent claims 6 and 12 further recite 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 a determinate mapping builder, 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, 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: Claims 1, 9, and 14 do not comprise anything significantly more. Claim 1 do not recite any particular additional elements for consideration. Claim 9 recites a device comprising “a human-machine interaction module; and a workflow entity search module. [Examiner’s Note: See the 35 USC 112(f) claim interpretation above.]” Claim 14 is directed to a method 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-5, 7-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 claims 6 and 12 further recite 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 a determinate mapping builder, 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, 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 (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);
based on a pre-established determinate mapping between each requirement entity and each workflow entity, using the current requirement entity as a keyword 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 claims 9 and 14, the claims recite limitations already addressed by the rejection of claim 1. Regarding claim 9, Dautov teaches a workflow recommendation device comprising (Pgs. 3-4): a human-machine interaction module (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 a workflow entity search module (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). 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, claims 9 and 14 are 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
a "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):
[edge applications] provide [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
[skills] are used by [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 [tasks] are included in [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):
[edge applications] provide [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
[skills] are used by [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
[current task] is included in [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
a "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 [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):
[functional blocks] support [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
[devices] are used by [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
[tasks] are included in [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):
[functional blocks] support [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
[devices] are used by [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
[current task] is included in [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, providing 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
wherein the determinate mapping builder maps the current requirement entity to an existing workflow entity or a new workflow entity, forms a new mapping record, and update 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 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:
Zheng et al. (US 20210271886 A1) discloses analyzing workflows for various operations through the use of embeddings or keywords
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
Prosecution Insights