DETAILED ACTION
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-3, 6-12, 17-21, and 26-30 are pending and are examined on the merits.
Claims 4-5, 13-16, and 22-25 are canceled.
Priority
As recorded on the 04/28/2023 filing receipt, the instant application is a CON of 16/771,451 06/10/2020 PAT 11,640,859 which is a 371 of PCT/US2019/056713 10/17/2019 which claims benefit of 62/746,997 10/17/2018 and said 16/771,451 06/10/2020 claims benefit of 62/902,950 09/19/2019. Accordingly, the effective filing date of the claimed invention is 10/17/2018.
At this point in examination, all claims have been interpreted as being accorded this priority date. In future actions, the effective filing date of one or more claims may change, due to amendments to the claims, or further analysis of the disclosure(s) of the priority application(s).
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 04/26/2023, 09/29/2023, and 02/15/2024 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the list of cited references was considered in full by the examiner. A signed copy of the corresponding 1449 form has been included with this Office action.
Drawings
The drawings filed 04/11/2023 are accepted.
Objection to the specification: title
The title should be amended to more specifically reflect the claims, particularly the independent claims and referencing steps/elements: setting the context of the invention, particular to all claims, and distinguishing the instant application from any related applications. The title should be "descriptive" and "as... specific as possible" (MPEP 606, 1st para. and 37 CFR 1.72; also MPEP 606.01 pertains).
Claim rejections - 112(b)
The following is a quotation of 35 USC 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.
Claims 1-30 is rejected under 112(b), as indefinite for failing to particularly point out and distinctly claim the subject matter which applicant regards as the invention. Claims depending from rejected claims are rejected similarly, unless otherwise noted, and any amendments in response to the following rejections should be applied throughout the claims, as appropriate. With regard to any suggested amendment below, for claim interpretation during the present examination it is assumed that each amendment suggested here is made. However equivalent amendments also would be acceptable.
The following issues cause the respective claims to be rejected under 112(b) as indefinite:
Claim 1 recites "storing a plurality of micro-service programs, operational user application programs, and analytical user application programs," but the phrasing is ambiguous as to whether two or all three of the recited elements are required. It does not appear that "plurality of" is appropriate in this construction. Claims 29-20 are rejected similarly.
Claim 29 is to a 101 machine or manufacture, i.e. a "system" in this instance, interpreted by statute according to its claimed physical structure, but it is not clear what is the structure associated with the recited instances of "...programs..." Therefore, it is not clear whether the claim is limited according to the recited programs. MPEP 2106.03, 5th-6th paras. pertain. The recited "system" is interpreted as not clearly requiring structure linking the "system" to the recited software in a structural sense appropriate to a claim to a machine or manufacture. While the recited elements may comprise unrecited software storage in some embodiments, it is not clear that all embodiments of these elements must comprise software storage corresponding to the recited process steps. Structure should be recited specifically corresponding to stored software. This rejection might be overcome by, for example, reciting a data storage device, comprised by the "system" (and the "computer system" if so intended), the storage device comprising the "programs."
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-3, 6-12, 17-21, and 26-30 are rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
The Supreme Court has established a two-step framework for this analysis, wherein a claim does not satisfy § 101 if (1) it is “directed to” a patent-ineligible concept, i.e., a law of nature, natural phenomenon, or abstract idea, and (2), if so, the particular elements of the claim, considered “both individually and as an ordered combination,” do not add enough to “transform the nature of the claim into a patent-eligible application.” Elec. Power Grp., LLC v. Alstom S.A., 830 F.3d 1350, 1353 (Fed. Cir. 2016) (quoting Alice, 134 S. Ct. at 2355). Applicant is also directed to MPEP 2106.
Step 1: The instantly claimed invention (claim(s) 1-3, 6-12, 17-21, and 26-28 being representative) is directed to a method and (claim(s) 29 and 30 being representative) is directed to a system. Therefore, the instantly claimed invention falls into one of the four statutory categories. [Step 1: YES]
Step 2A: First it is determined in Prong One whether a claim recites a judicial exception, and if so, then it is determined in in Prong Two if the recited judicial exception is integrated into a practical application of that exception.
Step 2A, Prong 1: Under the MPEP § 2106.04, the Step 2A (Prong 1) analysis requires determining whether a claim recites an abstract idea, law of nature, or natural phenomenon.
Claims 1-3, 6-12, 17-21, and 26-30 recite the following steps which fall under the mathematical concepts, mental processes, and/or certain methods of organizing human activity groupings of abstract ideas:
Claims 1, 29, and 30 recite consuming defined subsets of the system data to generate a new data product; and consuming the new data product by others of the micro-service programs or the operational or analytical user application programs; the limitation “consuming” given the plain meaning of consuming encompasses observation, evaluation, judgment, and opinion (See MPEP 2106.04(a)(2), subsection III.) performable by human mind (mental process), since human mind is capable of consume/use data to generate new data (see instant specification [0011]: “The term "consume" will be used to refer to any type of consideration, use, modification, or other activity related to any type of system data”).
Claims 1, 29, and 30 further recite storing system data received from a plurality of different sources in a database, storing the new data product in a second database; the limitations storing data in a database is considered a mental process, since humans are capable of storing data ina database/table.
Claims 7 and 8 recite shaping the system data; the limitations shaping data, as disclosed in claim 8, involves mathematical calculation by using mathematical modeling such as optical character recognition and natural processing language, and as such, falls into mathematical concepts groupings of abstract ideas. Said limitation also can be practically performed in human mind (mental process), using a pen and paper or computer, since humans are capable of shaping/ (filtering, renaming, removing data), as disclosed in instant specification (instant specification [0052]: “the step of shaping includes at least one manual step to be performed by a system user and wherein the system adds a data shaping activity to a user's work queue …”; [00203]: “the data shaping process may take many forms and may include a plurality of data processing steps that ultimately result in optimal system structured data sets”).
Claim 10 recites identifying metadata associated with the system data; the limitation “identifying”, given the plain meaning of identifying, encompasses observation, evaluation, judgment, and opinion (See MPEP 2106.04(a)(2), subsection III.) performable by human mind (mental process), since human mind is capable of identifying metadata/ (data about data)/ data type, date and time, … as discloses in instant specification [00167].
Claim 17 recites generating an alert indicating that the new data product is ready for consumption; the limitation generating an alert is considered a mental process, since humans are capable of generating an alert/message.
Claim 19 recites monitoring the alert and determining if new data is to be consumed by that micro-service program independent of all other micro-service programs; the limitations monitoring and determining, given the plain meaning of monitoring and determining, are considered mental processes, since humans are capable of monitoring alerts/messages and determining a condition.
Claim 20 recites monitoring for the alert, determining whether the new data corresponding to the alert satisfies the data- consumption definition; and consuming, by the micro-service program, the new data when the alert satisfies the data- consumption definition; the limitations monitoring, determining, and consuming are mental processes (see above rejections).
Claims 2-6, 9, 11-16, 18, and 21-28 provide additional information about the recited abstract ideas and additionally recited elements.
The identified claims recite a law of nature, a natural phenomenon (product of nature) and/or or fall into one of the groups of abstract ideas of mathematical concepts, mental processes, and/or certain methods of organizing human activity for the reasons set forth above. See MPEP 2106.04 (a)(2) III and MPEP 2106.04 (b) I. Therefore, claims are directed to one or more judicial exception(s) and require further analysis in Prong Two. [Step 2A, Prong 1: YES]
Step 2A: Prong 2: Under the MPEP § 2106.04, the Step 2A, Prong 2 analysis requires identifying whether there are any additional elements recited in the claim beyond the judicial exception(s), and evaluating those additional elements to determine whether they integrate the exception into a practical application of the exception. This judicial exception is not integrated into a practical application for the following reasons.
The additional elements of claim(s) 1-3, 6-12, 17-21, and 26-30 include the following.
Claims 1, 29, and 30 recite storing a plurality of programs in at least one computer system.
Claim 29 further recites a system for data intake and consumption comprising plurality of programs; a database storing system data, a second database.
Claim 30 further recites a non-transitory computer-readable storage medium having stored thereon program code instructions that, when executed by a processor.
The additional elements of a system comprising a processor, plurality of programs, storing programs, and a non-transitory computer-readable storage medium are generic computer components and/or processes. There are no limitations that indicate that the processor, plurality of programs, and a non-transitory computer-readable storage medium in the computer-implemented system require anything other than generic computing systems. The courts have found the use of a computer or other machinery in its ordinary capacity for economic or other 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., a fundamental economic practice or mathematical equation) does not integrate a judicial exception into a practical application. See MPEP 2106.05(f).
Furthermore, the additional elements of a database storing system data and a second database mount to selecting a particular data source to be manipulated, therefore, insignificant extra solution activity. See MPEP 2106.05 (g).
MPEP 2106.04(d). I lists the following example considerations for evaluating whether a judicial exception is integrated into a practical application:
An improvement in the functioning of a computer or an improvement to other technology or another technical field, as discussed in MPEP §§ 2106.04(d)(1) and 2106.05(a);
Applying or using a judicial exception to effect a particular treatment or prophylaxis for a disease or medical condition, as discussed in MPEP § 2106.04(d)(2);
Implementing a judicial exception with, or using a judicial exception in conjunction with, a particular machine or manufacture that is integral to the claim, as discussed in MPEP § 2106.05(b);
Effecting a transformation or reduction of a particular article to a different state or thing, as discussed in MPEP § 2106.05(c); and
Applying or using the judicial exception in some other meaningful way beyond generally linking the use of the judicial exception to a particular technological environment, such that the claim as a whole is more than a drafting effort designed to monopolize the exception, as discussed in MPEP § 2106.05(e).
In Step 2A, Prong 1 above, claim steps and/or elements were identified as part of one or more judicial exceptions (JEs).
In Step 2B below, any remaining steps and/or elements are therefore in addition to the identified JE(s). Any such additional steps and additional elements are further discussed in Step 2B.
Here in Step 2A, Prong 2, no additional step or element clearly demonstrates integration of the JE(s) into a practical application.
At this point in examination, it is not yet the case that any of the Step 2A, Prong 2 considerations enumerated above clearly demonstrates integration of the identified JE(s) into a practical application. Referring to the considerations above, none of 1. an improvement, 2. treatment, 3. a particular machine or 4. a transformation is clear in the record.
Therefore, the additionally recited elements amount to generic computer components and/or insignificant extra-solution activity and, as such, the claims as a whole do no integrate the abstract idea into practical application. See MPEP 2106.05(g). Thus, claims 1-3, 6-12, 17-21, and 26-30 are directed to an abstract idea. [Step 2A, Prong 2: NO]
Step 2B: In the second step it is determined whether the claimed subject matter includes additional elements that amount to significantly more than the judicial exception. An inventive concept cannot be furnished by an abstract idea itself. See MPEP § 2106.05.
The additional elements of claim(s) 1-3, 6-12, 17-21, and 26-30 include the following.
Claims 1, 29, and 30 recite storing a plurality of programs in at least one computer system.
Claim 29 further recites a system for data intake and consumption comprising plurality of programs; a database storing system data, a second database.
Claim 30 further recites a non-transitory computer-readable storage medium having stored thereon program code instructions that, when executed by a processor.
The additional elements of a system comprising a processor, plurality of programs, storing programs, and a non-transitory computer-readable storage medium are conventional computer components and/or processes. The courts have found the use of a computer or other machinery in its ordinary capacity for economic or other 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., a fundamental economic practice or mathematical equation) does not provide significantly more. See Affinity Labs v. DirecTV, 838 F.3d 1253, 1262, 120 USPQ2d 1201, 1207 (Fed. Cir. 2016) (cellular telephone); TU CommunicationsLLCv. AV Auto, LLC, 823 F.3d 607,613,118 USPQ2d 1744, 1748 (Fed. Cir. 2016) (computer server and telephone unit).
Furthermore, the additional elements of a database storing system data and a second database mount to selecting a particular data source to be manipulated, therefore, insignificant extra solution activity. See MPEP 2106.05 (g).
Therefore, the additional element is not sufficient to amount to significantly more than the judicial exception.
Taken alone, the additional elements do not amount to significantly more than the above-identified judicial exception(s). Even when viewed as a combination, the additional elements fail to transform the exception into a patent-eligible application of that exception. Thus, the claims as a whole do not amount to significantly more than the exception itself. [Step 2B: NO]
Therefore, the instantly rejected claims are not drawn to eligible subject matter as they are directed to an abstract idea without significantly more.
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, 2, 6, and 26-30 are rejected under 35 U.S.C. 103 as being unpatentable over Bagaev (US 20180358118 A1; as cites on the attached form 892) in view of Baker (US 10340046 B2; as cites on the attached form 892), and further in view of Toohey (US 20170092060 A1; as cites on the attached form 892).
Regarding claims 1 and 29-30, Baker discloses a platform and supported graphical user interface (GUI) decision-making tools for use by medical practitioners and/or their patients, e.g., to aide in the process of making decisions about a course of cancer treatment and/or to track treatment and/or the progress of a disease (abstract). The platform comprising a processor and
a memory having instructions stored thereon, where receive and store a plurality of medical images in a database, each medical image associated with a particular patient; (ii) access one or more of the medical images or related data associated with a particular patient (for example. Microservices) from the database upon user request for transmission to the user for display on a user computing device; (iii) automatically analyze one or more of the medical images; (iv) generate a radiologist report for a patient according to one or more of the medical images for the patient (for example, operational and analytical programs); and (v) apply a machine learning algorithm to update a process for automatically analyzing one or more of the medical images using accumulated image data in the database (claim 1). Baker further discloses that the platform uses a series of functional units with limited scope referred to as microservices. Each microservice handles an isolated set of tasks such as image storage, calculation of a risk index, identification of medical image type, and other tasks (col. 9, para. 1). Baker further discloses that the architecture allows for components to be improved or replaced without affecting other parts of the platform (col. 29, para. 2).
Further regarding limitations of the system data includes clinical records data the clinical records data including cancer state information, treatment types, and treatment efficacy information of claims 1 and 30, Bagaev discloses a software program may provide a user with a visual representation presenting information related to a patient's biomarkers scores (e.g., a biomarker score, and/or a therapy score, and/or an impact score), and predicted efficacy of a therapy. Such a software program may execute in any suitable computing environment including, but not limited to, a cloud-computing environment, a device co-located with a user (e.g., the user's laptop, desktop, smartphone, etc.), one or more devices remote from the user (e.g., one or more servers), etc. According to one aspect, one or more computer programs that when executed perform methods of the technology described herein need not reside on a single computer or processor, but may be distributed in a modular fashion among different computers or processors to implement various aspects of the technology described herein.) [0153], [0429] and [0439].
Bagaev further discloses systems and methods for determining therapy scores for multiple therapies based on normalized biomarker scores comprises, in some embodiments, accessing sequence data for a subject, accessing biomarker information indicating distribution of values for biomarkers associated with multiple therapies, determining normalized biomarker scores for the subject using sequencing data and biomarker information, and determining therapy scores for the multiple therapies based on normalized biomarker scores. Recent advances in personalized genomic sequencing and cancer genomic sequencing technologies have made it possible to obtain patient-specific information about cancer cells (e.g., tumor cells) and cancer microenvironments from one or more biological samples obtained from individual patients. The methods described are based on in part on the analysis of anthropometric, clinical, tumor, and/or cancerous cell microenvironment parameters, and tumor and/or cancerous cell parameters of a subject (e.g., a patient), along with accompanying disease information. For such analyses, sequence data such as that from transcriptome, exome, and/or genome sequencing of a patient's tumor biopsy, or from other tissues of the patient are suitable although any type of sequence data may be used. The techniques described herein may be implemented in the illustrative environment 100 shown in FIG. 1A. As shown in FIG. 1A, within illustrative environment 100, one or more biological samples of a patient 102 may be provided to a laboratory 104. Laboratory 104 may process the biological sample(s) to obtain sequencing data (e.g., transcriptome, exome, and/or genome sequencing data) and provide it, via network 108, to at least one database 106 that stores information about patient 102. The parameters of the subject (e.g., the patient), the type of tumor, or the type of cancerous cell may have been identified in group clinical trials that were published in scientific journals or actively used in clinically approved analyses, guidelines of treatment options (FDA, NIH, NCCN, CPIC, etc.) or elsewhere.) [0011], [0065], [0074], and [0154]; reading on limitations of a system and method for data intake and consumption, the method comprising the steps of: storing a plurality of micro-service programs, operational user application programs, and analytical user application programs in at least one computer system; storing system data received from a plurality of different sources in a database, the system data includes clinical records data in original forms, the clinical records data including cancer state information, treatment types, and treatment efficacy information.
Bagaev further discloses systems and methods that normalize biomarker scores to a common scale, thereby allowing comparison of biomarker scores across different cell populations and/or among different subjects. Normalized biomarker scores may be determined for any number of biomarkers as described herein. As used herein, the term “normalized biomarker score” refers to a biomarker value that has been adjusted (e.g., normalized) to a common scale according to the techniques described herein. In some embodiments, biomarker values are normalized to create normalized biomarker scores based on a respective distribution of values for each biomarker in a reference subset of biomarkers. In some embodiments, the reference subset of biomarkers comprises biomarker information from any number of reference subjects. In one embodiment, a “reference subset” is a subset of biomarkers from one or more reference subjects, the values of which may be used to normalize a biomarker of a subject. As shown in FIG. 1A, illustrative environment 100 includes one or more external databases 116, which may store information for patients other than patient 102. For example, external databases 116 may store expression data (of any suitable type) for one or more patients, medical history data for one or more patients, test result data (e.g., imaging results, biopsy results, blood test results) for one or more patients, demographic and/or biographic information for one or more patients, and/or any other suitable type of information.).
Bagaev further discloses at least a database to store information about the patient and at least a database to store sequencing data for the patient, expression data for the patient, medical history data for the patient, test result data for the patient, and/or any other suitable information about the patient; one or more external databases; information stored in patient information database and/or in external database(s) may be used to perform any of the techniques described herein [0098]-[0100], and [0156]-[0157]; reading on limitations of consuming, by each of the micro-service programs, defined subsets of the system data to generate a new data product; storing the new data product in a second database; and consuming the new data product by others of the micro-service programs or the operational or analytical user application programs.
Further regarding limitations of consuming, by each of the micro-service programs, defined subsets of the system data to generate a new data product, and consuming the new data product by others of the micro-service programs or the operational or analytical user application programs Toohey discloses an event-driven microservice architecture where each service only accesses local storage and this storage is not shared with other running instances. Storage can be replicated and kept synchronized across all running instances of the same service via sync queues implemented on the distributed message system. Services that are not micro-services may use shared storage but this storage will be clustered [0103]. Toohey further discloses that the data returned from this service can be in the form of a JSON document. Services consuming this service read only the minimum amount of data they require (for example, consuming defined subsets of the system data). The format of the data can be based on the json-api.org description of JSON API documents [0064]. Toohey further discloses organizing data stored in the one or more data storage devices according to a first data model; reconstructing data using at least a subset of information stored in at least the storage queue and organizing the reconstructed data according to a second data model different from the first data model, where Data stored in the one or more data storage devices can be independent of whichever data model is used to organize or characterize the data [0026] (claim 23).
Regarding claim 2, Baker discloses that each microservice handles an isolated set of tasks such as image storage, calculation of a risk index, identification of medical image type, and other tasks. Bagaev discloses systems and methods that normalize biomarker scores to a common scale, thereby allowing comparison of biomarker scores across different cell populations and/or among different subjects (col. 29, para. 1).
Bagaev discloses that biomarker values are normalized to create normalized biomarker scores based on a respective distribution of values for each biomarker in a reference subset of biomarkers [0098]-[0100] (see also, biomarker threshold in [0222]); reading on limitations of wherein the subsets of the system data are defined according to a data consume definition associated with each respective micro-service program.
Regarding claim 6, Baker discloses providing an easily - understood, user - friendly, interactive, controllable organ structures, sub - organs, a patient ' s condition to the patient (and / or to the physician, or to the patient ' s family with the patient ' s permission (col. 3, para. 2). Baker further discloses accessing one or more of the medical images and/or related data associated with a particular patient from the database upon user request for transmission to the user for display on a user computing device and generating a radiologist report for a patient according to one or more of the medical images for the patient (col. 36, para. 2); reading on limitations of wherein the new data product comprises a data model optimized for a particular user application.
Regarding claim 26, Baker discloses Each microservice handles an isolated set of tasks such as image storage, calculation of a risk index, identification of medical image type, and other tasks (for example, sequencing data) (col. 29, para. 1).
Bagaev discloses Systems and methods for determining therapy scores for multiple therapies based on normalized biomarker scores comprises, in some embodiments, accessing sequence data for a subject, accessing biomarker information indicating distribution of values for biomarkers associated with multiple therapies, determining normalized biomarker scores for the subject using sequencing data and biomarker information, and determining therapy scores for the multiple therapies based on normalized biomarker scores [0009]; reading on limitations of wherein the system data includes genomic sequencing data for a patient's cancerous cells and normal cells, the genomic sequencing data generated by a next generation genomic sequencer.
Regarding claim 27, Bagaev discloses that the parameters of the subject (e.g., the patient), the type of tumor, or the type of cancerous cell may have been identified in group clinical trials that were published in scientific journals or actively used in clinically approved analyses, guidelines of treatment options (FDA, NIH, NCCN, CPIC, etc.) or elsewhere. These parameters are biomarkers, the presence or absence of which and/or levels of which may be statistically significantly correlated (e.g., the correlation may be at least a threshold amount away from zero) with treatment response or patient survival [0074]; reading on limitations of wherein each cancer state includes a plurality of factors, the method further including the steps of using a processor to automatically perform the steps of analyzing patient genomic sequencing data that is associated with patients having at least a common subset of cancer state factors to identify treatments of genomically similar patients that experience treatment efficacies relative to a threshold level.
Regarding claim 28, Bagaev discloses that the parameters of the subject (e.g., the patient), the type of tumor, or the type of cancerous cell may have been identified in group clinical trials that were published in scientific journals or actively used in clinically approved analyses, guidelines of treatment options (FDA, NIH, NCCN, CPIC, etc.) or elsewhere. These parameters are biomarkers, the presence or absence of which and/or levels of which may be statistically significantly correlated (e.g., the correlation may be at least a threshold amount away from zero) with treatment response or patient survival [0074]. Bagaev further discloses that the techniques described herein provide a way to generate “thresholds” for pre-defined biomarkers based on (e.g., large volumes of) data obtained from large numbers of patients, such as TCGA, ICGC, Human Protein Atlas, etc., allowing for the creation of a normalized score for each of the biomarkers. Combinations of normalized biomarker scores for the patient may be used to analyze one more defined therapies (creating therapy scores) providing information that allows the selection of one or more therapies for each patient based on their personal parameters [0076]; reading on limitations of wherein each cancer state includes a plurality of factors, the method further including the steps of using a processor to automatically identify, for specific cancer types, highly efficacious cancer treatments and, for each highly efficacious cancer treatment, identify at least one genomic sequencing data subset that is different for patients that experienced treatment efficacy above a first threshold level when compared to patients that experienced treatment efficacy below a second threshold level.
In KSR Int 'l v. Teleflex, the Supreme Court, in rejecting the rigid application of the teaching, suggestion, and motivation test by the Federal Circuit, indicated that “The principles underlying [earlier] cases are instructive when the question is whether a patent claiming the combination of elements of prior art is obvious. When a work is available in one field of endeavor, design incentives and other market forces can prompt variations of it, either in the same field or a different one. If a person of ordinary skill can implement a predictable variation, § 103 likely bars its patentability.” KSR Int'l v. Teleflex lnc., 127 S. Ct. 1727, 1740 (2007).
Applying the KSR standard to Baker, Bagaev, and Toohey Examiner concludes that this combination represents the use of known techniques to improve similar methods. Baker, Bagaev, and Toohey are directed to using a collection of services to exchange and manage data. Baker only disclosed the general microservice architecture in healthcare having plurality of microservices to handle an isolated set of tasks such as image storage, calculation of a risk index, identification of medical image type, and other tasks. In the same field of research, Bagaev provided the specifics of the system data that includes clinical records data in original forms, the clinical records data including cancer state information, treatment types, and treatment efficacy information. Toohey further described the specifics of the microservice architecture, consuming a specific subset of data system. Combining the microservice architecture of Baker and Toohey with the specific system data types of Bagaev would have improved overall patient healthcare and treatment plans for specific patients. One ordinary skilled in the art before he effective filing data of the claimed invention would have had a reasonable expectation of success at combining the method of Baker, Bagaev, and Toohey. This combination would have been expected to have a suite of tools to healthcare providers and researchers enabling better cancer management. Therefore, the invention would have been prima facie obvious to one of skill in the art before the effective filing date of the claimed invention, absent evidence to the contrary.
Claims 3, 7-9, and 12 are rejected under 35 U.S.C. 103 as being unpatentable over Baker in view of Bagaev, further in view of Toohey, as applied to claims 1-2, 6, 26-30 above, and further in view of Neff (US 20140365242 A1; as cited on the attached Form 892).
Claims 3, 7-9, and 12 depend on claim 1. Limitations of claim 1 have been taught in the above rejections.
Regarding claim 3, Baker discloses that any of the microservices described herein can be separated, combined or incorporated into single or combined modules and/or services (col. 36, para. 1).
Bagaev discloses that the information stored in at least one database may be stored in any suitable format and/or using any suitable data structure(s), as aspects of the technology described herein are not limited in this respect [0156]. Bagaev further discloses that program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Typically, the functionality of the program modules may be combined or distributed [0430].
Further regarding limitations of the defined subsets of the system data: comprises data to which optical character recognition and natural language processing techniques have already been applied, Neff discloses a framework for integrating multiple patient-related input data streams where input data may be translated into structured data (abstract) [0009]. Neff further discloses that the input data maybe acquired by ne or more networked pervasive devices, such as position sensors, measurement devices, audio sensors, video sensors, motion sensors, cameras, wearable sensors with integrated displays, healthcare instruments and so forth. Input data may also be automatically collected by a data miner from one or more external data sources. Such captured information is assimilated by, for example, automatically transforming the unstructured or semi-structured data (e.g., text, audio and/or video stream, images, etc.) into structured data (e.g., patient record) [0022].
Neff further discloses that Data analysis engine may automatically convert unstructured or semi-structured data into a structured format. If the data is originally unstructured information (e.g., “free-text” output of speech recognition), it may be converted into structured data using various techniques, such as Natural Language Processing (NLP), NLP using machine learning, NLP using neural networks, image translation and processing, etc. [0051]. Neff further discloses that the Data analysis engine may also identify the patient by recognizing a barcode or any other optical machine-readable representation of data [0060]; reading on limitations of where at least one of the defined subsets of the system data: comprises data to which optical character recognition and natural language processing techniques have already been applied; is defined according to metadata associated with the data; or is defined according to a data type of the data.
Regarding claim 7, Baker discloses the interactive GUI element is produced from medical images of the patient [e.g., comprising one or more of the following: targeted PET images, targeted SPECT images, magnetic resonance (MR) images, ultrasound (US) images, gamma camera (i.e. scintillation camera) images, and combinations, fusions, or derivatives of any of the above] and/or other images or information (e.g., other images received and stored in the database of the network-based decision support system of any of the aspects and/or embodiments described herein) (col. 3, para. 2) (for example, shaping data by aggregating data sources).
Further Neff discloses converting unstructured or semi-structured data into a structured format [0051] and once the unstructured information is extracted from the medical records, it is stored into a data structure, such as a database or spreadsheet [0054]; reading on imitations of shaping the system data and storing the shaped data in a third database, wherein the defined subsets of the system data comprise shaped data retrieved from the third database.
Regarding claim 8, Neff discloses that the processor is operative with the computer readable program code to translate the acquired input data into the structured data by using Natural Language Processing (NLP), machine learning, neural networks, image translation and processing, or a combination thereof (claim 10). Neff further discloses that Data analysis engine may automatically convert unstructured or semi-structured data into a structured format using various techniques, such as Natural Language Processing (NLP), NLP using machine learning, NLP using neural networks, image translation and processing, etc. [0051]; reading on limitations of wherein shaping the system data comprises applying at least one of optical character recognition or natural language processing techniques to the system data.
Regarding claim 9, Neff discloses that exemplary components may operate to assimilate data (extract), transform the data into structured data (transform), make determinations based on the structured data and/or transfer the structured data (load) to, for instance, remotely-located structured sources; reading on limitations of wherein shaping the system data comprises applying an extract, transform, and load process to the system data.
Regarding claim 12, Neff discloses Structured data is in a form where the information can be easily manipulated to generate different reports and can easily be searched. Structured data has an enforced composition of different types of data (or data fields) in a database structure, and this allows for querying and reporting against the data types. Structured data may include health information stored in “organized” formats, such as charts and tables. It may include patient information organized in pre-defined fields, as well as clinical, financial and laboratory databases [0005]. Neff further discloses that the system may search, mine, extrapolate, combine, etc. input data that is in an unstructured format [0050]. Neff further discloses that data analysis engine automatically combines and translates the acquired data from the input data manager and optionally, mined data from the data miner, into structured data. Data analysis engine may automatically convert unstructured or semi-structured data into a structured format [0051]; reading on limitations of wherein the shaped system data is optimized for searching; and wherein the data being optimized for searching comprises the shaped system data being stored in a first data structure, the first data structure different than a second, different data structure in which the shaped system data can be stored, the second data structure being configured to support one or more of the user application programs; or wherein the system data is stored in a plurality of different formats, and wherein the shaped system data being optimized for searching comprises normalizing the system data into a common format.
Applying the KSR standard to Baker, Bagaev, Toohey, and Neff Examiner concludes that this combination represents the use of known techniques to improve similar methods. Baker, Bagaev, Toohey, and Neff are directed to using a collection of services to exchange and manage data. Baker, Bagaev, and Toohey only disclosed the general microservice architecture in healthcare having plurality of microservices to handle an isolated set of tasks where the system data that includes clinical records data in original forms, the clinical records data including cancer state information, treatment types, and treatment efficacy information, and further consuming only a subset of system data. In the same field of research, Neff provided the conversion of unstructured or semi-structured data into a structured format to make it easily searchable and analyzable. Combining the microservice architecture of Baker, Bagaev, and Toohey with data conversion of Neff would have enhanced analytics and reporting and provided faster querying and search. One ordinary skilled in the art before he effective filing data of the claimed invention would have had a reasonable expectation of success at combining the method of Baker, Bagaev, Toohey, and Neff. This combination would have been expected to have a suite of tools to healthcare providers and researchers enabling better cancer management. Therefore, the invention would have been prima facie obvious to one of skill in the art before the effective filing date of the claimed invention, absent evidence to the contrary.
Claims 10-11 are rejected under 35 U.S.C. 103 as being unpatentable over Baker in view of Bagaev, in view of Toohey, as applied to claims 1-2, 6, 26-30 above, in view of Neff (US20140365242A1; as cited on the attached Form 892), as applied to claims 3, 7-9, and 12 above, in view of Ringen ("Strategies for managing data in microservices”, Dec 29, 2017, jorgenringen.github,htpp://jorgenringen.github.io/2017/12/stategies_managing_data_in_microservices/, 7 pages; as cited on the attached Form 892), and further in view of Hedges (Management and Preservation of Research Data with iRODS, CIMS’07, November 9, 2007, pages 17-22; as cited on the attached Form 892) .
Claims 10 and 11 depend on claim 7. Limitations of claim 7 have been taught in the above ejections.
Regarding claims 10 and 11, Ringen discloses common patterns for managing data in a distributed microservice architecture and reveals that in a distributed microservice world, Read-only and immutable metadata is stored in libraries and used by the different microservices (pg. 5, subsection: Shared Metadata-Libraries).
Hedges discloses that Micro-services can access data held within the iCAT metadata catalogue, which is the iRODS equivalent of SRB’s MCAT. The iCAT is the iRODS CATalog, stored in a database (pg. 20, col. 1, last para.).
It would have been prima facie obvious to one ordinary skilled in the art before the effective filling date of the invention to identify metadata associated with the system data and store the identified metadata in a catalogue in a database, as disclosed by Ringen and Hedges. Storing system metadata in a separate catalog and database within a microservice architecture is recognized as part of ordinary capabilities of one skilled in the art. One ordinary skilled in the art would have been capable of applying this known technique to the known method of Baker, Bagaev, Toohey, and Neff for the purpose of preventing cross-service database coupling and improving system scalability and the results would have been predictable to one ordinary skilled in the art.
Claims 17-21 are rejected under 35 U.S.C. 103 as being unpatentable over Baker in view of Bagaev, in view of Toohey, as applied to claims 1-2, 6, 26-30 above, and further in view of Parikh (US 12348545 B1; as cited on the attached Form 892).
Claims 17-21 depends on claim 1. Limitations of claim 1 have been taught in the above rejections.
Regarding claims 17-21, Baker discloses that each microservice handles an isolated set of tasks such as image storage, calculation of a risk index, identification of medical image type, and other tasks (for example, generating an alert) (col. 29, para. 1).
Parikh discloses a customizable generative artificial intelligence (‘AI’) assistant, including: identifying one or more customizations for the generative AI assistant, the generative AI assistant configured to receive information describing a monitored deployment and a natural language input, the generative AI assistant further configured to generate a response to the natural language input; and modifying, based on the one or more customizations, the generative AI assistant (abstract).
Parikh further discloses a Data platform configured to perform one or more data analytics implemented by any suitable combination of physical and/or virtual compute resources, such as one or more computing devices, microservices, applications, etc. (col. 4, para. 3).
Parikh further discloses an alert generator that is a microservice that may be responsible for generating alerts. Alert generator may examine observations in aggregate, deduplicate them, and score them. Alerts may be generated for observations with a score exceeding a threshold (for example, data consumption definition of microservice programs in claims 20 and 21) (col. 26, para. 1).
Parikh further discloses certain portions of data may be gathered in response to detecting a particular event, other portions gathered as part of a separate process independent of any particular alert or event (col. 96, first para.)
Parikh further discloses that microservices may be deployed as self-contained Docker containers (for example, data is to be consumed by that micro-service program independent of all other micro-service programs in claim 19) (col. 23, last para.); reading on limitations of generating an alert indicating that the new data product is ready for consumption (claim 17) and wherein the alert is generated by the micro-service program that generated the respective new data product (claim 18), each micro-service program monitoring the alert and determining if new data is to be consumed by that micro-service program independent of all other micro-service programs (claim 19), monitoring, by a micro-service program, for the alert, the micro-service program including a data-consumption definition; determining whether the new data corresponding to the alert satisfies the data- consumption definition; and consuming, by the micro-service program, the new data when the alert satisfies the data- consumption definition (claim 20), wherein at least a subset of the micro-service programs specify the same data-consumption definition (claim 21).
It would have been prima facie obvious to one ordinary skilled in the art before the effective filling date of the invention to use one of the microservices for generating an alert, as disclosed by Parikh. Generating an alert using an independent microservice is recognized as part of ordinary capabilities of one skilled in the art. One ordinary skilled in the art would have been capable of applying this known technique to the known method of Baker, Bagaev, and Toohey for the purpose of indicating that the new data product is ready for consumption and the results would have been predictable to one ordinary skilled in the art.
Statutory Double Patenting
A rejection based on double patenting of the “same invention” type finds its support in the language of 35 U.S.C. 101 which states that “whoever invents or discovers any new and useful process... may obtain a patent therefor...” (Emphasis added). Thus, the term “same invention,” in this context, means an invention drawn to identical subject matter. See Miller v. Eagle Mfg. Co., 151 U.S. 186 (1894); In re Vogel, 422 F.2d 438, 164 USPQ 619 (CCPA 1970); In re Ockert, 245 F.2d 467, 114 USPQ 330 (CCPA 1957).
A statutory type (35 U.S.C. 101) double patenting rejection can be overcome by canceling or amending the claims that are directed to the same invention so they are no longer coextensive in scope. The filing of a terminal disclaimer cannot overcome a double patenting rejection based upon 35 U.S.C. 101.
Claims 1 and 30 are rejected under 35 U.S.C. 101 as claiming the same invention as that of claims 23 and 42 of prior U.S. Application No. 19/303,338, respectively. This is a statutory double patenting rejection.
Claims 1 and 30 are directed to the same invention as that of claims 23 and 42 of commonly assigned U.S. Application No. 19/303,338. Under 35 U.S.C. 101, more than one patent may not be issued on the same invention.
The USPTO may not institute a derivation proceeding in the absence of a timely filed petition. The U.S. Patent and Trademark Office normally will not institute a derivation proceeding between applications or a patent and an application having common ownership (see 37 CFR 42.411). The applicant should amend or cancel claims such that the reference and the instant application no longer contain claims directed to the same invention.
Nonstatutory double patenting
The nonstatutory double patenting rejection is based on a judicially created doctrine to prevent the improper timewise extension of the "right to exclude" granted by a patent and to prevent multiple suits against an accused infringer by different assignees of the same invention (MPEP 804.II.B, 1st para.). A nonstatutory double patenting rejection is appropriate where the conflicting claims (instant v. reference) are not identical, but an examined-application claim (instant claim) is not patentably distinct from a reference claim because the instant claim is either anticipated by, or would have been obvious over, the reference claim (MPEP 804.II.B, 2nd para.).
In cases of double patenting rejections versus reference claims of pending applications, as opposed to claims of an issued patent, the rejections are provisional because the reference claims have not been patented. Presently, no rejections are provisional.
A timely filed terminal disclaimer in compliance with 37 CFR 1.321(c) or 1.321(d) may be used to overcome an actual or provisional rejection based on nonstatutory double patenting provided the application or patent of the reference claim either is shown to be commonly owned with the instant application or claims an invention made as a result of activities undertaken within the scope of a joint research agreement. A registered attorney or agent of record may sign a terminal disclaimer. A terminal disclaimer signed by the assignee must comply fully with 37 CFR 3.73(b).
Applicant may wish to consider electronically filing a terminal disclaimer (MPEP 1490.V pertains, along with https://www.uspto.gov/patents-application-process/applying-online/eterminal-disclaimer). Electronic filing may lead to faster approval of the disclaimer. Also, if filing electronically, Applicant is encouraged to notify the examiner by telephone so that examination may resume more quickly.
The USPTO Internet website contains terminal disclaimer forms which may be used. Please visit www.uspto.gov/patent/patents-forms. The actual filing date of the application in which the form is filed determines what form (e.g., PTO/SB/25, PTO/SB/26, PTO/AIA /25, or PTO/AIA /26) should be used.
A web-based eTerminal Disclaimer may be filled out completely online using web-screens. An eTerminal Disclaimer that meets all requirements is auto-processed and approved immediately upon submission. For more information about eTerminal Disclaimers, refer to www.uspto.gov/patents/apply/applying-online/eterminal-disclaimer.
Double patenting rejections of instant claims 2-3, 6-12, 17-21, and 26-29
Instant claims 2-3, 6-12, 17-21, and 26-29 are rejected on the grounds of nonstatutory double patenting as unpatentable over one or more claims in reference application 19/303,338 in view of Bagaev (US 20180358118 A1), Baker (US 10340046 B2), Toohey (US 20170092060 A1), Neff (US20140365242A1), Ringen (NPL), Hedges (NPL) and Parikh (US 12348545 B1) -- each as cited on the attached Form 892.
The reference application as well as the instant application recite claims which involve micro-service, operational and analytical programs and a multi-source data base of cancer and treatment information.
Although the reference claims are not identical to the instant claims, in a BRI they also are not patentably distinct from the instant claims: either (i) because the instant claims recite obviously equivalent or broader limitations in comparison to the reference claims or (ii) because the instant claims recite limitations which are obvious over the cited art. It is not clear that the instant claims recite limitations which are narrower than limitations in the reference claims.
It would have been obvious in view of the cited art to modify reference claims to arrive at the rejected instant claims. Either the instant limitations are interpreted as reading on a reference limitation, or the instant limitations would have been obvious in view of the cited art. That is, to the extent that any instant claims are narrower than reference claims, then any such narrowing would have been obvious over the cited art.
Prior art made of record but not relied upon
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Shoumik (Scalable micro-service based approach to FHIR server with golang and No-SQL, 22-24 December, 2017, 2017 20th International Conference of Computer and Information Technology (ICCIT), IEEE Xplore, 5 pages).
Shoumik discloses a micro-service based health-care information management system using a defined FHIR having administration, clinical, diagnostics and medication components (pg. 2, col. 1, para. 1). Shoumik further discloses Communication between the client and API Gateway is done via the REST API. • The API Gateway handles the validity of the request via Authentication and then it passes the request to the router. • The Router decodes the request and passes the message to Service Discovery module where all the micro-services are registered. e.g, a single request might want information about a patient and diagnostic report. Those services belong to different micro-services and requests will get redirected to those service nodes via the gRPC. • Service Nodes communicate with Database Cluster and returns the result back to the Router. • The Router then combines the results in a Bundle Resource and returns the result to the client (pg. 3, col. 2. Para. 2). Shoumik further discloses performing benchmarking that Fetches a bundle resource that contains all the Observation results of a patient (for example, clinical data, treatment and lab results) using his/her unique identifier (pg. 4, col. 1, para. 4). Shoumik further discloses that micro-services are connected to a Single Couchbase Database Cluster to store health-care data; Each service is deployed to an independent zone within the cluster. Each service zone within a cluster (data, query, and index services) can now scale independently so that the best computational capacity is provided for each of them; Service Nodes communicate with Database Cluster and returns the result back to the Router (pg. 3, col. 1 and 2).
Conclusion
No claims are allowed.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to GHAZAL SABOUR whose telephone number is (703)756-1289. The examiner can normally be reached M-F 7:30-5:00.
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, Larry D. Riggs can be reached at (571) 270-3062. 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.
/G.S./Examiner, Art Unit 1686
/G. STEVEN VANNI/Primary patents examiner, Art Unit 1686
Prosecution Insights