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 Status
Claims 1-20 are pending.
Claims 1-20 are rejected.
Priority
The instant application filed on 2 November 2022 claims priority to a provisional application filed on 29 December 2021. As such, claims 1-20 of the instant application have an effective filing date of 29 December 2021.
Information Disclosure Statement
The examiner considered all documents in the IDS filed 06 April 2023. The provider NPL reference #3, Dohsimpson: "Kubernetes Documentation Part: Concepts" (21 December 2020) was illegible. The examiner found a copy of said NPL reference and has included it in the Notice of References Cited.
Drawings
The drawing filed 26 September 2022 are accepted.
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.
Claims 1, 8, and 15 and their dependent claims 2-7, 9-14, and 16-20 are rejected under 35 U.S.C. 103 as being unpatentable over Khalfan (gencore.bio.nyu.edu, 25 March 2020, pages 1-36) in view of Dockerfile (Github: gencorefacility, 28 April 2020, pages 1-4) and Main (Github: gencorefacility, 28 March 2020, pages 1-9). Khalfan teaches a Nextflow workflow that includes using Picard, a known genomics analysis tool (page 7, “Workflow Overview” figure) and using GATK4 for variant analysis. (Page 7-19, “Workflow Overview” figure and following table) Khalfan further teaches a Nextflow pipeline as a genomic analysis application (page 3, “Setting Up Nextflow”) and use with Docker containers to launch the tools. (Page 6, “Scenario 4: Use with a Docker container”)
Khalfan does not explicitly teach to “determine an indicated version of a variant analysis model for executing the genomic analysis application indicated by an application specification defining one or more parameters for the genomic analysis application; based on determining the indicated version of the variant analysis model, install the indicated version of the variant analysis model for execution instead of a previously installed version of the variant analysis model; and execute the genomic analysis application.”
Dockerfile teaches the application specifications for the genomic analysis application and determining the version of the variant analysis model. For example, code line 55 discloses “ENV GATK_VERSION 4.1.3.0”. (Page 2) Further, Dockerfile teaches installing the variant analysis model in code lines 64 – 72. (Page 3) Main teaches executing the variant analysis model by running the Nextflow pipeline. (Page 1, code lines 1 and 2)
It would have been prima facie obvious to one of ordinary skill in the art at the effective
filing date of the invention to have combined the teachings of Khalfan, Dockerfile, and Main to execute genomic analysis through selected and installed variant analysis models. Khalfan, Dockerfile, and Main all include interrelated information on how to utilize a Nextflow pipeline, Docker containers, and GATK4 to perform genomic analysis. Therefore, one of ordinary skill in the art would have been motivated before the effective filing date of the instant application to combine the method and coding from Khalfan, Dockerfile, and Main for genomic analysis through variant analysis models. The invention is therefore prima facie obvious.
Claim 2 is rejected under 35 U.S.C. 103 as being unpatentable over Khalfan, Dockerfile, and Main as applied to claim 1 above, and further in view of Van Rooyen et al. (US 10,049,179 B2, 14 August 2018) (Herein referred to as Van Rooyen.)
Khalfan, Dockerfile, and Main do not teach to “cause the system to install the indicated version of the variant analysis model by updating a field programmable gate array to include the indicated version of the variant analysis model for performing genomic analysis.”
Van Rooyen teaches using a field programmable gate array as part of genomics analysis platform for executing a sequence analysis pipeline. (Claims 1, 7, 8, 19, and 26)
It would have been prima facie obvious to one of ordinary skill in the art at the effective
filing date of the invention to have incorporated the field programmable gate array (FPGA) of Van Rooyen with the genomic and variant analysis methods of Khalfan, Dockerfile, and Main. FPGAs are known to improve efficiency by processing multiple workflows in parallel and allowing for changes to the programming of the system. As disclosed in Van Rooyen, “where the integrated circuit is an FPGA, such steps in the sequence and/or further analysis process may involve the partial reconfiguration of the FPGA during the analysis process.” (Page 75, column 3, lines 6-9) Van Rooyen further discloses benefits for use of an FPGA “when processing data through a genomics pipeline, as herein described, such as to accelerate overall processing function, timing, and efficiency, a number of different operations may be run on the data, which operations may involve both software and hardware processing components.” (Page 78, column 9, lines 4-9) Therefore, one of ordinary skill in the art would have been motivated before the effective filing date of the instant application to incorporate an FPGA into the genomic and variant analyses to increase efficiency and allow for reconfiguration. The invention is therefore prima facie obvious.
Claim 3 is rejected under 35 U.S.C. 103 as being unpatentable over Khalfan, Dockerfile, and Main as applied to claim 1 above, and further in view of Chowdhury. (FreeCodeCamp, The Docker Handbook, 1 February 2021, pages 1-146)
Khalfan, Dockerfile, and Main do not explicitly teach to “cause the system to install the indicated version of the variant analysis model automatically by utilizing a variant analysis model manager to determine available versions of the variant analysis model and to initiate installation of the indicated version from the available versions.”
In the “Docker Architecture Overview” item 1: Docker Daemon, Chowdhury teaches that “[t]he daemon is capable of managing various Docker objects.” (Pages 23-4) Chowdhury further describes the steps when the “docker run hello-world” command is executed, including that it is “the default behavior of Docker daemon to look for images in the hub that are not present locally. But once an image has been fetched, it'll stay in the local cache.” (Pages 25, lines1-6 and page 26, lines 1-11) Chowdhury also teaches “[i]f there is a newer version of the image available on the public registry, the daemon will fetch the image again. That :latest is a tag. Images usually have meaningful tags to indicate versions or builds.” (Page 26, lines 19-21)
It would have been prima facie obvious to one of ordinary skill in the art at the effective
filing date of the invention to have utilized the known features of Docker to determine available variant analysis models and to install the indicated version. Therefore, one of ordinary skill in the art would have been motivated before the effective filing date of the instant application to use the container orchestration engine to find and install versions of the variant analysis models. The invention is therefore prima facie obvious.
Claims 4 and 14 are rejected under 35 U.S.C. 103 as being unpatentable over Khalfan, Dockerfile, and Main as applied to claims 1 and 8 above, and further in view of Chowdhury.
Khalfan, Dockerfile, and Main do not explicitly teach to “cause the system to determine the indicated version of the variant analysis model for executing the genomic analysis application by analyzing the application specification to identify a version label specifying the indicated version of the variant analysis model.”
As indicated above, Chowdhury teaches using tags as indicators to assist in identifying image versions. (Page 26, lines 19-21) Chowdhury further teaches “[h]ow to Tag Docker Images…[that] you can assign custom identifiers to your images…[and] [t]he repository is usually known as the image name and the tag indicates a certain build or version.” (Page 53, lines 8-13 and page 54, lines 1-2)
It would have been prima facie obvious to one of ordinary skill in the art at the effective
filing date of the invention to have utilized the known features of Docker to label versions of the variant analysis models and use the labels to determine the indicated version. Therefore, one of ordinary skill in the art would have been motivated before the effective filing date of the instant application to use the Docker tagging and labeling options to indicate and determine versions of the variant analysis models. The invention is therefore prima facie obvious.
Claims 5 and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Khalfan, Dockerfile, and Main as applied to claims 1 and 15 above, and further in view of Chowdhury.
Khalfan, Dockerfile, and Main do not explicitly teach to “determine that the indicated version of the variant analysis model is different from the previously installed version of the variant analysis model, wherein only a single version of the variant analysis model can be installed at a time; and install the indicated version of the variant analysis model based on determining that the indicated version is different from the previously installed version.”
Chowdhury teaches “[Docker] Images are multi-layered self-contained files that act as the template for creating containers. They are like a frozen, read-only copy of a container. Images can be exchanged through registries.” (Page 21, lines 18-20) Chowdhury further teaches in the section “How to Understand the Many Layers of a Docker Image,” that “[t]he upper most layer is the latest one and as you go down the layers get older. The upper most layer is the one that you usually use for running containers” and “the image comprises of many read-only layers, each recording a new set of changes to the state triggered by certain instructions. When you start a container using an image, you get a new writable layer on top of the other layers.” (Pages 56-58)
It would have been prima facie obvious to one of ordinary skill in the art at the effective
filing date of the invention to have utilized the known features of Docker to determine a previously installed version of a variant analysis models is different from an indicated version and to install the indicated version as the only available model. Chowdhury discloses that “[b]y utilizing this concept, Docker can avoid data duplication and can use previously created layers as a cache for later builds. This results in compact, efficient images that can be used everywhere.” (Page 58, lines 21-23) Therefore, one of ordinary skill in the art would have been motivated before the effective filing date of the instant application to use the Docker multi-layer framework to install the indicated version of the variant analysis model as the top layer to ensure it is the version being used. The invention is therefore prima facie obvious.
Claim 6 is rejected under 35 U.S.C. 103 as being unpatentable over Khalfan, Dockerfile, and Main as applied to claim 1 above, and further in view of Chowdhury.
Khalfan, Dockerfile, and Main do not explicitly teach to “cause the system to replace the previously installed version of the variant analysis model with the indicated version of the variant analysis model.”
As indicated above, Chowdhury teaches that the Docker framework uses layering of images and that the top layer is the usable image. (Pages 56-58) Chowdhury further discloses “[i]mages are multi-layered files and in this file, each line (known as instructions) that you've written creates a layer for your image.” (Page 50, lines 16-17) Chowdhury also teaches “[f]inally the upper most layer…which sets the default command for this image.” (Page 58, 8-10)
It would have been prima facie obvious to one of ordinary skill in the art at the effective filing date of the invention to have utilized the known features of Docker to replace a previously installed version of a variant analysis models with the indicated version of the variant analysis model. One of ordinary skill in the art would have been motivated before the effective filing date of the instant application to use the Docker multi-layer framework to install the indicated version of the variant analysis model as the top layer to ensure it is the version being used. The invention is therefore prima facie obvious.
Claim 7 is rejected under 35 U.S.C. 103 as being unpatentable over Khalfan, Dockerfile, and Main as applied to claim 1 above, and further in view of Chowdhury.
Khalfan, Dockerfile, and Main do not explicitly teach to “cause the system to install the indicated version of the variant analysis model in addition to the previously installed version such that the indicated version and the previously installed version of the variant analysis model are installed on one or more servers of the system.”
Chowdhury teaches various methods of containerizing and creating multi-container projects. Chowdhury teaches “there is an easier way to manage multi-container projects, a tool called Docker Compose. According to the Docker documentation – ‘Compose is a tool for defining and running multi-container Docker applications.’” (Page 119, lines 13-16) By creating multiple containers, it is possible to have installed multiple versions of variant analysis models at the same time. Chowdhury further discloses using a repository to run a specific version of an image by giving it a specific tag. Chowdhury teaches “[t]he repository is usually known as the image name and the tag indicates a certain build or version. Take the official mysql image, for example. If you want to run a container using a specific version of MySQL, like 5.7, you can execute docker container run mysql:5.7 where mysql is the image repository and 5.7 is the tag.” (Page 54, lines 1-5)
It would have been prima facie obvious to one of ordinary skill in the art at the effective filing date of the invention to have utilized the known features of Docker to install multiple versions of variant analysis models. By using separate containers, it is possible to have multiple variant analysis models installed and available at the same time. As seen in Khalfan, GATK4 can use multiple variant analysis models. (Page 7, Workflow Overview) One of ordinary skill in the art would have been motivated before the effective filing date of the instant application to use the Docker framework to permit the installation and accessibility of multiple variant analysis models through multiple containers or a repository. The invention is therefore prima facie obvious.
Claim 9 is rejected under 35 U.S.C. 103 as being unpatentable over Khalfan, Dockerfile, and Main as applied to claim 8 above, and further in view of Chowdhury.
Khalfan, Dockerfile, and Main do not explicitly teach “utilizing a variant analysis model manager housed on a server shared by the variant analysis model to initiate installation of the indicated version of the variant analysis model.”
As discussed above, the docker framework utilizes tags to manage available images. (Chowdhury, pages 23-24 and 25-26) Chowdhury teaches “[a]n image registry is a centralized place where you can upload your images and can also download images created by others. Docker Hub is the default public registry for Docker.” (Page 22, lines10-12) Chowdhury further teaches “ you can also create your own image registry for hosting private images. There is also a local registry that runs within your computer that caches images pulled from remote registries.” (Page 23, lines 4-6)
It would have been prima facie obvious to one of ordinary skill in the art at the effective
filing date of the invention to have utilized the known features of Docker to determine available variant analysis models and utilize a registry as a server. Therefore, one of ordinary skill in the art would have been motivated before the effective filing date of the instant application to use the container orchestration engine and registries available in Docker. The invention is therefore prima facie obvious.
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Khalfan, Dockerfile, and Main as applied to claim 8 above, and further in view of Dohsimpson. (Dohsimpson, Github: Kubernetes Documentation Part: Concepts, 21 December 2020, pages 1-642)
Khalfan, Dockerfile, and Main do not explicitly teach “determining computational availability of a genomic analysis device housing the variant analysis model for executing the genomic analysis application; and scheduling execution of the genomic analysis application by the genomic analysis device based on the computational availability of the genomic analysis device.”
The instant application references Kubernetes as an example container orchestration engine. [0095] Dohsimpson teaches “Automatic bin packing: You provide Kubernetes with a cluster of nodes that it can use to run containerized tasks. You tell Kubernetes how much CPU and memory (RAM) each container needs. Kubernetes can fit containers onto your nodes to make the best use of your resources.” (Page 5, lines 22-26) Dohsimpson further teaches “kube-scheduler: Control plane component that watches for newly created Pods with no assigned node, and selects a node for them to run on. Factors taken into account for scheduling decisions include: individual and collective resource requirements, hardware/software/policy constraints…” (Page 8, lines 22-26)
It would have been prima facie obvious to one of ordinary skill in the art at the effective
filing date of the invention to have utilized the known features of Kubernetes to determine the computational availability and to schedule the execution of the genomic analysis application based on the computational availability. Therefore, one of ordinary skill in the art would have been motivated before the effective filing date of the instant application to use the features of Kubernetes for housing and scheduling genomic analysis applications. The invention is therefore prima facie obvious.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Khalfan, Dockerfile, and Main as applied to claim 8 above, and further in view of Dohsimpson and CI/CD on AWS. (AWS Whitepaper Continuous Integration and Continuous Delivery for 5G Networks on AWS, 8 March 2021, pages 1-28) (Herein referred to as AWS.)
Khalfan, Dockerfile, and Main do not teach “identifying multiple workflow pods, wherein two or more of the multiple workflow pods specify different versions of the variant analysis model to perform their respective functions; and iteratively installing the different versions of the variant analysis model for executing each of the multiple workflow pods in series.”
The instant application states “the term ‘workflow pod’ can refer to a deployable unit of software within a container orchestration engine that includes a group of one or more workflow containers.” [0035] Dohsimpson teaches “[a] Pod…is a group of one or more containers, with shared storage/network resources, and a specification for how to run the containers.” (Page 78, lines 4-6) In “Working with Pods”, Dohsimpson discloses methods of managing multiple pods. (Page 80, line 5 – page 82, line 15) AWS teaches “a sequence of steps that are carried out iteratively to deploy changes that are part of container/configuration changes resulting in upgrades.” (Page 6, lines 1-2) The AWS CI/CD pipeline is deployed through Kubernetes, as explained on page 5. (Lines 18-19 and 26-27)
It would have been prima facie obvious to one of ordinary skill in the art at the effective
filing date of the invention to have utilized the known features of Kubernetes to manage different variant analysis models by using multiple workflow pods and to iteratively install the different versions of the variant analysis models. Therefore, one of ordinary skill in the art would have been motivated before the effective filing date of the instant application to use the features of Kubernetes for managing workflows and iteratively installing in pods. The invention is therefore prima facie obvious.
Claim 12 is rejected under 35 U.S.C. 103 as being unpatentable over Khalfan, Dockerfile, and Main as applied to claim 8 above, and further in view of Controllers. (Kubernetes Blog, Using Admission Controllers: Kubernetes, 26 December 2021, pages 1-25)
Khalfan, Dockerfile, and Main do not teach “utilizing a mutating webhook controller to identify the indicated version of the variant analysis model and to modify an application specification for the genomic analysis application to include instructions for initializing installation of the indicated version of the variant analysis model.”
Controllers teaches “there are two special controllers: MutatingAdmissionWebhook and ValidatingAdmissionWebhook. These execute the mutating and validating (respectively) admission control webhooks which are configured in the API.” (Page 2, lines 8-11) Controllers further teaches “[m]utating controllers may modify related objects to the requests they admit.” (Page 2, lines 12-13) Controllers also teaches “[a]dmission controllers limit requests to create, delete, modify objects or connect to proxy. They do not limit requests to read objects…a Kubernetes API server that is not properly configured with the right set of admission controllers is an incomplete server and will not support all the features…” (Page 3, lines 1-2 and 18-20)
It would have been prima facie obvious to one of ordinary skill in the art at the effective
filing date of the invention to have utilized the known features of Kubernetes to utilize a mutating webhook controller to identify a version of the variant analysis model and to modify application specifications. Therefore, one of ordinary skill in the art would have been motivated before the effective filing date of the instant application to use the features of Kubernetes to use a mutating webhook controller. The invention is therefore prima facie obvious.
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over Khalfan, Dockerfile, Main, and Controllers as applied to claim 12 above, and further in view of Dohsimpson.
Khalfan, Dockerfile, Main, and Controllers do not teach “adding an initialization workflow container to the application specification that communicates with a variant analysis model manager to install the indicated version of the variant analysis model.”
Dohsimpson discloses the use of init containers, in general. (Pages 94-100) Dohsimpson teaches “init containers: specialized containers that run before app containers in a Pod. Init containers can contain utilities or setup scripts not present in an app image.” (Page 94, lines 2-4) Dohsimpson further teaches “Init containers are exactly like regular containers, except: Init containers always run to completion [and] [e]ach init container must complete successfully before the next one starts.” (Page 94, lines 11-14) Dohsimpson also teaches “Init containers can contain utilities or custom code for setup that are not present in an app image [and] [t]he application image builder and deployer roles can work independently without the need to jointly build a single app image.” (Page 95, lines 4-5 and 9-10) Dohsimpson additionally teaches “[b]ecause init containers run to completion before any app containers start, init containers offer a mechanism to block or delay app container startup until a set of preconditions are met.” (Page 95, lines 14-16)
It would have been prima facie obvious to one of ordinary skill in the art at the effective
filing date of the invention to have utilized the known features of Kubernetes to utilize an init container as an initialization workflow container to communicate with the model manager to install the indicated version of the variant analysis model. Therefore, one of ordinary skill in the art would have been motivated before the effective filing date of the instant application to use the features of Kubernetes init containers to use include instructions that would communicate with the variant analysis model manager to install the indicated model before initiating the workflow. The invention is therefore prima facie obvious.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Khalfan, Dockerfile, and Main as applied to claim 15 above, and further in view of Chowdhury.
Khalfan, Dockerfile, and Main do not explicitly teach “determining that the indicated version of the variant analysis model is stored within a remote repository storing multiple versions of the variant analysis model; and providing instructions to a server to install the indicated version of the variant analysis model based on determining that the indicated version is stored within the remote repository.”
As discussed above, the docker framework utilizes tags to manage available images. (Chowdhury, pages 23-24 and 25-26) Chowdhury teaches “[a]n image registry is a centralized place where you can upload your images and can also download images created by others. Docker Hub is the default public registry for Docker.” (Page 22, lines10-12) Chowdhury further teaches “ you can also create your own image registry for hosting private images. There is also a local registry that runs within your computer that caches images pulled from remote registries.” (Page 23, lines 4-6)
It would have been prima facie obvious to one of ordinary skill in the art at the effective
filing date of the invention to have utilized the known features of Docker to determine the indicated variant analysis model is stored in a remote repository and provide instructions to install the indicated version from the remote repository. Therefore, one of ordinary skill in the art would have been motivated before the effective filing date of the instant application to use the registry feature available in Docker to store multiple versions of variant analysis models and to permit the indicated versions to be accessed from the registry for installation. The invention is therefore prima facie obvious.
Claim 17 is rejected under 35 U.S.C. 103 as being unpatentable over Khalfan, Dockerfile, and Main as applied to claim 15 above, and further in view of Dohsimpson and AWS.
Khalfan, Dockerfile, and Main do not teach “identify multiple additional genomic analysis applications…and sequentially execute each of the multiple additional genomic analysis applications by iteratively: installing a version of the variant analysis model for a current genomic analysis application of the multiple additional genomic analysis applications to replace a version from a previous genomic analysis application of the multiple additional genomic analysis applications; and executing the current genomic analysis application utilizing the version of the variant analysis model for the current genomic analysis application.”
As discussed above, Dohsimpson teaches using organizing containers in pods and managing various workflows through pod deployment options. (Pages 80-82) Further, as discussed above, AWS teaches performing use a sequence of steps to iteratively update a container workflow. (Page 6, lines 1-2) Additionally, AWS teaches “[t]he CI/CD pipeline is built using AWS CodePipeline, and utilizes a continuous delivery service that models, visualizes, and automates the steps required to release software. By defining stages in a pipeline, you can retrieve code from a source code repository, build that source code into a releasable artifact, test the artifact, and deploy it to production. Only code that successfully passes through all these stages will be deployed. You can optionally add other requirements to your pipeline, such as manual approvals, to help ensure that only approved changes are deployed to production.” (Page 6, lines 7-12) AWS further teaches “[t]he Helm charts are implemented in a sequence as per the application’s needs, and check for the status of the Kubernetes PODs before moving to the next step in the deployment.” (Page 9, lines 12-14)
It would have been prima facie obvious to one of ordinary skill in the art at the effective
filing date of the invention to have utilized the known features of Kubernetes to manage different genomic analysis applications and variant analysis models, to iteratively install the different versions of the variant analysis models, and to execute the genomic analysis model utilizing the indicated version of the variant analysis model. Therefore, one of ordinary skill in the art would have been motivated before the effective filing date of the instant application to use the available features of Kubernetes and AWS for managing workflows and iteratively installing software options. The invention is therefore prima facie obvious.
Claim 18 is rejected under 35 U.S.C. 103 as being unpatentable over Khalfan, Dockerfile, and Main as applied to claim 15 above, and further in view of Van Rooyen.
Khalfan, Dockerfile, and Main do not teach to “receive sequencing data comprising the nucleotide base calls from a sequencing device; and execute the genomic analysis application to analyze the nucleotide base calls utilizing a field programmable gate array configured to execute the indicated version of the variant analysis model.”
Van Rooyen teaches using a field programmable gate array as part of genomics analysis platform for executing a sequence analysis pipeline. (Claims 1, 7, 8, 19, and 26) Van Rooyen further teaches that the first set of genomic processing steps includes base calling. (Claim 9)
It would have been prima facie obvious to one of ordinary skill in the art at the effective
filing date of the invention to have incorporated the use of base calls and the field programmable gate array (FPGA) of Van Rooyen with the genomic and variant analysis methods of Khalfan, Dockerfile, and Main. Receiving sequencing data as nucleotide base calls is a common initial step in genomic analysis, as described in Van Rooyen. (Figures 41 and 51; Page 83, column 20, lines 42-44) FPGAs are known to improve efficiency by processing multiple workflows in parallel and allowing for changes to the programming of the system. As disclosed in Van Rooyen, “where the integrated circuit is an FPGA, such steps in the sequence and/or further analysis process may involve the partial reconfiguration of the FPGA during the analysis process.” (Page 75, column 3, lines 6-9) Van Rooyen further discloses benefits for use of an FPGA “when processing data through a genomics pipeline, as herein described, such as to accelerate overall processing function, timing, and efficiency, a number of different operations may be run on the data, which operations may involve both software and hardware processing components.” (Page 78, column 9, lines 4-9) Therefore, one of ordinary skill in the art would have been motivated before the effective filing date of the instant application to incorporate receiving nucleotide base calls as a source of genomics information and utilizing an FPGA into the genomic and variant analyses to increase efficiency and allow for reconfiguration. The invention is therefore prima facie obvious.
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over Khalfan, Dockerfile, and Main as applied to claim 15 above, and further in view of Controllers and Dynamic. (Kubernetes Blog, Dynamic Admission Controller: Kubernetes, 26 October 2021, pages 1-18)
Khalfan, Dockerfile, and Main do not teach “ to select a genomic analysis device as a location for installing the indicated version of the variant analysis model by utilizing a mutating webhook controller to identify a resource label within the application specification that specifies the genomic analysis device.”
As discussed above, Controllers teaches utilizing a mutating webhook controller to identify a version of the variant analysis model and to modify application specifications. (Pages 2-3) Controllers further teaches “[t]his admission controller automatically attaches region or zone labels to PersistentVolumes as defined by the cloud provider (for example, GCE or AWS). It helps ensure the Pods and the PersistentVolumes mounted are in the same region and/or zone.” (Page 18, lines 16-19) Additionally, Controllers teaches using the “Configuration Annotation Format: PodNodeSelector uses the annotation key scheduler.alpha.kubernetes.io/node-selector to assign node selectors to namespaces.” (Page 19, lines 16-19) Dynamic teaches that “webhooks may optionally limit which requests are intercepted based on the labels of the objects they would be sent, by specifying an objectSelector . If specified, the objectSelector is evaluated against both the object and oldObject that would be sent to the webhook, and is considered to match if either object matches the selector. (Page 9, lines 14-16)
It would have been prima facie obvious to one of ordinary skill in the art at the effective
filing date of the invention to have utilized the known features of Kubernetes to utilize a mutating webhook controller to identify a resource label to identify a genomic analysis device and install a variant analysis model. Therefore, one of ordinary skill in the art would have been motivated before the effective filing date to select a genomic analysis device as a location for installing the indicated version of the variant analysis model by utilizing a mutating webhook controller to identify a resource label within the application specification that specifies the genomic analysis device. to use the features of Kubernetes to use a mutating webhook controller. The invention is therefore prima facie obvious.
Conclusion
Claims 1-20 are eligible under 35 USC 101 (eligibility). Even though independent claims 1, 8, and 15 include the potentially mental steps of identifying an application and determining a version of a model, those mental processes are integrated into particular computer steps of selecting versions of software that do not have a reasonable mental analog. (Step 2A: Prong 2).
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure. Rockowitz et al teaches a genomics learning system (GLS) that integrates analytical systems, including machine learning algorithms for automated variant classification and prioritization. (NPJ Genomic Medicine, 6 July 2020, pages 1-12) Rockowitz further teaches that the GLS uses Emedgene, a machine learning and automated variant classification application that can prioritize variants in family analyses. Emedgene generates a shortlist of potential causative variants along with supporting evidence, using an automated machine learning engine and a knowledge graph containing gene-disease relationships and polymorphism variant information. Ahmed et al discloses Bioinformatics Workflow Management Systems (WfMSs) are software components employed to for computational pipelines capable of efficiently orchestrating complex analysis stages while handling large volumes of data across heterogeneous computational environments. (Nature: Scientific Reports, 4 November 2021, pages 1-18) Ahmed et al further teaches considerations for scalable genomic workflow management systems with a variant-calling genomic pipeline through systematic evaluation of key features of popular bioinformatics WfMSs in use today, such as Nextflow, CWL, WDL and Swift/T. Reiter et al teaches a container-based bioinformatics workflow system with built-in functionality that facilitates and simplifies running analysis pipelines. (GigaScience, 13 January 2021, pages 1-19) Reiter et al further teaches workflow systems integrated with software management tools (e.g., conda, singularity, docker) that can automate software installation for each step, branching, parallelization, conditional execution, quality control and portability.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to SHARON LEVINE GRAFF whose telephone number is (571)317-0219. The examiner can normally be reached Mon - Fri 7:30 AM - 4 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, Karlheinz Skowronek can be reached at (571) 272-9047. 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.
/S.L.G./Examiner, Art Unit 1687
/Karlheinz R. Skowronek/Supervisory Patent Examiner, Art Unit 1687
Prosecution Insights