DETAILED ACTION
This non-final Office action is responsive to Request for Continued Examination filed May 6th, 2026. Claims 1, 11, and 18 have been amended. Claims 1-20 are presented for examination.
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 .
Continued Examination Under 37 CFR 1.114
A request for continued examination under 37 CFR 1.114, including the fee set forth in 37 CFR 1.17(e), was filed in this application after final rejection. Since this application is eligible for continued examination under 37 CFR 1.114, and the fee set forth in 37 CFR 1.17(e) has been timely paid, the finality of the previous Office action has been withdrawn pursuant to 37 CFR 1.114. Applicant's submission filed on 05/06/26 has been entered.
Response to Arguments
Applicant's arguments regarding claim rejections under 35 USC 101 filed 01/08/26 have been fully considered but they are not persuasive.
On pages 10-16 of the provided remarks, Applicant argues that the amended claims present statutory subject matter. Beginning on page 11 of the provided remarks, Applicant argues “one or more features of amended independent claim 1 cannot be performed/executed by human mind.” Citing the machine elements of the claim, Applicant argues that the steps are inextricably tied to a machine/device. Examiner respectfully disagrees and asserts the claimed “a processor configured for executing one or more processes based on machine-readable instructions; and a memory storing one or more machine readable instructions, including a rules engine, that when executed by the processor cause the computing system; a reports library” are recited so generically (no details whatsoever are provided other than that they are general purpose computing components and regular office supplies) that they represent no more than mere instructions to apply the judicial exception on a computer. These limitations can also be viewed as nothing more than an attempt to generally link the use of the judicial exception to the technological environment of a computer. Even when viewed in combination, the additional elements in the claims do no more than use the computer components as a tool. Further, while Applicant argues that the amended data migration involves automated data transfer, normalization, and persistence across distinct enterprise software systems, Examiner asserts that this argument is moot as the argued receiving of incoming quality data and migrating it to a products database is not reciting the abstract idea. Applicant’s arguments are not persuasive.
Applicant continues on page 11 of the provided remarks to argue that argued analyzing of incoming data using predefined rules, “requires computational analysis of historical QA datasets, comparison across time windows, and evaluation against lifecycle-dependent expectations, all of which require machine-based temporal correlation, statistical comparison, and rule execution that are far beyond human cognitive capabilities”. Examiner asserts that the argued requirement of “machine-based temporal correlation” is not present within the claims and that the argued “statistical comparison, and rule execution” are mental judgements and evaluations. Further citing the claimed correlation of flagged quality assurance data with related quality assurance data and product lifestyle data to generate context data, Applicant argues “This correlation step involves automated cross-dataset association, relationship mapping, and contextual synthesis across multiple data domains. Such correlation cannot be performed by the human mind at scale and requires structured database querying, rule- based inference, and multi-dimensional data processing executed by the computing system.” Similar to the above response, the present claim does not recite argued requirement of “automated cross-dataset association, relationship mapping, and contextual synthesis across multiple data domains” or “structured database querying, rule- based inference, and multi-dimensional data processing executed by the computing system”. Examiner asserts that the claimed “correlating the flagged data with a related quality assurance data and products lifecycle data” can be performed as a judgment and evaluation of the human mind. Finally, Applicant argues that the automatic determination of potential causes of the flagged data, “evaluates causal relationships and prioritizes corrective actions using rule-based logic. These operations require computational evaluation of multiple possible causes, application of ranking logic, and automated output generation, which cannot be executed mentally or manually in any practical sense.” Examiner respectfully disagrees and asserts that the evaluation of multiple possible causes and application of ranking logic are mental judgments and evaluations of human mind. Therefore, the claims recite the abstract idea of mental process. Applicant’s arguments are not persuasive.
Continuing on page 12 of the provided remarks, regarding Step 2A Prong 2 analysis, Applicant argues “the subject matter of amended independent claim 1 may be practiced in automated quality assurance reporting and prescriptive analytics”. Examiner asserts, citing MPEP 2106.04(d) “Accordingly, after determining that a claim recites a judicial exception in Step 2A Prong One, examiners should evaluate whether the claim as a whole integrates the recited judicial exception into a practical application of the exception in Step 2A Prong Two. A claim that integrates a judicial exception into a practical application will apply, rely on, or use the judicial exception in a manner that imposes a meaningful limit on the judicial exception, such that the claim is more than a drafting effort designed to monopolize the judicial exception.” Therefore, it is not simply can the claim be practiced within the field, but whether or not the claim as a whole integrates the recited judicial exception into a practical application of the exception. Applicant’s arguments are not persuasive.
On pages 12-13 of the provided remarks, Applicant argues “The amended claim goes beyond merely reviewing or reporting quality data. Instead, it provides a technological solution for dynamically detecting abnormal quality behavior by generating deviation criteria based on historical quality assurance trends and expected operational timeframes derived from product lifecycle data.” Examiner respectfully disagrees and asserts that the argued incorporation of historical quality assurances trends and expected operational timeframes is merely determining flagging criteria which is a mental observation/evaluation abstract idea. Additionally, the prescriptive correction recommendation is merely recited as an element of the generated context report would not account for additional elements that integrate the judicial exception (e.g. abstract idea) into a practical application because displaying data merely add insignificant extra-solution activity and merely adds the words to apply it with the judicial exception. Further, while Applicant argues that the claimed process provides “improvement without relying on manual intervention or subjective assessment”, Examiner cites MPEP 2106.05(a)(I): ‘Examples that the courts have indicated may not be sufficient to show an improvement in computer-functionality’: iii. Mere automation of manual processes. Therefore, the argued system automating a previously manual process is insufficient to disclose implementation of a practical application. Applicant’s arguments are not persuasive.
Continuing on page 13 of the provided remarks, Applicant argues that the correlation of flagged quality assurance data with related quality assurance data and product lifecycle data to generate contextual information, “provides a technical improvement over conventional QA systems by transforming isolated quality signals into contextualized, lifecycle-aware insights.” Examiner respectfully disagrees and asserts that the claimed correlation process is not a technical improvement as the claimed correlation method is merely an abstract mental evaluation of quality assurance data as stated above. Additionally, the argued “transforming isolated quality signals into contextualized, lifecycle-aware insights” is not present within the claims as the claimed “correlating the flagged data with a related quality assurance data and products lifecycle data” is recited with a high-level of generality such that the correlation can be performed as an observation, judgement, and evaluation of the human mind. Applicant’s arguments are not persuasive.
On page 13 of the provided remarks, Applicant argues that the amended automated determination of potential causes of the flagged data, “enables the computing system to function as an automated decision-support mechanism, assisting quality teams in prioritizing remediation steps and improving operational efficiency. The ranking of corrective actions based on computed causal relationships reflects a technical data processing improvement, not a mere display of information.” Examiner respectfully disagrees and asserts that the claimed determination of potential causes of flagged data is recited with a high-level of generality such that the determination can be performed as an observation, judgement, and evaluation of the human mind. Further, regarding the improved operational efficiency argument, Examiner cites “[M]erely adding computer functionality to increase the speed or efficiency of the process does not confer patent eligibility on an otherwise abstract idea.”); Alice, 573 U.S. at 223 (“Thus, if a patent’s recitation of a computer amounts to a mere instruction to implement an abstract idea on a computer, that addition cannot impart patent eligibility.”) Applicant’s arguments are not persuasive.
Citing Specification paragraphs [0002]-[0004], [0018], [0022]-[0030], [0039]-[0045], Applicant argues “the subject matter of amended independent claim 1 is integrated into a practical application that improves the functioning of enterprise quality management systems by enabling dynamic deviation detection, lifecycle-aware contextual analysis, automated cause determination, and ranked corrective action guidance. The claim does not merely recite collecting data, analyzing it, and displaying results; rather, it discloses a technologically specific computing implementation that transforms raw quality assurance data into actionable, system-generated quality intelligence.” Examiner respectfully disagrees and asserts, as stated above, the claims do not limit the process to “a technologically specific computing implementation”, as, for example, the amended independent claim 11 recites the evaluation and analytics as being performed “by the computing system”, which would not account for additional elements that integrate the judicial exception (e.g. abstract idea) into a practical application because the claimed structure merely adds the words to apply it with the judicial exception and mere instructions to implement an abstract idea on a computer (See PEG 2019 and MPEP 2106.05). Applicant’s arguments are not persuasive.
Regarding Step 2B analysis, Applicant argues that the amended elements of independent claim 1 provide an inventive concept and amounts to significantly more than the exception itself. Applicant argues that “claimed subject matter overcomes these challenges by automating the analysis, flagging, and contextual reporting of quality assurance data, enabling real-time identification of operational anomalies and prescriptive recommendations for process optimization”. Examiner respectfully disagrees and asserts, MPEP 2106.05(I)(A) recites the following regarding ‘Relevant Considerations For Evaluating Whether Additional Elements Amount To An Inventive Concept’ “Limitations that the courts have found to qualify as "significantly more" when recited in a claim with a judicial exception include: i. Improvements to the functioning of a computer, e.g., a modification of conventional Internet hyperlink protocol to dynamically produce a dual-source hybrid webpage, as discussed in DDR Holdings, LLC v. Hotels.com, L.P., 773 F.3d 1245, 1258-59, 113 USPQ2d 1097, 1106-07 (Fed. Cir. 2014)”. However, as stated above, mere automation of manual processes, as argued by Applicant is insufficient to disclose an inventive concept. Applicant’s arguments are not persuasive.
Continuing on pages 14-15 of the provided remarks, Applicant argues that amended claim 1 provides technical advantages. Specifically, Applicant argues “this automated analysis eliminates the need for manual data inspection, improving efficiency, consistency, and scalability across large-scale business environments”. Examiner respectfully disagrees and asserts, as stated above, the argued system automating a previously manual process is insufficient to disclose an inventive concept. Additionally, Applicant argues “By automating quality assurance data ingestion, anomaly detection, contextual reporting, and corrective action recommendations, the claimed subject matter minimizes human effort, reduces inconsistencies in quality assessments, and enhances the accuracy of compliance monitoring.” Examiner respectfully disagrees and asserts, in addition to the automated example analysis above, "claiming the improved speed or efficiency inherent with applying the abstract idea on a computer" does not integrate a judicial exception into a practical application or provide an inventive concept. Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363. Applicant’s arguments are not persuasive.
Finally, on page 15 of the provided remarks, Applicant argues “By automating quality assurance data ingestion, anomaly detection, contextual reporting, and corrective action recommendations, the claimed subject matter minimizes human effort, reduces inconsistencies in quality assessments, and enhances the accuracy of compliance monitoring. The result is a scalable, intelligent, and adaptive quality assurance solution that leverages real-time analytics, historical performance comparisons, and automated decision-making algorithms to improve operational efficiency, ensure regulatory compliance, and optimize business processes.” Examiner respectfully disagrees and asserts, in addition to the enhanced accuracy and improved operational efficiency argument above, "claiming the improved speed or efficiency inherent with applying the abstract idea on a computer" does not integrate a judicial exception into a practical application or provide an inventive concept. Intellectual Ventures I LLC v. Capital One Bank (USA), 792 F.3d 1363. Therefore, the 35 USC 101 rejection is maintained. Applicant’s arguments are not persuasive.
Applicant's arguments regarding claim rejections under 35 USC 103 filed 01/08/26 have been fully considered but they are not persuasive.
On pages 16-22 of the provided remarks, Applicant argues that the cited prior art does not disclose the amended limitations. Beginning on page 17 of the provided remarks, Applicant argues that primary reference Selker does not “describe that the predefined rules comprise dynamically generated deviation criteria based on historical quality assurance trends and expected operational timeframes derived from product lifecycle data. Further, Selker does not teach or suggest dynamically generating deviation criteria, nor does it analyze deviations relative to historical QA trends across operational timeframes.” Examiner respectfully disagrees and asserts that the criteria matrix of Selker is analogous to the predefined rules comprising dynamically generated deviation criteria. This in combination with cited Vemireddy discloses the amended limitations argued above. Applicant’s arguments are not persuasive.
Continuing on page 18 of the provided remarks, Applicant argues “Selker does not perform correlation across multiple QA reports and product lifecycle datasets, does not determine potential causes using rule- based reasoning, and does not rank corrective actions. Furthermore, Selker's flagging is static and rule-based, applied to individual patient records without analyzing trends over time. In contrast, the amended claim introduces an adaptive system that dynamically updates flagging rules based on past QA trends and real-time report frequency analysis, stating that thresholds for flagging are not predetermined.” Examiner respectfully disagrees and cited Figure 16 of Selker to disclose the correlation of user health metrics to determine user health goals and prioritize said goals. This is analogous to the argued correlation across QA data and trends over time and in combination with the amended citations of Vemireddy disclose the amended claim limitations argued above. Applicant’s arguments are not persuasive.
Continuing on page 19 of the provided remarks, Applicant argues that cited Franco, “does not analyze deviations relative to historical QA behavior, nor does it generate deviation criteria dynamically based on evolving trends and lifecycle expectations. Furthermore, Franco’s analysis ends once an alert condition is met. Franco does not describe correlating flag data with related QA data and product lifecycle data, does not determine potential causes of flagged QA conditions, and does not generate, present, or rank recommended corrective actions.” Examiner begins by asserting that the argument by Applicant is moot as Franco is only cited to disclose the flagging criteria of the number of reports generated within a given period. Therefore, the arguments regarding “correlating flag data with related QA data and product lifecycle data, does not determine potential causes of flagged QA conditions, and does not generate, present, or rank recommended corrective actions” are moot. Further, the deviation criteria of Franco, per the citations below is dynamic based on the trend of customer scores. Therefore, Applicant’s arguments are not persuasive.
On pages 19-20 of the provided remarks, Applicant argues cited Vemireddy “provides care-plan justifications and clinical recommendations aimed at physicians and patients. Additionally, Vemireddy does not describe generating deviation criteria dynamically, nor does it compare current QA activity against historical baselines tied to lifecycle stages. At last, Vemireddy fails to describe correlating flagged QA data with related QA data and product lifecycle data to generate contextual explanations, determine potential causes, or rank corrective actions.” Examiner respectfully disagrees and asserts that the citations below of Vemireddy disclose the argued generating deviation criteria dynamically; comparing current QA activity against historical baselines; and correlating flagged QA data with related QA data to generate contextual explanations, determine potential causes, or rank corrective actions. This in combination with newly cited Chait (U.S 2014/0222521 A1) discloses the amended limitations argued above.
Claim Objections
Claims 18-20 are objected to because of the following informalities: Independent claim 18 recites in the limitation beginning “compiling” the term “the context report” which lacks antecedent basis and should recite “the report”. Appropriate correction is required. Dependent claims 19-20 are objected due to their dependency of independent claim 18.
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-20 are rejected under 35 U.S.C. 101 because the claimed invention is directed to non-statutory subject matter;
When considering subject matter eligibility under 35 U.S.C. 101, it must be determined whether the claim is directed to one of the four statutory categories of invention, i.e., process, machine, manufacture, or composition of matter. If the claim does fall within one of the statutory categories, it must then be determined whether the claim is directed to a judicial exception (i.e., law of nature, natural phenomenon, and abstract idea), and if so, it must additionally be determined whether the claim is a patent-eligible application of the exception. If an abstract idea is present in the claim, any element or combination of elements in the claim must be sufficient to ensure that the claim amounts to significantly more than the abstract idea itself.
Claims 1-10
Step 1: Independent claim 1 (system) and dependent claims 2-10, respectively, fall within at least one of the four statutory categories of 35 U.S.C. 101: (i) process; (ii) machine; (iii) manufacture; or (iv) composition of matter. Claim 1 is directed to a system (i.e. machine).
Step 2A Prong 1: The independent claim recites receive from a quality management system (QMS) module, incoming data related to one or more quality assurance business processes and migrate the incoming data to a products database; analyze the incoming data using predefined rules executed by the rules engine, wherein the predefined rules comprise dynamically-generated deviation criteria based on historical quality assurance trends and expected operational timelines derived from products lifecycle data stored in the products database, to determine data meeting flagging criteria for flagging the incoming data as flagged data, wherein the data meeting flagging criteria indicates that additional context is necessary with respect to the flagged data, wherein the incoming data includes a number of quality assurance reports generated within a given period and the flagging criteria includes a threshold number of quality assurance reports generated within the given period such that the incoming data is flagged if a number of reports generated within the given period exceeds the threshold and the dynamically-generated deviation criteria; flagging the incoming data if the incoming data does not satisfy the flagging criteria; and triggering automatically generation of a context report using the flagged data based on the flagging criteria, wherein the context report includes, at least, the flagged data and context data that indicates specific flagging criteria of the flagged data, wherein the context data being generated by the rules engine by correlating the flagged data with a related quality assurance data and products lifecycle data, one or more potential causes of the flagged data determined by applying the predefined rules to the correlated quality assurance data, and at least one recommended corrective action presented and ranked based on the determined potential cause (Certain Method of Organizing Human Activity & Mental Process), which are considered to be abstract ideas (See PEG 2019 and MPEP 2106.05). [Examiner notes the underlined limitations above recite to the abstract idea].
The steps/functions disclosed above and in the independent claims recite the abstract idea of Certain Methods of Organizing Human Activity because the claimed limitations are analyzing quality assurance business processes to generate quality assurance reports, which is a commercial interaction in the form of business relations. The Applicant’s claimed limitations are analyzing quality assurance business processes to generate quality assurance reports, which recite the abstract idea of Certain Methods of Organizing Human Activity.
The steps/functions disclosed above and in the independent claims recite the abstract idea of Mental Process because the claimed limitations are analyzing quality assurance business processes to generate quality assurance reports, which are functions of the human mind in the form of observation, judgement, and evaluation. The Applicant’s claimed limitations are analyzing quality assurance business processes to generate quality assurance reports, which recite the abstract idea of Mental Process.
In addition, dependent claims 2 and 4-10 further narrow the abstract idea and recite further defining the flagged data and context data; the flagging criteria; the given period of analyzing; and the classification of flagged data. These processes are similar to the abstract idea noted in the independent claims because they further the limitations of the independent claims which recite a certain method of organizing human activity which include commercial interactions such as business relations. Accordingly, these claim elements do not serve to confer subject matter eligibility to the claims since they are directed to abstract ideas. Dependent claim 3 will be discussed in Prong 2 analysis below.
Step 2A Prong 2: In this application, the above “receive from a quality management system (QMS) module, incoming data related to one or more quality assurance business processes and migrate the incoming data to a products database” steps/functions of the independent claims would not account for additional elements that integrate the judicial exception (e.g. abstract idea) into a practical application because receiving/storing data and displaying data merely add insignificant extra-solution activity and merely adds the words to apply it with the judicial exception. Also, the claimed “A computing system comprising: a processor configured for executing one or more processes based on machine-readable instructions; and a memory storing one or more machine readable instructions, including a rules engine, that when executed by the processor cause the computing system; a quality management system (QMS) module, a products database; a reports library” would not account for additional elements that integrate the judicial exception (e.g. abstract idea) into a practical application because the claimed structure merely adds the words to apply it with the judicial exception and mere instructions to implement an abstract idea on a computer (See PEG 2019 and MPEP 2106.05).
In addition, dependent claims 2 and 4-10 further narrow the abstract idea and dependent claim 3 additionally recite “wherein the predefined report format is stored” which do not account for additional elements that integrate the judicial exception (e.g. abstract idea) into a practical application because receiving/storing data and displaying data merely add insignificant extra-solution activity and the claimed “a reports library” which do not account for additional elements that integrate the judicial exception (e.g. abstract idea) into a practical application because the claimed structure merely adds the words to apply it with the judicial exception and mere instructions to implement an abstract idea on a computer (See PEG 2019 and MPEP 2106.05).
The claimed “A computing system comprising: a processor configured for executing one or more processes based on machine-readable instructions; and a memory storing one or more machine readable instructions, including a rules engine, that when executed by the processor cause the computing system; a quality management system (QMS) module, a products database; a reports library” are recited so generically (no details whatsoever are provided other than that they are general purpose computing components and regular office supplies) that they represent no more than mere instructions to apply the judicial exception on a computer. These limitations can also be viewed as nothing more than an attempt to generally link the use of the judicial exception to the technological environment of a computer. Even when viewed in combination, the additional elements in the claims do no more than use the computer components as a tool. There is no change to the computers and other technology that is recited in the claim, and thus the claims do not improve computer functionality or other technology (See PEG 2019).
Step 2B: When analyzing the additional element(s) and/or combination of elements in the claim(s) other than the abstract idea per se the claim limitations amount(s) to no more than: a general link of the use of an abstract idea to a particular technological environment and merely amounts to the application or instructions to apply the abstract idea on a computer (See MPEP 2106.05 and PEG 2019). Further, system claims 1-10 recite “A computing system comprising: a processor configured for executing one or more processes based on machine-readable instructions; and a memory storing one or more machine readable instructions, including a rules engine, that when executed by the processor cause the computing system; a quality management system (QMS) module, a products database; a reports library”; however, these elements merely facilitate the claimed functions at a high level of generality and they perform conventional functions and are considered to be general purpose computer components which is supported by Applicant’s specification in Paragraphs 0030-0035 and Figures 1-4. The Applicant’s claimed additional elements are mere instructions to implement the abstract idea on a general purpose computer and generally link of the use of an abstract idea to a particular technological environment. Also, the above “receive from a quality management system (QMS) module, incoming data related to one or more quality assurance business processes and migrate the incoming data to a products database” steps/functions of the independent claims would not account for significantly more than the abstract idea because receiving data and displaying/presenting data (See MPEP 2106.05) have been identified as well-known, routine, and conventional steps/functions to one of ordinary skill in the art. When viewed as a whole, these additional claim element(s) do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself.
In addition, claims 2 and 4-10 further narrow the abstract idea identified in the independent claims. The Examiner notes that the dependent claims merely further define the data being analyzed and how the data is being analyzed. Similarly, claim 3 additionally recites “wherein the predefined report format is stored” which do not account for additional elements that amount to significantly more than the abstract idea because receiving data and displaying/presenting data (See MPEP 2106.05) have been identified as well-known, routine, and conventional steps/functions to one of ordinary skill in the art and the claimed “reports library” which do not account for additional elements that amount to significantly more than the abstract idea because the claimed structure merely amounts to the application or instructions to apply the abstract idea on a computer and does not move beyond a general link of the use of an abstract idea to a particular technological environment (See MPEP 2106.05). The additional limitations of the independent and dependent claim(s) when considered individually and as an ordered combination do not amount to significantly more than the abstract idea. The examiner has considered the dependent claims in a full analysis including the additional limitations individually and in combination as analyzed in the independent claim(s). Therefore, the claim(s) are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claims 11-17
Step 1: Independent claim 11 (method) and dependent claims 12-17, respectively, fall within at least one of the four statutory categories of 35 U.S.C. 101: (i) process; (ii) machine; (iii) manufacture; or (iv) composition of matter. Claim 11 is directed to a method (i.e. process).
Step 2A Prong 1: The independent claim recites receiving descriptive data that describes raw report generation data based on information about the raw report generation data using a computing system, the method comprising: generating, by the computing system, descriptive data related to one or more products or business processes related to patient information, patient treatment, pharmaceutical business processes, or pharmaceutical products, wherein the descriptive data comprises at least tracking data associated with the one or more products; storing, by the computing system, the descriptive data in one or more databases as raw report generation data for the generation of one or more reports related to patient information, patient treatment, pharmaceutical business processes, or pharmaceutical products; migrating, by the computing system, the raw report generation data to a products database for inclusion in a current report related to patient information, patient treatment, pharmaceutical business processes, or pharmaceutical products; generating, by the computing system, one or more flag criteria for flagging raw report generation data, wherein the flag criteria is determined dynamically based on at least historical quality assurance trends and a threshold relating to a number of reports generated within a given time period, such that the raw report generation data is flagged if the number of reports generated within the given period exceeds the threshold and dynamically-generated deviation criteria; flagging, by the computing system, raw report generation data that meets one or more of the flag criteria as flagged report generation data; requesting, by the computing system, descriptive information from the one or more databases based on the flagged report generation data; receiving, by the computing system, descriptive information related to the flagged report generation data, wherein the descriptive information comprises of a products lifecycle logistics information comprising at least shipping time, location dwell time, and refrigeration-compliance information; and generating, by the computing system, a context report based on the flagged report generation data, wherein the context report includes the flagged report generation data and context data that indicates specific flagging criteria of the flagged report generation data, one or more potential causes determined by applying predefined rules to the received descriptive information, and at least one recommended corrective action presented and ranked based on the determined potential cause (Certain Methods of Organizing Human Activity & Mental Process), which are considered to be abstract ideas (See PEG 2019 and MPEP 2106.05). [Examiner notes the underlined limitations above recite the abstract idea].
The steps/functions disclosed above and in the independent claims recite the abstract idea of Certain Methods of Organizing Human Activity because the claimed limitations are generating descriptive data related to one or more products or business processes related to patient information, patient treatment, pharmaceutical business processes, or pharmaceutical products, wherein the descriptive data comprises at least tracking data associated with the one or more products, which is commercial interactions including marketing. The Applicant’s claimed limitations are generating descriptive data related to one or more products or business processes, which recite the abstract idea of Organizing Human Activity.
The steps/functions disclosed above and in the independent claims recite the abstract idea of Mental Process because the claimed limitations are generating descriptive data related to one or more products or business processes related to patient information, patient treatment, pharmaceutical business processes, or pharmaceutical products; generating one or more flag criteria for flagging raw report generation data; flagging raw report generation data that meets one or more of the flag criteria as flagged report generation data; and generating a context report based on the flagged report generation data. The Applicant’s claimed limitations are generating descriptive data; flag criteria; flagging raw report generation data that meets the flag criteria, and generating a context report based on the flagged report generation data, which recite the abstract idea of Mental Process.
In addition, dependent claims 12-17 further narrow the abstract idea and recite further defining the flagging of raw report generation data; the descriptive information; the classification of the flagged report generation data; and user permission levels. These processes are similar to the abstract idea noted in the independent claims because they further the limitations of the independent claims which recite a certain method of organizing human activity which include commercial interactions such as marketing and mental processes. Accordingly, these claim elements do not serve to confer subject matter eligibility to the claims since they recite abstract ideas.
Step 2A Prong 2: In this application, the above “receiving descriptive data that describes raw report generation data based on information about the raw report generation data; storing, by the computing system, the descriptive data in one or more databases as raw report generation data for the generation of one or more reports related to patient information, patient treatment, pharmaceutical business processes, or pharmaceutical products; migrating, by the computing system, the raw report generation data to a products database for inclusion in a current report related to patient information, patient treatment, pharmaceutical business processes, or pharmaceutical products; requesting, by the computing system, descriptive information from the one or more databases based on the flagged report generation data; and receiving, by the computing system, descriptive information related to the flagged report generation data, wherein the descriptive information comprises of a products lifecycle logistics information comprising at least shipping time, location dwell time, and refrigeration-compliance information” steps/functions of the independent claims would not account for additional elements that integrate the judicial exception (e.g. abstract idea) into a practical application because receiving/storing data and displaying data merely add insignificant extra-solution activity and merely adds the words to apply it with the judicial exception. Also, the claimed “a computing system, one or more databases; a products database” would not account for additional elements that integrate the judicial exception (e.g. abstract idea) into a practical application because the claimed structure merely adds the words to apply it with the judicial exception and mere instructions to implement an abstract idea on a computer (See PEG 2019 and MPEP 2106.05).
In addition, dependent claims 12-17 further narrow the abstract idea and dependent claims 13, 16, and 17 additionally recite “the descriptive information is requested”; “the user can only access the compiled report”; and “the user can only distribute the compiled report” which do not account for additional elements that integrate the judicial exception (e.g. abstract idea) into a practical application because receiving/storing data and displaying data merely add insignificant extra-solution activity and the claimed “one or more databases” which do not account for additional elements that integrate the judicial exception (e.g. abstract idea) into a practical application because the claimed structure merely adds the words to apply it with the judicial exception and mere instructions to implement an abstract idea on a computer (See PEG 2019 and MPEP 2106.05).
The claimed “a computing system, one or more databases; a products database” are recited so generically (no details whatsoever are provided other than that they are general purpose computing components and regular office supplies) that they represent no more than mere instructions to apply the judicial exception on a computer. These limitations can also be viewed as nothing more than an attempt to generally link the use of the judicial exception to the technological environment of a computer. Even when viewed in combination, the additional elements in the claims do no more than use the computer components as a tool. There is no change to the computers and other technology that is recited in the claim, and thus the claims do not improve computer functionality or other technology (See PEG 2019).
Step 2B: When analyzing the additional element(s) and/or combination of elements in the claim(s) other than the abstract idea per se the claim limitations amount(s) to no more than: a general link of the use of an abstract idea to a particular technological environment and merely amounts to the application or instructions to apply the abstract idea on a computer (See MPEP 2106.05 and PEG 2019). Further, method claims 11-17 recite “a computing system, one or more databases; a products database”; however, these elements merely facilitate the claimed functions at a high level of generality and they perform conventional functions and are considered to be general purpose computer components which is supported by Applicant’s specification in Paragraphs 0030-0035 and Figures 1-4. The Applicant’s claimed additional elements are mere instructions to implement the abstract idea on a general purpose computer and generally link of the use of an abstract idea to a particular technological environment. Also, the above “receiving descriptive data that describes raw report generation data based on information about the raw report generation data; storing, by the computing system, the descriptive data in one or more databases as raw report generation data for the generation of one or more reports related to patient information, patient treatment, pharmaceutical business processes, or pharmaceutical products; migrating, by the computing system, the raw report generation data to a products database for inclusion in a current report related to patient information, patient treatment, pharmaceutical business processes, or pharmaceutical products; requesting, by the computing system, descriptive information from the one or more databases based on the flagged report generation data; and receiving, by the computing system, descriptive information related to the flagged report generation data, wherein the descriptive information comprises of a products lifecycle logistics information comprising at least shipping time, location dwell time, and refrigeration-compliance information” steps/functions of the independent claims would not account for significantly more than the abstract idea because receiving data and displaying/presenting data (See MPEP 2106.05) have been identified as well-known, routine, and conventional steps/functions to one of ordinary skill in the art. When viewed as a whole, these additional claim element(s) do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself.
In addition, claims 12-17 further narrow the abstract idea identified in the independent claims. The Examiner notes that the dependent claims merely further define the data being analyzed and how the data is being analyzed. Similarly, claims 13, 16, and 17 additionally recite “the descriptive information is requested”; “the user can only access the compiled report”; and “the user can only distribute the compiled report” which do not account for additional elements that amount to significantly more than the abstract idea because receiving data and displaying/presenting data (See MPEP 2106.05) have been identified as well-known, routine, and conventional steps/functions to one of ordinary skill in the art and the claimed “one or more databases” which do not account for additional elements that amount to significantly more than the abstract idea because the claimed structure merely amounts to the application or instructions to apply the abstract idea on a computer and does not move beyond a general link of the use of an abstract idea to a particular technological environment (See MPEP 2106.05). The additional limitations of the independent and dependent claim(s) when considered individually and as an ordered combination do not amount to significantly more than the abstract idea. The examiner has considered the dependent claims in a full analysis including the additional limitations individually and in combination as analyzed in the independent claim(s). Therefore, the claim(s) are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claims 18-20
Step 1: Independent claim 18 (method) and dependent claims 19-20, respectively, fall within at least one of the four statutory categories of 35 U.S.C. 101: (i) process; (ii) machine; (iii) manufacture; or (iv) composition of matter. Claim 18 is directed to a method (i.e. process).
Step 2A Prong 1: The independent claim recites automatically generating one or more business intelligence reports using a computing system, the method comprising: migrating, using the computing system, raw report generation data from one or more databases storing descriptive data to a products database for inclusion in a current report related to patient information, patient treatment, pharmaceutical business processes, or pharmaceutical products, wherein the descriptive data comprising at least tracking data associated with the one or more products; generating, using the computing system, one or more flag criteria for flagging raw report generation data, wherein the flag criteria is determined dynamically based on at least historical quality assurance trends and a threshold relating to a number of reports generated within a given time period, such that the raw report generation data is flagged if the number of reports generated within the given period exceeds the threshold and the dynamically-generated deviation criteria; flagging, using the computing system, raw report generation data that meets one or more of the flag criteria as flagged report generation data; requesting, using the computing system, descriptive information from the one or more databases based on the flagged report generation data; receiving, using the computing system, descriptive information related to the flagged report generation data, wherein the descriptive information comprises of a products lifecycle logistics information comprising at least shipping time, location dwell time, and refrigeration-compliance information; and compiling, using the computing system, the received descriptive information related to the flagged report generation data into a report for presentation to a user in a form of a prescriptive report, wherein the context report includes the flagged report generation data, and context data that indicates specific flagging criteria of the flagged report generation data, one or more potential causes determined by applying predefined rules to the received descriptive information, and at least one recommended corrective action presented and ranked based on the determined potential cause (Certain Method of Organizing Human Activity & Mental Process), which are considered to be abstract ideas (See PEG 2019 and MPEP 2106.05). [Examiner notes the underlined limitations above are directed to the abstract idea].
The steps/functions disclosed above and in the independent claims recite the abstract idea of Certain Methods of Organizing Human Activity because the claimed limitations are generating business intelligence reports using tracked product data, which is a commercial interaction in the form of business relations. The Applicant’s claimed limitations are generating business intelligence reports, which recite the abstract idea of Certain Methods of Organizing Human Activity.
The steps/functions disclosed above and in the independent claims recite the abstract idea of Mental Process because the claimed limitations are generating business intelligence reports by generating one or more flag criteria for flagging raw report generation data determined based on historical quality assurance trends and a threshold relating to a number of reports generated within a given time period; flagging raw report generation data that meets one or more of the flag criteria as flagged report generation data; and compiling the received descriptive information related to the flagged report generation data into a report for presentation to a user in a form of a prescriptive report, which functions of the human mind including observation, judgement, and evaluation. Additionally, the generation of reports could be performed utilizing pen & paper. The Applicant’s claimed limitations are generating business intelligence reports, which recite the abstract idea of Mental Process.
In addition, dependent claims 19-20 further narrow the abstract idea recite further defining the flagging of raw report generating data and compiling of received descriptive information. These processes are similar to the abstract idea noted in the independent claims because they further the limitations of the independent claims which recite a certain method of organizing human activity which include commercial interactions such as business relations as well as mental processes. Accordingly, these claim elements do not serve to confer subject matter eligibility to the claims since they recite abstract ideas.
Step 2A Prong 2: In this application, the above “migrating, using the computing system, raw report generation data from one or more databases storing descriptive data to a products database for inclusion in a current report related to patient information, patient treatment, pharmaceutical business processes, or pharmaceutical products; requesting, using the computing system, descriptive information from the one or more databases based on the flagged report generation data; receiving, using the computing system, descriptive information related to the flagged report generation data, wherein the descriptive information comprises of a products lifecycle logistics information comprising at least shipping time, location dwell time, and refrigeration-compliance information” steps/functions of the independent claims would not account for additional elements that integrate the judicial exception (e.g. abstract idea) into a practical application because receiving/storing data and displaying data merely add insignificant extra-solution activity and merely adds the words to apply it with the judicial exception. Also, the claimed “a computing system, one or more databases; a products database” would not account for additional elements that integrate the judicial exception (e.g. abstract idea) into a practical application because the claimed structure merely adds the words to apply it with the judicial exception and mere instructions to implement an abstract idea on a computer (See PEG 2019 and MPEP 2106.05). In addition, dependent claims 19-20 further narrow the abstract idea.
The claimed “a computing system, one or more databases; a products database” are recited so generically (no details whatsoever are provided other than that they are general purpose computing components and regular office supplies) that they represent no more than mere instructions to apply the judicial exception on a computer. These limitations can also be viewed as nothing more than an attempt to generally link the use of the judicial exception to the technological environment of a computer. Even when viewed in combination, the additional elements in the claims do no more than use the computer components as a tool. There is no change to the computers and other technology that is recited in the claim, and thus the claims do not improve computer functionality or other technology (See PEG 2019).
Step 2B: When analyzing the additional element(s) and/or combination of elements in the claim(s) other than the abstract idea per se the claim limitations amount(s) to no more than: a general link of the use of an abstract idea to a particular technological environment and merely amounts to the application or instructions to apply the abstract idea on a computer (See MPEP 2106.05 and PEG 2019). Further, method claims 18-20 recite “a computing system, one or more databases; a products database”; however, these elements merely facilitate the claimed functions at a high level of generality and they perform conventional functions and are considered to be general purpose computer components which is supported by Applicant’s specification in Paragraphs 0030-0035 and Figures 1-4. The Applicant’s claimed additional elements are mere instructions to implement the abstract idea on a general purpose computer and generally link of the use of an abstract idea to a particular technological environment. Also, the above “migrating, using the computing system, raw report generation data from one or more databases storing descriptive data to a products database for inclusion in a current report related to patient information, patient treatment, pharmaceutical business processes, or pharmaceutical products; requesting, using the computing system, descriptive information from the one or more databases based on the flagged report generation data; receiving, using the computing system, descriptive information related to the flagged report generation data, wherein the descriptive information comprises of a products lifecycle logistics information comprising at least shipping time, location dwell time, and refrigeration-compliance information” steps/functions of the independent claims would not account for significantly more than the abstract idea because receiving data and displaying/presenting data (See MPEP 2106.05) have been identified as well-known, routine, and conventional steps/functions to one of ordinary skill in the art. When viewed as a whole, these additional claim element(s) do not provide meaningful limitation(s) to transform the abstract idea into a patent eligible application of the abstract idea such that the claim(s) amounts to significantly more than the abstract idea itself.
In addition, claims 19-20 further narrow the abstract idea identified in the independent claims. The Examiner notes that the dependent claims merely further define the data being analyzed and how the data is being analyzed. The additional limitations of the independent and dependent claim(s) when considered individually and as an ordered combination do not amount to significantly more than the abstract idea. The examiner has considered the dependent claims in a full analysis including the additional limitations individually and in combination as analyzed in the independent claim(s). Therefore, the claim(s) are rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
This application currently names joint inventors. In considering patentability of the claims the examiner presumes that the subject matter of the various claims was commonly owned as of the effective filing date of the claimed invention(s) absent any evidence to the contrary. Applicant is advised of the obligation under 37 CFR 1.56 to point out the inventor and effective filing dates of each claim that was not commonly owned as of the effective filing date of the later invention in order for the examiner to consider the applicability of 35 U.S.C. 102(b)(2)(C) for any potential 35 U.S.C. 102(a)(2) prior art against the later invention.
Claim(s) 1-3, 6-8, 11-18, and 20 is/are rejected under 35 U.S.C. 103 as being unpatentable over Selker (U.S 2011/0184759 A1) in view of Franco (U.S 8,024,330 B1) in view of Vemireddy (U.S 2013/0179178 A1) in view of Chait (U.S 2014/0222521 A1).
Claim 1
Regarding Claim 1, Selker discloses the following:
A computing system comprising [see at least Paragraph 0030 for reference to a quality improvement (QI) review system for automatically evaluating the quality of the care that is provided by the EMS teams responding to medical emergencies; Figure 17 and related text regarding the computer system on which the QI Review Software can be run]
a processor configured for executing one or more processes based on machine-readable instructions [see at least Paragraph 0091 for reference to the system containing interconnected processors; Figure 17 and related text regarding item 200 ‘processors’]
a memory storing one or more machine readable instructions, including a rules engine, that when executed by the processor cause the computing system to [see at least Paragraph 0091 for reference to the computer system are stored on physical computer readable storage medium, e.g., disks, a flash drive, and/ or physical memory (e.g. RAM)]
receive from a quality management system (QMS) module, incoming data related to one or more quality assurance business processes and migrate the incoming data to a products database [see at least Paragraph 0037 for reference to the patient care record along with other records that were generated by that EMS team in that period, are electronically transferred to the computer system of a third party quality assessment agency; Paragraph 0038 for reference to the patient care record along with other records that were generated by that EMS team in that period, are electronically transferred to the computer system of a third party quality assessment agency; Paragraph 0091 for reference to one or more digital data storage devices for storing data such as the patient care record information that is downloaded from the EMS services]
analyze the incoming data using predefined rules executed by the rules engine, wherein the predefined rules comprises dynamically-generated deviation criteria to determine data meeting flagging criteria for flagging the incoming data as flagged data, wherein the data meeting flagging criteria indicates that additional context is necessary with respect to the flagged data [see at least Paragraph 0031 for reference to QI review system automatically identifies run reports for which there is evidence that the paramedics appear to have failed to meet the applicable standards and it flags those run reports; Paragraph 0039 for reference to after a batch of records have been received, the QI review service then processes the received records with its computer system programmed with QI Review software; Paragraph 0039 for reference to analyzing each of the received patient care records to determine whether the paramedics met the applicable standard of care; Paragraph 0039 for reference to QI Review computer system has access to a matrix of clinical review criteria for a large range of different clinical conditions of the type that the paramedics are likely to treat when performing their job functions, and based on the information that was entered into the electronic patient care record by the paramedics, the software determines which set of clinical review criteria are to be applied to that incident or run report; Paragraph 0040 for reference to the QI review computer system also identifies those records for which the paramedics failed to meet all of the review criteria for the particular medical condition; Paragraph 0052 for reference to based on the information that the paramedic enters into the EMS system and which is relevant to the top four fields, the Quality Review software selects the particular set of review criteria that are to be applied to the review; Paragraph 0084 for reference to a report aggregating performance data for all patients that were treated by the EMS service within a selected period of time for a selected review type; Figure 2 and related text regarding the clinical review criteria matrix]
flagging the incoming data if the incoming data does not satisfy the flagging criteria [see at least Paragraph 0031 for reference to QI review system automatically identifies run reports for which there is evidence that the paramedics appear to have failed to meet the applicable standards and it flags those run reports; Paragraph 0039 for reference to after a batch of records have been received, the QI review service then processes the received records with its computer system programmed with QI Review software; Paragraph 0039 for reference to analyzing each of the received patient care records to determine whether the paramedics met the applicable standard of care; Paragraph 0040 for reference to the QI review computer system also identifies those records for which the paramedics failed to meet all of the review criteria for the particular medical condition]
triggering automatically generation of a context report using the flagged data based on the flagging criteria, wherein the context report includes, at least, the flagged data and context data that indicates specific flagging criteria of the flagged data, wherein the context data being generated by the rules engine by correlating the flagged data with a related quality assurance data [see at least Paragraph 0033 for reference to the QI review system also includes a reporting engine that enables the EMS (or a third party providing the QI review analysis) to generate various reports on the performance of the company, the performance of individual para medics, trends in performance, and comparisons with other EMS services in the area; Paragraph 0033 for reference to the system can generate reports that summarize the care given to the number of patients handled by the EMS service, it can examine and report on the performance of individual paramedics; and it can aggregate data and look at performance of the EMS service in various categories e.g. for different medical conditions; Paragraph 0047 for reference to software running of the QI Review computer system also implements a reporting package that enables the QI Review Service and/or other persons to access the system to generate various reports about the performance of the EMS; Figure 2 and related text regarding item 34 ‘Reporting’]
While Selker discloses the limitations above, it does not disclose the wherein the predefined rules comprises dynamically-generated deviation criteria based on historical quality assurance trends and expected operational timeframes derived from products lifecycle data stored in the products database; flagging criteria includes a threshold number of quality assurance reports generated within the given period such that the incoming data is flagged if the number of reports generated within the given period exceeds the threshold and the dynamically-generated deviation criteria; wherein the context data being generated by the rules engine by correlating the flagged data with a products lifecycle data; wherein the context report includes one or more potential causes of the flagged data determined by applying the predefined rules to the correlated quality assurance data, and at least one recommended corrective action presented and ranked based on the determined potential cause.
However, Franco discloses the following:
the flagging criteria includes a threshold number of quality assurance reports generated within the given period such that the incoming data is flagged if the number of reports generated within the given period exceeds the threshold and the dynamically-generated deviation criteria [see at least Col 2 lines 35-37 for reference to the analysis including a comparison of the number of reports produced by the query to a threshold number of reports required in order to alert the user; Col 5 lines 5-11 for reference to the user’s zone of interest for the determined score including a time range; Col 9 lines 45-61 for reference to the score computation representing the overall number of reports; Col 10 lines 7-10 for reference to the computed score is analyzed to determine if it exceeds a threshold and if it does then and incident alert is reported; Figure 4 and related text regarding item 406 ‘For each group, compute a score based on the reports (and associated contextual information) in the group (and optionally any prior user inquiries’ and item 408 ‘Incident alert is reported to the inquiring user’]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the flagging criteria of Selker to include the number of reports generated within a given time period of Franco. Doing so enables a plurality of users to participate in a collaborative process whereby they can report, be alerted of, and respond to or avoid incidents such as emergencies or hazards, as stated by Franco (Col 1 lines 46-49).
While the combination of Selker and Franco disclose the limitations above, they do not disclose wherein the predefined rules comprises dynamically-generated deviation criteria based on historical quality assurance trends and expected operational timeframes derived from products lifecycle data stored in the products database; the flagging criteria includes the dynamically-generated deviation criteria; wherein the context data being generated by the rules engine by correlating the flagged data with a products lifecycle data; wherein the context report includes one or more potential causes of the flagged data determined by applying the predefined rules to the correlated quality assurance data, and at least one recommended corrective action presented and ranked based on the determined potential cause.
However, Vemireddy discloses the following:
wherein the predefined rules comprises dynamically-generated deviation criteria based on historical quality assurance trends [see at least Paragraph 0062 for reference to the rule processing session receiving the patients clinical history and inheriting rules for processing of incoming real-time data; Paragraph 0081 for reference to based on a history of a heart attack and the patient’s drug regimen compliance information (e.g., as entered by a health care provider), the rules engine module presents relevant drug-related educational materials relating to the importance of taking medications for heart attacks; Paragraph 0084 for reference to the rules engine module processes the newly-received data point in light of the previously stored health profile (e.g., prior health indicator readings, patient’s chronic conditions, age, and sex) and the best evidence-based medical standards of care to generate in real-time a normal or target range, as well as a high risk indicator, which provide context for the updated readings]
the flagging criteria includes the dynamically-generated deviation criteria [see at least Paragraph 0057 for reference to the clinical alert associated with the current tracker value being represented as a normal range and high risk indicators to provide the patient with a health risk assessment trend; Paragraph 0084 for reference to the rules engine module processes the newly-received data point in light of the previously stored health profile (e.g., prior health indicator readings, patient’s chronic conditions, age, and sex) and the best evidence-based medical standards of care to generate in real-time a normal or target range, as well as a high risk indicators which provide context for the updated readings; Examiner notes the determined ‘ranges’ as analogous to the ‘predefined deviation criteria’]
wherein the context report includes, at least, the flagged data and the context data that indicates specific flagging criteria of the flagged data, wherein the context data being generated by the rules engine by correlating the flagged data with a related quality assurance data, one or more potential causes of the flagged data determined by applying the predefined rules to the correlated quality assurance data, and at least one recommended corrective action presented and ranked based on the determined potential cause [see at least Paragraph 0015 for reference to the alert justification information specifies which clinical rules have been triggered/processed by the incoming data (e.g., by rule number), which alerts have been generated (e.g., by alert number), a time/date stamp for each alert, the specific exclusionary and inclusionary information for a given patient that caused the rule to trigger (e.g., known drug allergies are used to exclude alerts recommending a drug regimen that may cause an allergic reaction), as well as patient-entered and claim information associated; Paragraph 0047 for reference to the PHR allowing the patients to create printable reports containing the patients health information, including health summaries and health risk assessment reports; Paragraph 0057 for reference to the rules engine module evaluates the patient-reported and claims based health tracker data along with other clinical data available in the medical database to determine the patient specific goal for a given tracker metric and evaluate the current tracker value against that goal to trigger a clinical alert; Paragraph 0074 for reference to the alert payload filtering module consolidates outgoing alerts into recommendation families (e.g., alerts relating to potential drug interactions, medical text recommendations); Paragraph 0075 for reference to the alert payload filtering module customizing the alert text including alert justification information to the designated delivery party and the specifics of the patients health care plan; Paragraph 0084 for reference to the rules engine module provides the patient and the health care provider with real-time health trend ranges and corresponding clinical recommendations when the patient and/or the health care provider enters new health indicator data into the PHR-based health tracking tool or disease management application; Figure 16 and related text regarding the health tracking tool to allow the patient to trend one or more health indicators; Figure 17 and related text regarding an Alert Status Report indicating the alert completion and outcome status for the overall patient population]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the flagging criteria and reporting of Selker to include the deviation criteria and report display of Vemireddy. Doing so would provide a computer-based solution which is capable of clinically analyzing, in real-time, the accumulated health care information in light of appropriate medical standards and directly notifying the patient and the healthcare provider to ensure a prompt follow up on the results of the analysis, as stated by Vemireddy (Paragraph 0003).
While the combination of Selker, Franco, and Vemireddy disclose the limitations above, they do not disclose wherein the predefined rules comprises dynamically-generated deviation criteria based on expected operational timeframes derived from products lifecycle data stored in the products database; wherein the context data being generated by the rules engine by correlating the flagged data with a products lifecycle data.
However, Chait discloses the following:
wherein the predefined rules comprises dynamically-generated deviation criteria based on expected operational timeframes derived from products lifecycle data stored in the products database [see at least Paragraph 0033 for reference to the standards may comprise rules and/or instructions provided by a suitable entity, such as a governmental agency, an industry group, and/or a specific company; Paragraph 0045 for reference to servers may implement a rules engine, that correlates and analyzes the collected data based on instructions and/or standards; Paragraph 0048 for reference to the standards may comprise three different types of information: regulatory rules, representing governmental regulations, such as 21 C.F.R. that regulates rodent indexing in livestock farms; industry standards, representing instructions or standards established by trade groups or industry organizations; and company specifications, representing company-specific specifications or rules regarding operation and task within the company; Paragraph 0095 for reference to a biological and environmental database that stores data collected from one or more biological and/or environmental sensors, representing information related to various organisms and/or environments; Paragraph 0097 for reference to a logistical database that stores logistical data, which may represent information related to the logistical operations of the work environment, such as distribution and supply chain logistics; Paragraph 0098 for reference to a rules/instructions database, which may store data related to various standards, such as regulations, rules, and/or specifications applicable to the distributed work environment; Figure 3 and related text regarding item 326 ‘rules database’]
wherein the context data being generated by the rules engine by correlating the flagged data with a products lifecycle data [see at least Paragraph 0045 for reference to servers may implement a rules engine, that correlates and analyzes the collected data based on instructions and/or standards; Paragraph 0069 for reference to the rules engine, different types of collected data may be analyzed and correlated with a set of standards to determine non-compliance and/or potential non-compliance, and to implement actions to resolve the non-compliance Paragraph 0122 for reference to the rules engine may determine, based on the results of the analysis, which collected data are most useful in determining non-compliance at one or more critical control points, or at any other part of the workflow chain]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the flagging criteria and reporting of Selker to include the product lifecycle consideration of Chait. Doing so enables improved usage of resource constrained sensors, and/or may streamline the processing by the rules engine by correlating only the data that is most useful, as stated by Chait (Paragraph 0122).
Claim 2
While the combination of Selker, Franco, Vemireddy, and Chait disclose the limitations above, regarding Claim 2, Selker discloses the following:
wherein the flagged data and the context data are provided to a user in a predefined report format [see at least Paragraphs 0081-0087 for reference to the various types of reports that can be created; Paragraph 0088 for reference to a report wizard interface for generating such reports from the collected data is provided by the QI Review software; Paragraph 0088 for reference to a menu driven interface that enables authorized users to select what report is to be generated; Figure 15A-15E and related text regarding the report wizard interface]
Claim 3
While the combination of Selker, Franco, Vemireddy, and Chait disclose the limitations above, regarding Claim 3, Selker discloses the following:
wherein the predefined report format is stored in a reports library [see at least Paragraph 0088 for reference to the report wizard enables the user to select the group from which the report is to be generated; Figure 15A and related text regarding the report wizard screens]
Claim 6
While the combination of Selker, Franco, Vemireddy, and Chait disclose the limitations above, regarding Claim 6, Selker discloses the following:
wherein the given period is one year or less [see at least Paragraph 0059 for reference to user can also select the time period for which the Summary review is desired (e.g. last 4 months); Paragraph 0084 for reference to a report aggregating performance data for all patients that were treated by the EMS service within a selected period of time for a selected review type; Paragraph 0088 for reference to the software invites the user to select the period of time which the report will cover (e.g. the last 12 months)]
Claim 7
While the combination of Selker, Franco, Vemireddy, and Chait disclose the limitations above, regarding Claim 7, Selker discloses the following:
wherein the flagged data is classified based on one or more sectors of a business to which the flagged data relates and the context data that is received is based on a classification of the flagged data [see at least Paragraph 0049 for reference to the QI review system is the matrix of clinical review criteria for the possible review types that might be handled by the EMS; Paragraph 0050 for reference to the four fields of review including (1) review type; (2) clinical impression; (3) chief complaint (symptoms); and (4) transport priority (critical or not critical); Paragraph 0054 for reference to the range of review types is determined by the EMS service that wants its performance reviewed; Figure 2 and related text regarding the clinical review criteria matrix]
Claim 8
While the combination of Selker, Franco, Vemireddy, and Chait disclose the limitations above, regarding Claim 8, Selker discloses the following:
wherein the classification of the flagged data is related to one or more of risk assessments, quality measurements, employee training, compliance management, complaints, corrective action/preventive action (CAPA), change controls, response times, and effectiveness [see at least Paragraph 0049 for reference to the QI review system is the matrix of clinical review criteria for the possible review types that might be handled by the EMS; Paragraph 0050 for reference to the four fields of review including (1) review type; (2) clinical impression; (3) chief complaint (symptoms); and (4) transport priority (critical or not critical); Paragraph 0054 for reference to the range of review types is determined by the EMS service that wants its performance reviewed; Paragraph 0081-0087 which describe the different types of reports generated including trend reports of quality of care; Figure 2 and related text regarding the clinical review criteria matrix]
Claim 11
Regarding Claim 11, Selker discloses the following:
A method of receiving descriptive data that describes raw report generation data based on information about the raw report generation data using a computing system, the method comprising [see at least Paragraph 0008 for reference to the invention features a computer-implemented clinical quality review method; Paragraph 0009 for reference to the computer-implemented method may also include electronically forwarding information about the manually reviewed records to the reporting system; Paragraph 0039 for reference to based on the information that was entered into the electronic patient care record by the paramedics, the software determines which set of clinical review criteria are to be applied to that incident or run report]
generating, by the computing system, descriptive data related to one or more products or business processes related to patient information, patient treatment, pharmaceutical business processes, or pharmaceutical products [see at least Paragraph 0037 for reference to paramedics enter data into that system to generate a record for the patient; Paragraph 0037 for reference to data entered including identifying information about the patient, measured Vital signs, symptoms, clinical impressions, and many details about the clinical review that was conducted and the treatment that was applied and operational information, such as details about the transport of the patient to the hospital]
storing, by the computing system, the descriptive data in one or more databases as raw report generation data for the generation of one or more reports related to patient information, patient treatment, pharmaceutical business processes, or pharmaceutical products [see at least Paragraph 0091 for reference to one or more digital data storage devices for storing data such as the patient care record information that is downloaded from the EMS services; Figure 17 and related text regarding item 210 ‘digital storage devices’]
migrating, by the computing system, the raw report generation data to a products database for inclusion in a current report related to patient information, patient treatment, pharmaceutical business processes, or pharmaceutical products [see at least Paragraph 0038 for reference to the patient care record along with other records that were generated by that EMS team in that period, are electronically transferred to the computer system of a third party quality assessment agency]
generating, by the computing system, one or more flag criteria for flagging raw report generation data [see at least Paragraph 0049 for reference to the QI review system is the matrix of clinical review criteria for the possible review types that might be handled by the EMS; Paragraph 0050 for reference to the four fields of review including (1) review type; (2) clinical impression; (3) chief complaint (symptoms); and (4) transport priority (critical or not critical); Figure 2 and related text regarding the clinical review criteria matrix]
flagging, by the computing system, raw report generation data that meets one or more of the flag criteria as flagged report generation data [see at least Paragraph 0031 for reference to QI review system automatically identifies run reports for which there is evidence that the paramedics appear to have failed to meet the applicable standards and it flags those run reports; Paragraph 0039 for reference to after a batch of records have been received, the QI review service then processes the received records with its computer system programmed with QI Review software; Paragraph 0039 for reference to analyzing each of the received patient care records to determine whether the paramedics met the applicable standard of care; Paragraph 0040 for reference to the QI review computer system also identifies those records for which the paramedics failed to meet all of the review criteria for the particular medical condition]
requesting, by the computing system, descriptive information from the one or more databases based on the flagged report generation data [see at least Paragraph 0041 for reference to the QI review computer system also provides a graphical user interface to authorized people on the EMS staff to access the particular identified records that have been flagged as failing to meet the relevant review criteria and to review those run reports]
receiving, by the computing system, descriptive information related to the flagged report generation data [see at least Paragraph 0041 for reference to this enables the administration and designated reviewers to access basic data and supporting documentation including the locked down electronic patient care record that was provided by the paramedics as a result of the run]
generating, by the computing system, a context report based on the flagged report generation data, wherein the context report includes the flagged report generation data and context data that indicates specific flagging criteria of the flagged report generation data [see at least Paragraph 0033 for reference to the QI review system also includes a reporting engine that enables the EMS (or a third party providing the QI review analysis) to generate various reports on the performance of the company, the performance of individual para medics, trends in performance, and comparisons with other EMS services in the area; Paragraph 0033 for reference to the system can generate reports that summarize the care given to the number of patients handled by the EMS service, it can examine and report on the performance of individual paramedics; and it can aggregate data and look at performance of the EMS service in various categories e.g. for different medical conditions; Paragraph 0047 for reference to software running of the QI Review computer system also implements a reporting package that enables the QI Review Service and/or other persons to access the system to generate various reports about the performance of the EMS; Figure 2 and related text regarding item 34 ‘Reporting’]
While Selker discloses the limitations above, it does not disclose wherein the descriptive data comprises at least tracking data associated with the one or more products; wherein the flag criteria is determined dynamically based on at least historical quality assurance trends and a threshold relating to a number of reports generated within a given time period, such that the raw report generation data is flagged if the number of reports generated within the given period exceeds the threshold and dynamically-generated deviation criteria; wherein the descriptive information comprises of a products lifecycle logistics information comprising at least shipping time, location dwell time, and refrigeration-compliance information; generating, by the computing system, a context report based on the flagged report generation data, wherein the context report one or more potential causes determined by applying predefined rules to the received descriptive information, and at least one recommended corrective action presented and ranked based on the determined potential cause.
However, Franco discloses the following:
wherein the flag criteria is determined dynamically based on a threshold relating to a number of reports generated within a given period, such that the raw report generation data is flagged if the number of reports generated within the given period exceeds the threshold and dynamically-generated deviation criteria [see at least Col 2 lines 35-37 for reference to the analysis including a comparison of the number of reports produced by the query to a threshold number of reports required in order to alert the user; Col 5 lines 5-11 for reference to the user’s zone of interest for the determined score including a time range; Col 9 lines 45-61 for reference to the score computation representing the overall number of reports; Col 10 lines 7-10 for reference to the computed score is analyzed to determine if it exceeds a threshold and if it does then and incident alert is reported; Figure 4 and related text regarding item 406 ‘For each group, compute a score based on the reports (and associated contextual information) in the group (and optionally any prior user inquiries’ and item 408 ‘Incident alert is reported to the inquiring user’]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the flagging criteria of Selker to include the number of reports generated within a given time period of Franco. Doing so enables a plurality of users to participate in a collaborative process whereby they can report, be alerted of, and respond to or avoid incidents such as emergencies or hazards, as stated by Franco (Col 1 lines 46-49).
While the combination of Selker and Franco disclose the limitations above, they do not disclose wherein the descriptive data comprises at least tracking data associated with the one or more products; wherein the descriptive information comprises of a products lifecycle logistics information comprising at least shipping time, location dwell time, and refrigeration-compliance information; generating, by the computing system, a context report based on the flagged report generation data, wherein the context report one or more potential causes determined by applying predefined rules to the received descriptive information, and at least one recommended corrective action presented and ranked based on the determined potential cause.
However, Vemireddy discloses the following:
wherein the descriptive data comprises at least tracking data associated with the one or more products [see at least Paragraph 0042 for reference to clinical data including drug prescription information; Paragraph 0044 for reference to the patient entered data including use of non-prescription drugs; Paragraph 0045 for reference to the rules engine module applies the clinical rules specific to the patient’s medical data file, including checking for known drug interactions, to compare the patient’s actual care with the best evidence-based medical standard of care]
wherein the flag criteria is determined dynamically based on at least historical quality assurance trends [see at least Paragraph 0062 for reference to the rule processing session receiving the patients clinical history and inheriting rules for processing of incoming real-time data; Paragraph 0081 for reference to based on a history of a heart attack and the patient’s drug regimen compliance information (e.g., as entered by a health care provider), the rules engine module presents relevant drug-related educational materials relating to the importance of taking medications for heart attacks; Paragraph 0084 for reference to the rules engine module processes the newly-received data point in light of the previously stored health profile (e.g., prior health indicator readings, patient’s chronic conditions, age, and sex) and the best evidence-based medical standards of care to generate in real-time a normal or target range, as well as a high risk indicator, which provide context for the updated readings]
generating, by the computing system, a context report based on the flagged report generation data, wherein the context report one or more potential causes determined by applying predefined rules to the received descriptive information, and at least one recommended corrective action presented and ranked based on the determined potential cause [see at least Paragraph 0015 for reference to the alert justification information specifies which clinical rules have been triggered/processed by the incoming data (e.g., by rule number), which alerts have been generated (e.g., by alert number), a time/date stamp for each alert, the specific exclusionary and inclusionary information for a given patient that caused the rule to trigger (e.g., known drug allergies are used to exclude alerts recommending a drug regimen that may cause an allergic reaction), as well as patient-entered and claim information associated; Paragraph 0047 for reference to the PHR allowing the patients to create printable reports containing the patients health information, including health summaries and health risk assessment reports; Paragraph 0057 for reference to the rules engine module evaluates the patient-reported and claims based health tracker data along with other clinical data available in the medical database to determine the patient specific goal for a given tracker metric and evaluate the current tracker value against that goal to trigger a clinical alert; Paragraph 0074 for reference to the alert payload filtering module consolidates outgoing alerts into recommendation families (e.g., alerts relating to potential drug interactions, medical text recommendations); Paragraph 0075 for reference to the alert payload filtering module customizing the alert text including alert justification information to the designated delivery party and the specifics of the patients health care plan; Paragraph 0084 for reference to the rules engine module provides the patient and the health care provider with real-time health trend ranges and corresponding clinical recommendations when the patient and/or the health care provider enters new health indicator data into the PHR-based health tracking tool or disease management application; Figure 16 and related text regarding the health tracking tool to allow the patient to trend one or more health indicators; Figure 17 and related text regarding an Alert Status Report indicating the alert completion and outcome status for the overall patient population]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the flagging criteria and descriptive data of Selker to include the product data and flagging criteria of Vemireddy. Doing so would provide a computer-based solution which is capable of clinically analyzing, in real-time, the accumulated health care information in light of appropriate medical standards and directly notifying the patient and the healthcare provider to ensure a prompt follow up on the results of the analysis, as stated by Vemireddy (Paragraph 0003).
While the combination of Selker, Franco, and Vemireddy disclose the limitations above, they do not disclose wherein the descriptive information comprises of a products lifecycle logistics information comprising at least shipping time, location dwell time, and refrigeration-compliance information.
However, Chait discloses the following:
wherein the descriptive information comprises of a products lifecycle logistics information comprising at least shipping time, location dwell time, and refrigeration-compliance information [see at least Paragraph 0077 for reference to critical points may be designated at outdoor loading docks, which may have prescribed time limits for unloading and loading the eggs, or may be designated at a holding facility, which may have requirements on refrigerating eggs at a certain temperature based on the age of the eggs, or may be designated at a transportation entity that may be required to maintain a prescribed temperature during transportation, and comply with maximum loading and unloading times during transfer of the eggs; Paragraph 0093 for reference to the data store may comprise: behavioral data, operational data, biological and environmental data, machine data, logistical data, regulatory rules, industry standards, and company specifications; Paragraph 0097 for reference to the logistical data may include information related to transportation, distribution, and/or transfer of goods between different entities]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the flagging criteria and reporting of Selker to include the products lifestyle logistics information of Chait. Such logistical data may be used, for example, by a rules engine to determine logistical compliance and/or to provide instructions for logistical operations, as stated by Chait (Paragraph 0097).
Claim 12
While the combination of Selker, Franco, Vemireddy, and Chait disclose the limitations above, regarding Claim 12, Selker discloses the following:
wherein raw report generation data that meets one or more of the flag criteria is automatically flagged as flagged report generation data each time raw report generation data is migrated to the products database [see at least Paragraph 0030 for reference to a quality improvement (QI) review system for automatically evaluating the quality of the care that is provided by the EMS teams responding to medical emergencies; Paragraph 0031 for reference to the QI review system automatically identifies run reports for which there is evidence that the paramedics appear to have failed to meet the applicable standards and it flags those run reports; Paragraph 0039 for reference to using those relevant criteria it automatically evaluates whether the paramedics met the applicable standard of care; Figure 2 and related text regarding item 18 ‘Auto Review’]
Claim 13
While the combination of Selker, Franco, Vemireddy, and Chait disclose the limitations above, regarding Claim 13, Selker discloses the following:
wherein the descriptive information is requested from the one or more databases based on a classification of the flagged report generation data [see at least Paragraph 0049 for reference to the QI review system is the matrix of clinical review criteria for the possible review types that might be handled by the EMS; Paragraph 0050 for reference to the four fields of review including (1) review type; (2) clinical impression; (3) chief complaint (symptoms); and (4) transport priority (critical or not critical); Paragraph 0054 for reference to the range of review types is determined by the EMS service that wants its performance reviewed; Figure 2 and related text regarding the clinical review criteria matrix]
Claim 14
While the combination of Selker, Franco, Vemireddy, and Chait disclose the limitations above, regarding Claim 14, Selker discloses the following:
wherein the classification of the flagged report generation data includes classification of the data as related to one or more of risk assessments, quality measurements, employee training, compliance management, complaints, corrective action/preventive action (CAPA), change controls, response times, and effectiveness [see at least Paragraph 0049 for reference to the QI review system is the matrix of clinical review criteria for the possible review types that might be handled by the EMS; Paragraph 0050 for reference to the four fields of review including (1) review type; (2) clinical impression; (3) chief complaint (symptoms); and (4) transport priority (critical or not critical); Paragraph 0054 for reference to the range of review types is determined by the EMS service that wants its performance reviewed; Paragraph 0081-0087 which describe the different types of reports generated including trend reports of quality of care; Figure 2 and related text regarding the clinical review criteria matrix]
Claim 15
While the combination of Selker, Franco, Vemireddy, and Chait disclose the limitations above, regarding Claim 15, Selker discloses the following:
wherein the received descriptive information related to the flagged report generation data is compiled into a report for presentation to a user [see at least Paragraph 0033 for reference to the QI review system also includes a reporting engine that enables the EMS (or a third party providing the QI review analysis) to generate various reports on the performance of the company, the performance of individual para medics, trends in performance, and comparisons with other EMS services in the area; Paragraph 0033 for reference to the system can generate reports that summarize the care given to the number of patients handled by the EMS service, it can examine and report on the performance of individual paramedics; and it can aggregate data and look at performance of the EMS service in various categories e.g. for different medical conditions; Paragraph 0047 for reference to software running of the QI Review computer system also implements a reporting package that enables the QI Review Service and/or other persons to access the system to generate various reports about the performance of the EMS; Figure 2 and related text regarding item 34 ‘Reporting’]
Claim 16
While the combination of Selker, Franco, Vemireddy, and Chait disclose the limitations above, regarding Claim 16, Selker discloses the following:
wherein the user can only access the compiled report based on a permission level of the user [see at least Paragraph 0058 for reference to the user logs into the system and the level of access that is granted to the user reflects the authority that was defined for that user; Paragraph 0088 for reference to the report wizard being an menu driven interface that enables authorized users to select which report is to be generated; Paragraph 0089 for reference to the QI Review software responds by generating the requested report for the authorized user from the stored ePCR data]
Claim 17
While the combination of Selker, Franco, Vemireddy, and Chait disclose the limitations above, regarding Claim 17, Selker discloses the following:
wherein the user can only distribute the compiled report based on a permission level of the user [see at least Paragraph 0058 for reference to the user logs into the system and the level of access that is granted to the user reflects the authority that was defined for that user; Paragraph 0088 for reference to the report wizard being an menu driven interface that enables authorized users to view the compiled report]
Claim 18
Regarding Claim 18, Selker discloses the following:
A method of automatically generating one or more business intelligence reports using a computing system, the method comprising [see at least Paragraph 0030 for reference to a quality improvement (QI) review system for automatically evaluating the quality of the care that is provided by the EMS teams responding to medical emergencies; Paragraph 0033 for reference to the QI review system also includes a reporting engine that enables the EMS (or a third party providing the QI review analysis) to generate various reports on the performance of the company, the performance of individual para medics, trends in performance, and comparisons with other EMS services in the area; Paragraph 0033 for reference to the system can generate reports that summarize the care given to the number of patients handled by the EMS service, it can examine and report on the performance of individual paramedics; and it can aggregate data and look at performance of the EMS service in various categories e.g. for different medical conditions; Figure 2 and related text regarding item 34 ‘Reporting’]
migrating, using the computing system, raw report generation data from one or more databases storing descriptive data to a products database for inclusion in a current report related to patient information, patient treatment, pharmaceutical business processes, or pharmaceutical products [see at least Paragraph 0037 for reference to paramedics enter data into that system to generate a record for the patient; Paragraph 0037 for reference to data entered including identifying information about the patient, measured Vital signs, symptoms, clinical impressions, and many details about the clinical review that was conducted and the treatment that was applied and operational information, such as details about the transport of the patient to the hospital; Paragraph 0038 for reference to the patient care record along with other records that were generated by that EMS team in that period, are electronically transferred to the computer system of a third party quality assessment agency; Paragraph 0091 for reference to one or more digital data storage devices for storing data such as the patient care record information that is downloaded from the EMS services; Figure 17 and related text regarding item 210 ‘digital storage devices’]
generating, using the computing system, one or more flag criteria for flagging raw report generation data [see at least Paragraph 0049 for reference to the QI review system is the matrix of clinical review criteria for the possible review types that might be handled by the EMS; Paragraph 0050 for reference to the four fields of review including (1) review type; (2) clinical impression; (3) chief complaint (symptoms); and (4) transport priority (critical or not critical); Figure 2 and related text regarding the clinical review criteria matrix]
flagging, using the computing system, raw report generation data that meets one or more of the flag criteria as flagged report generation data [see at least Paragraph 0031 for reference to QI review system automatically identifies run reports for which there is evidence that the paramedics appear to have failed to meet the applicable standards and it flags those run reports; Paragraph 0039 for reference to after a batch of records have been received, the QI review service then processes the received records with its computer system programmed with QI Review software; Paragraph 0039 for reference to analyzing each of the received patient care records to determine whether the paramedics met the applicable standard of care; Paragraph 0040 for reference to the QI review computer system also identifies those records for which the paramedics failed to meet all of the review criteria for the particular medical condition]
requesting, using the computing system, descriptive information from the one or more databases based on the flagged report generation data [see at least Paragraph 0041 for reference to the QI review computer system also provides a graphical user interface to authorized people on the EMS staff to access the particular identified records that have been flagged as failing to meet the relevant review criteria and to review those run reports]
receiving, using the computing system, descriptive information related to the flagged report generation data [see at least Paragraph 0041 for reference to this enables the administration and designated reviewers to access basic data and supporting documentation including the locked down electronic patient care record that was provided by the paramedics as a result of the run]
compiling, using the computing system, the received descriptive information related to the flagged report generation data into a report for presentation to a user in a form of a prescriptive report, wherein the context report includes the flagged report generation data, and context data that indicates specific flagging criteria of the flagged report generation data [see at least Paragraph 0033 for reference to the QI review system also includes a reporting engine that enables the EMS (or a third party providing the QI review analysis) to generate various reports on the performance of the company, the performance of individual para medics, trends in performance, and comparisons with other EMS services in the area; Paragraph 0033 for reference to the system can generate reports that summarize the care given to the number of patients handled by the EMS service, it can examine and report on the performance of individual paramedics; and it can aggregate data and look at performance of the EMS service in various categories e.g. for different medical conditions; Paragraph 0047 for reference to software running of the QI Review computer system also implements a reporting package that enables the QI Review Service and/or other persons to access the system to generate various reports about the performance of the EMS; Figure 2 and related text regarding item 34 ‘Reporting’]
While Selker discloses the limitations above, it does not disclose wherein the descriptive data comprises at least tracking data associated with the one or more products; wherein the flag criteria is determined dynamically based on at least historical quality assurance trends and a threshold relating to a number of reports generated within a given time period, such that the raw report generation data is flagged if the number of reports generated within the given period exceeds the threshold and the dynamically-generated deviation criteria; wherein the descriptive information comprises of a products lifecycle logistics information comprising at least shipping time, location dwell time, and refrigeration-compliance information; wherein the context report includes the flagged report generation data, and context data that indicates specific flagging criteria of the flagged report generation data, one or more potential causes determined by applying predefined rules to the received descriptive information, and at least one recommended corrective action presented and ranked based on the determined potential cause.
However, Franco discloses the following:
wherein the flag criteria is determined dynamically based on a threshold relating to a number of reports generated within a given period, such that the raw report generation data is flagged if the number of reports generated within the given period exceeds the threshold and the dynamically-generated deviation criteria [see at least Col 2 lines 35-37 for reference to the analysis including a comparison of the number of reports produced by the query to a threshold number of reports required in order to alert the user; Col 5 lines 5-11 for reference to the user’s zone of interest for the determined score including a time range; Col 9 lines 45-61 for reference to the score computation representing the overall number of reports; Col 10 lines 7-10 for reference to the computed score is analyzed to determine if it exceeds a threshold and if it does then and incident alert is reported; Figure 4 and related text regarding item 406 ‘For each group, compute a score based on the reports (and associated contextual information) in the group (and optionally any prior user inquiries’ and item 408 ‘Incident alert is reported to the inquiring user’]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the flagging criteria of Selker to include the number of reports generated within a given time period of Franco. Doing so enables a plurality of users to participate in a collaborative process whereby they can report, be alerted of, and respond to or avoid incidents such as emergencies or hazards, as stated by Franco (Col 1 lines 46-49).
While the combination of Selker and Franco disclose the limitations above, they do not disclose wherein the descriptive data comprises at least tracking data associated with the one or more products; wherein the flag criteria is determined dynamically based on at least historical quality assurance trends; wherein the descriptive information comprises of a products lifecycle logistics information comprising at least shipping time, location dwell time, and refrigeration-compliance information; wherein the context report includes one or more potential causes determined by applying predefined rules to the received descriptive information, and at least one recommended corrective action presented and ranked based on the determined potential cause.
However, Vemireddy discloses the following:
wherein the descriptive data comprises at least tracking data associated with the one or more products [see at least Paragraph 0042 for reference to clinical data including drug prescription information; Paragraph 0044 for reference to the patient entered data including use of non-prescription drugs; Paragraph 0045 for reference to the rules engine module applies the clinical rules specific to the patient’s medical data file, including checking for known drug interactions, to compare the patient’s actual care with the best evidence-based medical standard of care]
wherein the flag criteria is determined dynamically based on at least historical quality assurance trends [see at least Paragraph 0062 for reference to the rule processing session receiving the patients clinical history and inheriting rules for processing of incoming real-time data; Paragraph 0081 for reference to based on a history of a heart attack and the patient’s drug regimen compliance information (e.g., as entered by a health care provider), the rules engine module presents relevant drug-related educational materials relating to the importance of taking medications for heart attacks; Paragraph 0084 for reference to the rules engine module processes the newly-received data point in light of the previously stored health profile (e.g., prior health indicator readings, patient’s chronic conditions, age, and sex) and the best evidence-based medical standards of care to generate in real-time a normal or target range, as well as a high risk indicator, which provide context for the updated readings]
wherein the context report includes the flagged report generation data, and context data that indicates specific flagging criteria of the flagged report generation data, one or more potential causes determined by applying predefined rules to the received descriptive information, and at least one recommended corrective action presented and ranked based on the determined potential cause [see at least Paragraph 0015 for reference to the alert justification information specifies which clinical rules have been triggered/processed by the incoming data (e.g., by rule number), which alerts have been generated (e.g., by alert number), a time/date stamp for each alert, the specific exclusionary and inclusionary information for a given patient that caused the rule to trigger (e.g., known drug allergies are used to exclude alerts recommending a drug regimen that may cause an allergic reaction), as well as patient-entered and claim information associated; Paragraph 0047 for reference to the PHR allowing the patients to create printable reports containing the patients health information, including health summaries and health risk assessment reports; Paragraph 0057 for reference to the rules engine module evaluates the patient-reported and claims based health tracker data along with other clinical data available in the medical database to determine the patient specific goal for a given tracker metric and evaluate the current tracker value against that goal to trigger a clinical alert; Paragraph 0074 for reference to the alert payload filtering module consolidates outgoing alerts into recommendation families (e.g., alerts relating to potential drug interactions, medical text recommendations); Paragraph 0075 for reference to the alert payload filtering module customizing the alert text including alert justification information to the designated delivery party and the specifics of the patients health care plan; Paragraph 0084 for reference to the rules engine module provides the patient and the health care provider with real-time health trend ranges and corresponding clinical recommendations when the patient and/or the health care provider enters new health indicator data into the PHR-based health tracking tool or disease management application; Figure 16 and related text regarding the health tracking tool to allow the patient to trend one or more health indicators; Figure 17 and related text regarding an Alert Status Report indicating the alert completion and outcome status for the overall patient population]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the flagging criteria and descriptive data of Selker to include the product data and flagging criteria of Vemireddy. Doing so would provide a computer-based solution which is capable of clinically analyzing, in real-time, the accumulated health care information in light of appropriate medical standards and directly notifying the patient and the healthcare provider to ensure a prompt follow up on the results of the analysis, as stated by Vemireddy (Paragraph 0003).
While the combination of Selker, Franco, and Vemireddy disclose the limitations above, they do not disclose wherein the descriptive information comprises of a products lifecycle logistics information comprising at least shipping time, location dwell time, and refrigeration-compliance information.
However, Chait discloses the following:
wherein the descriptive information comprises of a products lifecycle logistics information comprising at least shipping time, location dwell time, and refrigeration-compliance information [see at least Paragraph 0077 for reference to critical points may be designated at outdoor loading docks, which may have prescribed time limits for unloading and loading the eggs, or may be designated at a holding facility, which may have requirements on refrigerating eggs at a certain temperature based on the age of the eggs, or may be designated at a transportation entity that may be required to maintain a prescribed temperature during transportation, and comply with maximum loading and unloading times during transfer of the eggs; Paragraph 0093 for reference to the data store may comprise: behavioral data, operational data, biological and environmental data, machine data, logistical data, regulatory rules, industry standards, and company specifications; Paragraph 0097 for reference to the logistical data may include information related to transportation, distribution, and/or transfer of goods between different entities]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the flagging criteria and reporting of Selker to include the products lifestyle logistics information of Chait. Such logistical data may be used, for example, by a rules engine to determine logistical compliance and/or to provide instructions for logistical operations, as stated by Chait (Paragraph 0097).
Claim 20
While the combination of Selker, Franco, Vemireddy, and Chait disclose the limitations above, regarding Claim 20, Selker discloses the following:
wherein the received descriptive information is compiled into a report format based on a user profile of the user requesting the business intelligence report [see at least Paragraph 0033 for reference to the QI review system also includes a reporting engine that enables the EMS (or a third party providing the QI review analysis) to generate various reports on the performance of the company, the performance of individual para medics, trends in performance, and comparisons with other EMS services in the area; Paragraph 0033 for reference to the system can generate reports that summarize the care given to the number of patients handled by the EMS service, it can examine and report on the performance of individual paramedics; and it can aggregate data and look at performance of the EMS service in various categories e.g. for different medical conditions; Paragraph 0047 for reference to software running of the QI Review computer system also implements a reporting package that enables the QI Review Service and/or other persons to access the system to generate various reports about the performance of the EMS; Figure 2 and related text regarding item 34 ‘Reporting’]
Claim(s) 4 is/are rejected under 35 U.S.C. 103 as being unpatentable over Selker (U.S 2011/0184759 A1) in view of Franco (U.S 8,024,330 B1) in view of Vemireddy (U.S 2013/0179178 A1) in view of Chait (U.S 2014/0222521 A1), as applied in claim 1, in view of James (U.S 2012/0246105 A1).
Claim 4
While the combination of Selker, Franco, Vemireddy, and Chait disclose the limitations above, Selker does not disclose wherein one or more of the incoming data, the flagged data, and the context data are stored as one or more enterprise object models.
Regarding Claim 4, James discloses the following:
wherein one or more of the incoming data, the flagged data, and the context data are stored as one or more enterprise object models [see at least Paragraph 0273 for reference to the Abstract Instance Model, often referred to as the reference model (or, when implemented, the reference implementation), defines a stable object model against which software can be built and data physically stored; Paragraph 0273 for reference to a new model representing a clinical data object may be added to the system and instances of that data model may be stored without changes to the reference model and optimizations may be performed against the reference implementation without changes to a data model]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the system of Selker to include the object model of James. Doing so enables healthcare delivery organizations to improve performance against their quality targets, resulting in better patient care at a low, appropriate cost, as stated by James (Paragraph 0043).
Claim(s) 5 is/are rejected under 35 U.S.C. 103 as being unpatentable over Selker (U.S 2011/0184759 A1) in view of Franco (U.S 8,024,330 B1) in view of Vemireddy (U.S 2013/0179178 A1) in view of Chait (U.S 2014/0222521 A1), as applied in claim 1, in view of McCullough (U.S 2017/0124284 A1).
Claim 5
While the combination of Selker, Franco, Vemireddy, and Chait disclose the limitations above, Selker does not disclose wherein the flagging criteria includes a pharmaceutical expiration data.
Regarding Claim 5, McCullough discloses the following:
wherein the flagging criteria includes a pharmaceutical expiration data [see at least Paragraph 0090 for reference to the system monitoring and communicating information including expiration date; Paragraph 0093 for reference to information such as environmental history, instructions for use, storage instructions, product authenticity or any associated field alerts for the produced lot of materials, expiration date, medication reminders and current location or estimated arrival through shipping provide information of interest to the user]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the flagging criteria of Selker to include the expiration data of McCullough. Doing so would help alert interested and authorized parties to product location in the event of field events such as product transfer or return and replacement under recall, as stated by McCullough (Paragraph 0090).
Claim(s) 9 and 10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Selker (U.S 2011/0184759 A1) in view of Franco (U.S 8,024,330 B1) in view of Vemireddy (U.S 2013/0179178 A1) in view of Chait (U.S 2014/0222521 A1), as applied in claim 1, in view of Sadeghi (U.S 2014/0278448 A1).
Claim 9
While the combination of Selker, Franco, Vemireddy, and Chait disclose the limitations above, they do not disclose wherein the flagging criteria includes one or more metadata tags for tagging received data.
Regarding Claim 9, Sadeghi discloses the following:
wherein the flagging criteria includes one or more metadata tags for tagging received data [see at least Paragraph 0045 for reference to suitable contextual information or combination thereof may be used to understand the analyzed text including metadata associated with the medical report; Paragraph 0078 for reference to the Order Data pane may display metadata associated with the medical report displayed in the Report pane]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the flagging criteria of Selker to include the metadata tags of Sadeghi. Doing so would reduce the occurrence rate of false positive alerts, as stated by Sadeghi (Paragraph 0045).
Claim 10
While the combination of Selker, Franco, Vemireddy, Chait, and Sadeghi discloses the limitations above, Selker does not disclose wherein the one or more metadata tags are object based metadata tags.
Regarding Claim 10, Sadeghi discloses the following:
wherein the one or more metadata tags are object based metadata tags [see at least Paragraph 0045 for reference to suitable contextual information or combination thereof may be used to understand the analyzed text including metadata associated with the medical report; Paragraph 0068 for reference to examples of metadata including patient gender, order procedure code (e.g., as established by a medical institution, insurance company, government agency, or other organization), order procedural description (e.g., “XRAY Left Leg'), etc.; Paragraph 0078 for reference to the Order Data pane may display metadata associated with the medical report displayed in the Report pane]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the flagging criteria of Selker to include the metadata tags of Sadeghi. Doing so would reduce the occurrence rate of false positive alerts, as stated by Sadeghi (Paragraph 0045).
Claim(s) 19 is/are rejected under 35 U.S.C. 103 as being unpatentable over Selker (U.S 2011/0184759 A1) in view of Franco (U.S 8,024,330 B1) in view of Vemireddy (U.S 2013/0179178 A1) in view of Chait (U.S 2014/0222521 A1), as applied in claim 18, in view of Sadeghi (U.S 2014/0278448 A1).
Claim 19
While the combination of Selker, Franco, Vemireddy, and Chait discloses the limitations above, they do not disclose wherein the raw report generation data is flagged based on one or more metadata tags associated with the raw report generation data.
Regarding Claim 19, Sadeghi discloses the following:
wherein the raw report generation data is flagged based on one or more metadata tags associated with the raw report generation data [see at least Paragraph 0045 for reference to suitable contextual information or combination thereof may be used to understand the analyzed text including metadata associated with the medical report; Paragraph 0078 for reference to the Order Data pane may display metadata associated with the medical report displayed in the Report pane]
Before the effective filing date, it would have been obvious to one of ordinary skill in the art to modify the flagging criteria of Selker to include the metadata tags of Sadeghi. Doing so would reduce the occurrence rate of false positive alerts, as stated by Sadeghi (Paragraph 0045).
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Prasad, Biren. "Survey of life-cycle measures and metrics for concurrent product and process design." AI EDAM 14.2 (2000): 163-176.
DOCUMENT ID
INVENTOR(S)
TITLE
US 7799273 B2
Popp, Shane M.
Manufacturing Execution System For Validation, Quality And Risk Assessment And Monitoring Of Pharmaceutical Manufacturing Processes
AU 2006214717 A1
Cleavenger, Darrell S.
Business Statistical Analysis Reporting Module And Method For Client Application Systems
Any inquiry concerning this communication or earlier communications from the examiner should be directed to KRISTIN ELIZABETH GAVIN whose telephone number is (571)270-7019. The examiner can normally be reached M-F 7:30-4:30 PM EST.
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, Jerry O'Connor can be reached at 571-272-6787. 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.
/KRISTIN E GAVIN/Primary Examiner, Art Unit 3624
Prosecution Insights