Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Claim Rejections - 35 USC § 102
The following is a quotation of the appropriate paragraphs of 35 U.S.C. 102 that form the basis for the rejections under this section made in this Office action:
A person shall be entitled to a patent unless –
(a)(1) the claimed invention was patented, described in a printed publication, or in public use, on sale, or otherwise available to the public before the effective filing date of the claimed invention.
Claims 1-4, 7-10, 11-14, 17-20 are rejected under 35 U.S.C. 102(a)(1) as being anticipated by Yotam (US Patent no. 12511120)
Regarding claim 1, Yotam discloses:
A method, in a data processing system, for segregating a function-as-a-service (FaaS) workflow into processes for segregated execution, the method comprising:
Identifying a plurality of sub-flows within the FaaS workflow; (see e.g., fig. 3, build graph 314 being a FaaS workflow, with three sub-flows, first subflow being F2() 302, second sub-flow being merge candidates 312 as F1(), F4() and F5(), and third subflow being F3() 306). Build graph 314 shows each function (F + number) as its own object, and shows that the patented system can assign attributes to the functions (i.e., which merge group the function can fit inside for optimization). (see also e.g., column [0004], lines [0024-0029], “The present techniques can facilitate dynamic FaaS reallocation to collect runtime execution information to identify optimized function execution groups.”)
Generating, for each sub-flow, a container to implement the sub-flow as a separate process from processes of other sub-flows in the FaaS workflow, wherein at least one sub-flow comprises a plurality of functions of the FaaS workflow; and (see e.g., column [005], lines [0044-0054], “Build graph 314 can be used to determine to merge F1() 304, F4() 308, and F5() 310, to save a potential idle time in a function cold start […] Where F2() 302 and F3() 306 are to be executed in parallel, they can be kept outside of a fused container.”) In effect, there is a fused container for F1(), F4(), and F5() together in a container, and then F2() and F3() are in separate containers. (See also e.g., column [0006], lines [0043 – 0053], “each of function container 414A and function container 414B can comprise a container, where a container can generally package executable computer code (e.g., a function) with libraries and dependencies that are invoked by the code”)
Deploying the containers of the plurality of sub-flows for execution by one or more nodes. (see e.g., column [0004], lines [0053-0055], “FaaS fusion deployment component 108 can implement part(s) of the process flows of FIGS. 6 and or 9-11 to implement FaaS fusion deployment.”) (see also e.g., fig. 5, deployment of function container 514 and fig. 7, fused function container 702C).
Regarding claim 7, Yotam discloses:
The method of claim 1, wherein the method further comprises inserting a proxy, for at least one function, in the one or more sub-flows of the plurality of sub-flows, that is invoked by a function of a different sub-flow. (see e.g., column [001-002], lines [0054-0009], “An example method can comprise determining, by a system comprising a processor, that a first containerized function of a group of containerized functions invokes a second containerized function of the group of containerized functions. […] The method can further comprise directing, by the system, a second call to invoke the second containerized function to the deployed image.”
Regarding claim 8, Yotam discloses:
the method of claim 1, wherein identifying a plurality of sub-flows within the FaaS workflow comprises identifying a subset of functions of the FaaS workflow that are executed together in a sequence at least a threshold number of times. (see e.g., column [007], lines [0014-0030], “ Fuse controller 404 can pull metric data (e.g., from metric collector 408) and analyze the data to make a decision on which functions or function groups to merge. In some examples, fuse controller 404 can take into account the following information in determining a merge strategy: 1. Whether the functions are called above a threshold percentage of the time together, where the threshold is a predefined system parameter; 2. Whether the functions are called within a threshold amount of time of each other, where the threshold is a predefined system parameter;”)
Regarding claim 9, Yotam discloses:
The method of claim 1, wherein the identifying of the plurality of sub-flows within the FaaS workflow is performed dynamically based on gathered performance data for the FaaS workflow, and wherein the sub-flows within the FaaS workflow may change over time based on the gathered performance data. (see e.g., column [004], lines [0001-0006], “In some examples, the system can have two possible modes of analyzing and deploying cascading function calls- static and dynamic. […] Dynamic analysis can be based on recognizing cascading function calls based on metrics collected during runtime.”)
Regarding claim 10, Yotam discloses:
The method of claim 1, wherein deploying the containers of the plurality of sub-flows for execution by one or more nodes comprises generating a deployment plan having segregated invocation paths and control data for the plurality of sub-flows executed as segregated processes. (see e.g., column [021], lines [0035 – 0048], “generating a graph based on source code of the group of containerized functions, wherein the source code comprises the first source code and the second source code, wherein the graph comprises nodes that represent respective functions of the group of containerized functions and edges that represent invocations between the respective functions, and wherein the static analysis is based on the graph. The System of claim 3, wherein the graph comprises paths of invocations in the graph, and wherein the static analysis comprises identifying a path of the paths that is a longest path of the paths.”) The Examiner is considering the node/path graph as the segregated invocation path and the static analysis of longest paths as control data.
Regarding claim 11, Yotam discloses:
A computer program product comprising a computer readable storage medium having a computer readable program stored therein, wherein the computer readable program, when executed on a computing device, causes the computing device to segregate a function-as-a-service (FaaS) workflow into processes for segregated execution, at least by: performing the steps of the method of claim 1. As such, claim 11 is rejected as being anticipated by Yotam for the same reasons presented with respect to claim 1.
Claims 17-19 recite substantially the same limitations as claims 7-9, respectively, applied to the apparatus of claim 11. As such, claims 17-19 are rejected as being anticipated by Yotam for the same reasons presented with respect to claims 7-9.
Regarding claim 20, Yotam discloses:
An apparatus comprising: at least one processor; and at least one memory coupled to the at least one processor, wherein the at least one memory comprises instructions which, when executed by the at least one processor, cause the at least one processor to segregate a function-as-a-service (FaaS) workflow into processes for segregated execution, at least by: performing the steps of the method of claim 1. As such, claim 20 is rejected as being anticipated by Yotam for the same reasons presented with respect to claim 1.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 2, 3, and 4 are rejected under 35 U.S.C. 103 as being unpatentable over Yotam in view of Lucas (Lucas, US 20210141783 A1), hereinafter referred to as Lucas.
Regarding claim 2, Yotam teaches:
The method of claim 1
Yotam fails to teach:
Wherein the method further comprises inserting, for at least one function, in one or more of the sub-flows of the plurality of sub-flows, that invokes a function of a different sub-flow, a routing tap that applies a policy to alter an input to a subsequent function or to determine an execution path based on a condition of the at least one function.
However, Lucas teaches:
Inserting, for at least one function, in one or more of the sub-flows of the plurality of sub-flows, that invokes a function of a different sub-flow, a routing tap that applies a policy to alter an input to a subsequent function or to determine an execution path based on a condition of the at least one function. (see e.g., paragraph [0031], “The system describes herein provides for modifying the runtime configuration during runtime of the master flow. A flow's path may be dictated by configurable predicates, and sub-flows can be bypassed using custom metadata. Furthermore, the system provides for environment-specific variables that are externalized and unobtrusively maintained. A centralized source can be used to declare defaults that can be overridden, independent of other flow definitions. This way, the system allows for changes in the metadata to be propagated throughout the flows and sub-flows, seamlessly.”) (see e.g., paragraph [0109], “As a non-limiting example, a master and sub-flows may implement two-factor authentication (2FA) to authenticate a user logging on to a system. An administrator may use flow builder 2344 to modify an expiration of the time to input an onetime passcode provided to the user. The administrator may update metadata object 2348 to change the expiration time from 10 minutes to 5 minutes. An administrator may use flow builder 2344 to navigate to setup, custom metadata types, flow session setting, and modify the associated record (2FA expiration period). By doing so, the setting of metadata object 2348 may be updated and implemented in the master and sub-flows, without having to restart the flow itself using the variable identifying the master and sub-flows. Each instance of the 2FA expiration period record in the master and sub-flows may be updated.”)
Yotam and Lucas are considered to be analogous art to the claimed invention as they are reasonably pertinent to the problem faced by the inventor of managing sub-flows. Therefore, it would have been obvious to one of ordinary skill in the art that the method for managing sub-flows taught by Yotam could include flow-managing variables as taught by Lucas. Having sub-flows utilize a variable from outside their scope in the manner described by Lucas enables propagation of metadata that can control the runtime configuration of the workflow or its sub-flows. (Lucas: paragraphs [0002] and [0027])
Regarding claim 3, Lucas recites:
The method of claim 2, wherein the routing tap controls, based on an output of a first function in a first sub-flow of a first process, with which the routing tap is associated, which second function in a second sub-flow of a second process to invoke. (see e.g., paragraph [0093], “Application 2326-1 may include one or more software applications that may be provided to or accessed by user device 2310 or the client device 2360. In an embodiment, flow builder 2344 may be executed locally on the client device 2360. Alternatively, the application 2326-1 may eliminate a need to install and execute software applications on the user device 2310 and client device 2360. The application 2326-1 may include software associated with backend platform 125 and/or any other software configured to be provided across cloud computing system 2332. The application 2326-1 may send/receive information from one or more other applications 2326-1, via the virtual machine 2326-2.”) (see e.g., paragraph [0031], “The system describes herein provides for modifying the runtime configuration during runtime of the master flow. A flow's path may be dictated by configurable predicates, and sub-flows can be bypassed using custom metadata. Furthermore, the system provides for environment-specific variables that are externalized and unobtrusively maintained. A centralized source can be used to declare defaults that can be overridden, independent of other flow definitions. This way, the system allows for changes in the metadata to be propagated throughout the flows and sub-flows, seamlessly.”) The Examiner would like to put forth that metadata is a type of information, and therefore these quotes show that in this context, other applications can send and receive information that would determine the next step of a running path.
Regarding claim 4, Lucas recites:
The method of claim 2, wherein the routing tap comprises logic that determines when to invoke the function of the different sub-flow or to continue a workflow of a sub-flow in which the routing tap is inserted. (see e.g., paragraph [0035], “Once the data has been sanitized, the system can utilize the provided utility flow to convert the session data, e.g., running the Create Records From Flow Session (Auto-launched Flow) utility flow to create/update contact and associate the uploaded documents with that record after the information and documents have been validated, or approved by staff.”) Since this flow is automatically launched when the data is sanitized, there must be logic that determines whether the data is sanitized.
Claims 12, 13, and 14 recite substantially the same limitations as claims 2, 3, and 4 respectively, applied to the apparatus of claim 11. As such, claims 12, 13, and 14 are rejected as being unpatentable over Yotam in view of Lucas for the same reasons presented with respect to claims 2, 3 and 4.
Allowable Subject Matter
Claims 5-6 and 15-16 are objected to as being dependent upon a rejected base claim, but would be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
The following is a statement of reasons for the indication of allowable subject matter:
There was no prior art, nor combination of prior art, which taught the limitation “the routing tap comprises a wrapper of the at least one function, which comprises a signature of the at least one function and control-flow-flags, wherein the control-flow-flags are set through an attached probe which is invoked during function invocate or before a function return of the at least one function.” as recited in claim 5, when considered in combination with the limitations added by the claims it is dependent on.
The closest prior art found with respect to the above limitation was Stroustrup et. al, (since at least 2020, “C++ Core Guidelines”), which teaches what a helper function is generally considered (see e.g., immediately under section header “C.5: Place helper functions in the same namespace as the class they support” [if viewing on GitHub, a shortcut is possible by appending “#Rc-helper” to the end of the URL viewing the markdown document], “A helper function is a function (usually supplied by the writer of a class that does not need direct access to the representation of the class, yet is seen as part of the useful interface to the class.”) While Stroustrup teaches the potential wrapping of functions, it fails to teach the setting of “control-flow-flags”
There was no prior art, nor combination of prior art, which taught the limitation “the routing tap comprises an Extended Berkeley Packet Filter (eBPF) user probe attached to a function invocation event, and wherein the policy is obtained from an eBPF map with an eBPF master.” as recited in claim 6, when considered in combination with the limitations added by the claims it is dependent on.
The closest prior art found with respect to the above limitation was The Libbpf Authors (2023, eBPF Docs, “Helper function bpf_probe_write_user”), which teaches a method of using a eBPF probe attached to two points (src and dst) to write from one space to another within valid user contexts. However, it teaches strictly away from using this method except when testing and debugging (in effect, limiting it to a development tool), as it can crash the system or running programs.
Claims 15 and 16 recite the same limitations as 5 and 6, respectively. Accordingly, claims 15 and 16 would also be allowable if rewritten in independent form including all of the limitations of the base claim and any intervening claims.
Conclusion
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Connor Imiola Blackburn whose telephone number is (571)272-6547. The examiner can normally be reached M-Th 7-5.
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, Kevin Young can be reached at (571) 270 - 3180. 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.
/C.I.B./Examiner, Art Unit 2194 /KEVIN L YOUNG/Supervisory Patent Examiner, Art Unit 2194
Prosecution Insights