DETAILED ACTION
Notice of Pre-AIA or AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Response to Amendment
The IDS has been considered.
In light of the amendments, the claims are rejected under 35 U.S.C. 101.
In light of the amendments, the claims are rejected under 35 U.S.C. 103.
Notice to Applicant
In the amendment dated 11/12/2025, the following has occurred: claims 1, 7, 13, and 19 have been amended; claims 2-6, 8-12, 14-18, and 20-21 have remained unchanged; and no new claims have been added.
Claims 1-21 are pending.
Effective Filing Date: 01/31/2020
Response to Arguments
35 U.S.C. 101 Rejections:
Applicant amended the claims and then argued with respect to these amendments. Examiner has updated the 35 U.S.C. 101 rejection section to account for these amendments. In order to advance prosecution however, some of the arguments will be addressed below.
Step 2A, Prong 1:
Applicant argues that the claims do not include an abstract idea that would be categorized under certain methods of organizing human activity. Examiner however respectfully disagrees. The claims do include such an abstract concept. Applicant states that the claims should not be directed to any of the subgroupings under certain methods as they do not fall within the ones disclosed in the MPEP as the claims are different than the examples. Examiner would like to note however that these subgroupings are not limited to the examples disclosed in the MPEP.
Step 2A, Prong 2:
Applicant argues that the additional limitations should not be examined in a vacuum. Examiner is examining the claims as a whole. The stated improvement to clinical trial design by improving collaboration within the design process, improvements to adjusting the analysis flow, and improvements to how the information is shared to people based on their role. The claims do not include additional elements which integrate with the abstract idea to form a practical application. The additional elements are being applied to the abstract idea. Furthermore, the improvements here appear to be improvements to the abstract idea involving updating and displaying information to a user.
Step 2B:
Lasty, Applicant argues that the claims recite limitations which are not generic computer functions. Applicant states that the displaying of pre- and post-clinical trial design analysis flow adjustment clinical trial design simulation results to multiple users in real-time with views customized to their roles is not a well-known, generic process. Examiner however would like to kindly remind Applicant though that this element is not an additional element based on current claim construction. It is part of the abstract idea, therefore a determination of if this limitation is generic would not occur.
35 U.S.C. 103 Rejections:
Applicant argues that the Shu reference does not teach the newly-added subject matter in paragraph [0009]. Examiner agrees, however it is taught using Shu and Harder in part. Shu teaches of simulation optimization using a computing device, and Harder teaches a clinical trial development user. Having a person do something that a computer is already doing is reasonable to swap.
Information Disclosure Statement
The information disclosure statements (IDS) submitted on 11/12/2025 are in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statements are being considered by the examiner.
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-21 are rejected under 35 U.S.C. 101 because the claimed invention is directed to a judicial exception (i.e., a law of nature, a natural phenomenon, or an abstract idea) without significantly more. Claims 1-6 are drawn to a method, claims 7-12 are drawn to an apparatus, claims 13-18 are drawn to a medium, and claims 19-21 are drawn to a method, each of which is within the four statutory categories. Claims 1-21 are further directed to an abstract idea on the grounds set out in detail below. As discussed below, the claims do not include additional elements that are sufficient to amount to significantly more than the abstract idea because the additional computer elements, which are recited at a high level of generality, provide conventional computer functions that do not add meaningful limits to practicing the abstract idea (Step 1: YES).
Step 2A:
Prong One:
Claim 1 recites a method, comprising:
1) receiving, via a) at least one processor, a role of a clinical trial development team user of a first instance of a plurality of instances of b) a graphical user interface, wherein b) the graphical user interface is structured to depict a configuration for a clinical trial design analysis flow, wherein the clinical trial design analysis flow comprises at least one clinical trial simulation model utilized by c) at least one clinical trial design simulation engine structured to simulate one or more clinical trial designs;
2) configuring, via a) the at least one processor, the first instance of b) the graphical user interface for the role of the clinical trial development team user, wherein configuring the first instance of b) the graphical user interface comprises determining, via a) the at least one processor, an interface view for the role;
3) displaying, via a) the at least one processor, the first instance of b) the graphical user interface with the interface view displaying a first result of c) the at least one clinical trial design simulation engine simulating the one or more clinical trial designs, wherein c) the at least one clinical trial design simulation engine generates the first result utilizing at least one simulation parameter of the at least one clinical trial simulation model, wherein the at least one simulation parameter is based at least in part on an expertise of the clinical trial development team user, wherein the clinical trial development team user optimizes the trial simulation model;
4) receiving, via the first instance of b) the graphical user interface, a user input from the clinical trial development team user, wherein the user input is related to the at least one simulation parameter;
5) displaying, via a) the at least one processor and responsive to the user input, an adjustment to the clinical trial design analysis flow across the plurality of instances of b) the graphical user interface in real-time, wherein each of the plurality of instances of b) the graphical user interface is configured for a different role; and
6) displaying, on each of the plurality of instances of b) the graphical user interface, a second result of c) the at least one clinical trial design simulation engine based at least in part on the adjusted clinical trial design analysis flow.
Claim 1 recites, in part, performing the steps of 1) receiving a role of a clinical trial development team user of a first instance of a plurality of instances of a user interface, wherein the user interface (a sheet of paper) is structured to depict a configuration for a clinical trial design analysis flow, wherein the clinical trial design analysis flow comprises at least one clinical trial simulation model utilized by at least one clinical trial design simulation engine (the engine may be an icon of a paper) structured to simulate one or more clinical trial designs, 2) configuring the first instance of the user interface for the role of the clinical trial development team user, wherein configuring the first instance of the user interface comprises determining an interface view for the role, 3) displaying the first instance of the user interface with the interface view displaying a first result of the at least one clinical trial design simulation engine (the engine may be an icon of a paper) simulating the one or more clinical trial designs, wherein the at least one clinical trial design simulation engine generates the first result utilizing at least one simulation parameter of the at least one clinical trial simulation model, wherein the at least one simulation parameter is based at least in part on an expertise of the clinical trial development team user, wherein the clinical trial development team optimizes the trial simulation model, 4) receiving, via the first instance of the user interface, a user input from the clinical trial development team user, wherein the user input is related to the at least one simulation parameter, 5) displaying, responsive to the user input, an adjustment to the clinical trial design analysis flow across the plurality of instances of the user interface in real-time, (this may be done by adjusting two pieces of paper in “real-time”) wherein each of the plurality of instances of the user interface is configured for a different role, and 6) displaying, on each of the plurality of instances of the user interface, a second result of the at least one clinical trial design simulation engine (the engine may be an icon of a paper) based at least in part on the adjusted clinical trial design analysis flow. These steps correspond to Certain Methods of Organizing Human Activity, more particularly, managing personal behavior or relationships or interactions between people (including following rules or instructions). For example, the claim describes updating and displaying data to users. Independent claims 7 and 13 recite similar limitations and are also directed to an abstract idea under the same analysis.
Claim 19 recites a method comprising:
7) interpreting a first command value to generate an interface view for a first instance of a plurality of instances of a clinical trial design application, wherein the clinical trial design application is structured to depict a configuration for a clinical trial design analysis flow, wherein the clinical trial design analysis flow comprises at least one clinical trial simulation model utilized by at least one clinical trial design simulation engine structured to simulate one or more clinical trial designs;
8) generating, in response to the first command value, first interface data structured to display the interface view on an electronic display, wherein the interface view is adapted to a trial development team clinician, wherein the first interface data is at least in part generated utilizing at least one simulation parameter of the at least one clinical trial simulation model, wherein the at least one simulation parameter is based at least in part on an expertise of the trial development team clinician, wherein the trial development team clinician optimizes the trial simulation model;
9) transmitting the first interface data;
10) interpreting a second command value to adjust the clinical trial design analysis flow, wherein the second command value is related to the at least one simulation parameter;
11) generating, in response to the second command value, second interface data structured to display an adjustment to the clinical trial design analysis flow across the plurality of instances of the clinical trial design application in real-time, wherein each of the plurality of instances of the clinical trial design application is configured for a different role;
12) transmitting the second interface data;
13) generating third interface data structured to display, on each of the plurality of instances of the clinical trial design application, a second result of the at least one clinical trial design simulation engine based at least in part on the adjusted clinical trial design analysis flow; and
14) transmitting the third interface data.
Claim 19 recites, in part, performing the steps of 7) interpreting a first command value to generate an interface view for a first instance of a plurality of instances of a clinical trial design application (on a sheet of paper), wherein the clinical trial design application is structured to depict a configuration for a clinical trial design analysis flow, wherein the clinical trial design analysis flow comprises at least one clinical trial simulation model utilized by comprising at least one clinical trial design simulation engine (the engine may be an icon of a paper) structured to simulate one or more clinical trial designs, 8) generating, in response to the first command value, first interface data structured to display the interface view, wherein the interface view is adapted to a trial development team clinician, wherein the first interface data is at least in part generated utilizing at least one simulation parameter of the at least one clinical trial simulation model, wherein the at least one simulation parameter is based at least in part on an expertise of the clinical trial development team clinician, wherein the trial development team clinician optimizes the trial simulation model, 9) transmitting the first interface data, 10) interpreting a second command value to adjust the clinical trial design analysis flow, wherein the second command value is related to the at least one simulation parameter, 11) generating, in response to the second command value, second interface data structured to display an adjustment to the clinical trial design analysis flow across the plurality of instances of the clinical trial design application in real-time, (this may be done by adjusting two pieces of paper in “real-time”) wherein each of the plurality of instances of the clinical trial design application is configured for a different role, 12) transmitting the second interface data, 13) generating third interface data structured to display, on each of the plurality of instances of the clinical trial design application, a second result of the at least one clinical trial design simulation engine (the engine may be an icon of a paper) based at least in part on the adjusted clinical trial design analysis flow, and 14) transmitting the third interface data. These steps correspond to Certain Methods of Organizing Human Activity, more particularly, managing personal behavior or relationships or interactions between people (including following rules or instructions). For example, the claim describes updating and displaying data to users.
Depending claims 2-6, 8-12, 14-18, and 20-21 include all of the limitations of claims 1, 7, 13, and 19, and therefore likewise incorporate the above described abstract idea. The limitations of depending claims 2-6, 8-12, 14-18, and 20-21 further specify elements from the claims from which they depend on without adding any additional steps. These additional limitations only further serve to limit the abstract idea. Thus, depending claims 2-6, 8-12, 14-18, and 20-21 are nonetheless directed towards fundamentally the same abstract idea as independent claims 1, 7, 13, and 19 (Step 2A (Prong One): YES).
Prong Two:
This judicial exception is not integrated into a practical application. In particular, the claims recite the additional elements of – using a) at least one processor, b) a graphical user interface, c) at least one clinical trial design simulation engine, d) a device property data processing circuit (from claim 7), e) an electronic display (in claim 19), f) a computing device with a processor (from claim 19) to perform the claimed steps.
The a) at least one processor, b) a graphical user interface, c) at least one clinical trial design simulation engine, d) a device property data processing circuit, e) an electronic display, f) a computing device with a processor in these steps are recited at a high-level of generality (i.e., as generic components performing generic computer functions) such that it amount to no more than mere instructions to apply the exception using generic computer components (see: Applicant’s specification, paragraph [1344] where there are general purpose computing components, see MPEP 2106.05(f)).
Dependent claims recite additional subject matter which amount to limitations consistent with the additional elements in the independent claims. Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually. There is no indication that the combination of elements improves the functioning of a computer or improves any other technology. Their collective functions merely provide conventional computer implementation and do not impose a meaningful limit to integrate the abstract idea into a practical application.
Accordingly, these additional elements do not integrate the abstract idea into a practical application because they do not impose any meaningful limits on practicing the abstract idea. The claims are directed to an abstract idea (Step 2A (Prong Two): NO).
Step 2B:
The claims do not include additional elements that are sufficient to amount to significantly more than the judicial exception. As discussed above with respect to integration of the abstract idea into a practical application, the additional elements of using a) at least one processor, b) a graphical user interface, c) at least one clinical trial design simulation engine, d) a device property data processing circuit, e) an electronic display, f) a computing device with a processor to perform the claimed steps amounts to no more than mere instructions to apply the exception using generic computer components that does not offer “significantly more” than the abstract idea itself because the claims do not recite an improvement to another technology or technical field, an improvement to the functioning of any computer itself, or provide meaningful limitations beyond generally linking an abstract idea to a particular technological environment. It should be noted that the claims do not include additional elements that amount to significantly more than the judicial exception because the Specification recites mere generic computer components, as discussed above that are being used to apply certain method steps of organizing human activity. Specifically, MPEP 2106.05(f) recites that the following limitations are not significantly more:
Adding the words "apply it" (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, e.g., a limitation indicating that a particular function such as creating and maintaining electronic records is performed by a computer, as discussed in Alice Corp., 134 S. Ct. at 2360, 110 USPQ2d at 1984 (see MPEP § 2106.05(f)).
The current invention generates a display utilizing a) at least one processor, b) a graphical user interface, c) at least one clinical trial design simulation engine, d) a device property data processing circuit, e) an electronic display, f) a computing device with a processor, thus these computing components are adding the words “apply it” with mere instructions to implement the abstract idea on a computer.
Mere instructions to apply an exception using generic computer components cannot provide an inventive concept. The claims are not patent eligible (Step 2B: NO).
Claims 1-21 are therefore rejected under 35 U.S.C. 101 as being directed to non-statutory subject matter.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
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.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1-3, 7-9, 13-15, and 19-21 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. 2016/0239619 to Harder et al. in view of U.S. 2016/0239619 to Abou-Hawili et al. and further in view of U.S. 2016/0253463 to Shu et al.
As per claim 1, Harder et al. teaches a method, comprising:
--wherein the graphical user interface is structured to depict a configuration for a clinical trial design analysis flow, wherein the clinical trial design analysis flow comprises at least one clinical trial simulation model utilized by at least one clinical trial design simulation engine structured to simulate one or more clinical trial designs; (see: FIG. 2 and paragraph [0052] where there is an interface which depicts a configuration for a clinical trial design analysis flow. This depiction comprises a design simulation engine which uses a model to simulate the design in the form of a flow)
--displaying, via the at least one processor, the first instance of the graphical user interface with the interface view displaying a first result of the at least one clinical trial design simulation engine simulating the one or more clinical trial designs, (see: FIG. 14 and paragraph [0066] where there is display of predictive analytics (a first result of a design simulation engine simulating the design) associated with the clinical trial metrics in the dashboard) wherein the at least one clinical trial design simulation engine generates the first result utilizing at least one simulation parameter of the at least one clinical trial simulation model, (see: FIG. 14 and paragraph [0066] where there is at least one clinical trial design simulation engine that generate a first result (predictive analytics) using at least one simulation parameter of a model (clinical trial metrics in the dashboard are part of a model))
--something as the clinical trial development team user; (see: paragraph [0006] where there is such a user)
--receiving, via the first instance of the graphical user interface, a user input from the clinical trial development team user, wherein the user input is related to the at least one simulation parameter; (see: paragraph [0061] where the clinical plan schema may be edited. Also see: paragraphs [0057], [0067], and [0076] where an editor is opened when a node is selected. The editor is for inputting design parameters. A user input is being received here on the interface which it is inputted in and that input is related to at least one design/simulation parameter)
--displaying, via the at least one processor and responsive to the user input, an adjustment to the clinical trial design analysis flow across the plurality of instances of the graphical user interface in real-time, (see: paragraph [0061] where the clinical plan schema may be edited. Also see: paragraph [0040] where the graphic representations may be updated automatically and dynamically such that any user in any location may access and view the updated graphic representation. The adjustment to the schema is being shown (such as FIG. 2) across a plurality of instances of the interface in real-time in response to the updated user input) and
--displaying, on each of the plurality of instances of the graphical user interface, a second result of the at least one clinical trial design simulation engine based at least in part on the adjusted clinical trial design analysis flow (see: FIG. 14 and paragraph [0066] where there is display of predictive analytics (a result of a design simulation engine simulating the design) associated with the clinical trial metrics in the dashboard. Also see: paragraph [0061] where the clinical plan schema may be edited. Also see: paragraph [0040] where the graphic representations may be updated automatically and dynamically such that any user in any location may access and view the updated graphic representation. Thus, an update to the schema will cause an updated to the predictive analytics to be shown, a second result (updated predictive analytics) is being displayed on each instance for each user based on the adjusted analysis flow (updates to the schema)).
Harder et al. may not further, specifically teach:
1) --receiving, via at least one processor, a role of a clinical trial development team user of a first instance of a plurality of instances of a graphical user interface;
2) --configuring, via the at least one processor, the first instance of the graphical user interface for the role of the clinical trial development team user, wherein configuring the first instance of the graphical user interface comprises determining, via the at least one processor, an interface view for the role;
3) --wherein the at least one simulation parameter is based at least in part on an expertise of the clinical trial development team user, wherein the clinical trial development team user optimizes the trial simulation model; and
4) --wherein each of the plurality of instances of the graphical user interface is configured for a different role.
Abou-Hawili et al. teaches:
1) --receiving, via at least one processor, a clinical trial development team role of a user of a first instance of a plurality of instances of a graphical user interface; (see: paragraph [0009] where role data is being received by a system. Also see: paragraph [0041] where there are different interface views based on the roles of the user. The role of a user of a first instance/view is being received when a clinician logs in. There are a plurality of views/instances here depending on the role of a user. The user relating to a clinical trial development team role was already taught in the Harder et al. reference at paragraph [0038])
2) --configuring, via the at least one processor, the first instance of the graphical user interface for the role of the clinical trial development team user, (see: paragraph [0009] where a role-based interface is being generated. Also see: paragraph [0041] where there are different interface views based on the roles of the user. The first instance/view is being configured when a clinician logs in. There are a plurality of views/instances here depending on the role of a user. The user relating to a clinical trial development team role was already taught in the Harder et al. reference at paragraph [0038]) wherein configuring the first instance of the graphical user interface comprises determining, via the at least one processor, an interface view for the role; (see: paragraph [0010] where the role-based user display is being generated and displayed. Also see: paragraph [0041] where there are different interface views based on the roles of the user. There are a plurality of views/instances here depending on the role of a user. There is a determination here of an interface view for the role when determining the screen (first instance of the graphical user interface) to show the user) and
4) --wherein each of the plurality of instances of the graphical user interface is configured for a different role (see: paragraph [0041] where there are views based on roles. Thus, each of the instances/views are for different roles as they are based on these roles).
One of ordinary skill before the effective filing date of the claimed invention would have found it obvious to 1) receive, via at least one processor, a clinical trial development team role of a user of a first instance of a plurality of instances of a graphical user interface, 2) configure, via the at least one processor, the first instance of the graphical user interface for the role of the clinical trial development team user, wherein configuring the first instance of the graphical user interface comprises determining, via the at least one processor, an interface view for the role, and have 4) wherein each of the plurality of instances of the graphical user interface is configured for a different role as taught by Abou-Hawili et al. in the method as taught by Harder et al. with the motivation(s) of improving care planning workflow and coordination/collaboration (see: paragraph [0004] of Abou-Hawili et al.).
Shu et al. teaches:
3) --wherein the at least one simulation parameter is based at least in part on an expertise of the clinical trial development team user, (see: paragraph [0009] where there is a simulation using at least one parameter based in part on the expertise of the individual) wherein something optimizes the trial simulation model; (see: paragraph [0008] where there is optimizing the random variables of the simulated HR plan with respect to an objective function representing objectives for staffing of the medical institution. The optimization is happening here but by a computer)
One of ordinary skill before the effective filing date of the claimed invention would have found it obvious to have 3) wherein the at least one simulation parameter is based at least in part on an expertise of the clinical trial development team user as taught by Shu et al. in the method as taught by Harder et al. and Abou-Hawili et al. in combination with the motivation(s) of optimizing one or more parameters of a facility (see: paragraph [0001] of Shu et al.).
Therefore it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to substitute the clinical trial development team user as taught by Harder et al. for the entity that is performing the optimizing as disclosed by Shu et al. since each individual element and its function are shown in the prior art, with the difference being the substitution of the elements. In the present case, Shu et al. already teaches of optimization of a simulation thus it would be obvious to switch what is doing the optimizing as predictable results of optimizing a model would occur. Thus, one of ordinary skill in the art could have substituted the one known element for the other to produce a predictable result (MPEP 2143).
As per claim 2, Harder et al., Abou-Hawili et al., and Shu et al. in combination teaches the method of claim 1, see discussion of claim 1. Abou-Hawili et al. further teaches wherein the interface view is a clinician interface view (see: paragraph [0042] where the interface view is a clinician’s interface view).
The motivations to combine the above-mentioned references are discussed in the rejection of claim 1, and incorporated herein.
As per claim 3, Harder et al., Abou-Hawili et al., and Shu et al. in combination teaches the method of claim 1, see discussion of claim 1. Abou-Hawili et al. further teaches wherein configuring the first instance of the graphical user interface for the role comprises changing at least one of a feature or display of the first instance of the graphical user interface (see: paragraph [0040] where there is a change in the display based on the role, where different data is being provided to an engine to determine what is to be displayed on the display).
The motivations to combine the above-mentioned references are discussed in the rejection of claim 1, and incorporated herein.
As per claim 7, Harder et al. teaches an apparatus, (see: paragraph [0046] where there is an apparatus/device) comprising:
--a device property data processing circuit (see: paragraph [0046] where there is a device with a circuit) structured to:
--wherein: the graphical user interface is structured to depict a configuration for a clinical trial design analysis flow comprising at least one clinical trial design simulation engine structured to simulate one or more clinical trial designs, wherein the clinical trial design analysis flow comprises at least one clinical trial simulation model utilized by at least one clinical trial design simulation engine; (see: FIG. 2 and paragraph [0052] where there is an interface which depicts a configuration for a clinical trial design analysis flow. This depiction comprises a design simulation engine which simulated the design in the form of a flow)
--display the first instance of the graphical user interface with the interface view displaying a first result of the at least one clinical trial design simulation engine simulating the one or more clinical trial designs, (see: FIG. 14 and paragraph [0066] where there is display of predictive analytics (a first result of a design simulation engine simulating the design) associated with the clinical trial metrics in the dashboard) wherein the at least one clinical trial design simulation engine generates the first result utilizing at least one simulation parameter of the at least one clinical trial simulation model; (see: FIG. 14 and paragraph [0066] where there is at least one clinical trial design simulation engine that generate a first result (predictive analytics) using at least one simulation parameter of a model (clinical trial metrics in the dashboard are part of a model))
--receive a user input from the clinical trial development team user, wherein the user input is related to the at least one simulation parameter; (see: paragraph [0061] where the clinical plan schema may be edited. Also see: paragraphs [0057], [0067], and [0076] where an editor is opened when a node is selected. The editor is for inputting design parameters. A user input is being received here on the interface which it is inputted in and that input is related to at least one design/simulation parameter)
--display, responsive to the user input, an adjustment to the clinical trial design analysis flow across the plurality of instances of the graphical user interface in real-time, (see: paragraph [0061] where the clinical plan schema may be edited. Also see: paragraph [0040] where the graphic representations may be updated automatically and dynamically such that any user in any location may access and view the updated graphic representation. The adjustment to the schema is being shown (such as FIG. 2) across a plurality of instances of the interface in real-time in response to the updated user input) and
--display, on each of the plurality of instances of the graphical user interface, a second result of the at least one clinical trial design simulation engine based at least in part on the adjusted clinical trial design analysis flow (see: FIG. 14 and paragraph [0066] where there is display of predictive analytics (a result of a design simulation engine simulating the design) associated with the clinical trial metrics in the dashboard. Also see: paragraph [0061] where the clinical plan schema may be edited. Also see: paragraph [0040] where the graphic representations may be updated automatically and dynamically such that any user in any location may access and view the updated graphic representation. Thus, an update to the schema will cause an updated to the predictive analytics to be shown, a second result (updated predictive analytics) is being displayed on each instance for each user based on the adjusted analysis flow (updates to the schema)).
Harder et al. may not further, specifically teach:
1) --identify a role of a clinical trial development team user;
2) --configure a first instance of a plurality of instances of a graphical user interface for the role, and configuring the first instance of the graphical user interface comprises determining an interface view for the role;
3) --wherein the at least one simulation parameter is based at least in part on an expertise of the clinical trial development team user; and
4) --wherein each of the plurality of instances of the graphical user interface is configured for a different role.
Abou-Hawili et al. teaches:
1) --identify a role of a clinical trial development team user; (see: paragraph [0009] where role data is being received by a system. The user relating to a clinical trial development team role was already taught in the Harder et al. reference at paragraph [0038])
2) --configure a first instance of a plurality of instances of a graphical user interface for the role, (see: paragraph [0009] where a role-based interface is being generated. Also see: paragraph [0041] where there are different interface views based on the roles of the user. The first instance/view is being configured when a clinician logs in. There are a plurality of views/instances here depending on the role of a user) and configuring the first instance of the graphical user interface comprises determining an interface view for the role; (see: paragraph [0010] where the role-based user display is being generated and displayed. Also see: paragraph [0041] where there are different interface views based on the roles of the user. There are a plurality of views/instances here depending on the role of a user. There is a determination here of an interface view for the role when determining the screen (first instance of the graphical user interface) to show the user) and
4) --wherein each of the plurality of instances of the graphical user interface is configured for a different role (see: paragraph [0041] where there are views based on roles. Thus, each of the instances/views are for different roles as they are based on these roles).
One of ordinary skill before the effective filing date of the claimed invention would have found it obvious to 1) identify a role of a clinical trial development team user, 2) configure a first instance of a plurality of instances of a graphical user interface for the role, and configuring the first instance of the graphical user interface comprises determining an interface view for the role, and have 4) wherein each of the plurality of instances of the graphical user interface is configured for a different role as taught by Abou-Hawili et al. in the apparatus as taught by Harder et al. with the motivation(s) of improving care planning workflow and coordination/collaboration (see: paragraph [0004] of Abou-Hawili et al.).
Shu et al. teaches:
3) --wherein the at least one simulation parameter is based at least in part on an expertise of the clinical trial development team user (see: paragraph [0009] where there is a simulation using at least one parameter based in part on the expertise of the individual).
One of ordinary skill before the effective filing date of the claimed invention would have found it obvious to have 3) wherein the at least one simulation parameter is based at least in part on an expertise of the clinical trial development team user as taught by Shu et al. in the apparatus as taught by Harder et al. and Abou-Hawili et al. in combination with the motivation(s) of optimizing one or more parameters of a facility (see: paragraph [0001] of Shu et al.).
As per claim 8, Harder et al., Abou-Hawili et al., and Shu et al. in combination teaches the apparatus of claim 7, see discussion of claim 7. Abou-Hawili et al. further teaches wherein the interface view is a clinician interface view (see: paragraph [0042] where the interface view is a clinician’s interface view).
The motivations to combine the above-mentioned references are discussed in the rejection of claim 7, and incorporated herein.
As per claim 9, Harder et al., Abou-Hawili et al., and Shu et al. in combination teaches the apparatus of claim 7, see discussion of claim 7. Abou-Hawili et al. further teaches wherein to configure the first instance of the graphical user interface for the role comprises changing at least one of a feature or display of the first instance of the graphical user interface (see: paragraph [0040] where there is a change in the display based on the role, where different data is being provided to an engine to determine what is to be displayed on the display).
The motivations to combine the above-mentioned references are discussed in the rejection of claim 7, and incorporated herein.
As per claim 13, Harder et al. teaches a non-transitory computer-readable storage medium storing instructions, (see: paragraph [0046] where there is a medium with instructions) that when executed by a processor of a computing device, cause the computing device to:
--wherein: the graphical user interface is structured to depict a configuration for a clinical trial design analysis flow comprising at least one clinical trial design simulation engine structured to simulate one or more clinical trial designs, wherein the clinical trial design analysis flow comprises at least one clinical trial simulation model utilized by at least one clinical trial design simulation engine; (see: FIG. 2 and paragraph [0052] where there is an interface which depicts a configuration for a clinical trial design analysis flow. This depiction comprises a design simulation engine which simulated the design in the form of a flow)
--display the first instance of the graphical user interface with the interface view displaying a first result of the at least one clinical trial design simulation engine simulating the one or more clinical trial designs, (see: FIG. 14 and paragraph [0066] where there is display of predictive analytics (a first result of a design simulation engine simulating the design) associated with the clinical trial metrics in the dashboard) wherein the at least one clinical trial design simulation engine generates the first result utilizing at least one simulation parameter of the at least one clinical trial simulation model; (see: FIG. 14 and paragraph [0066] where there is at least one clinical trial design simulation engine that generate a first result (predictive analytics) using at least one simulation parameter of a model (clinical trial metrics in the dashboard are part of a model))
--receive a user input from the clinical trial development team user, wherein the user input is related to the at least one simulation parameter; (see: paragraph [0061] where the clinical plan schema may be edited. Also see: paragraphs [0057], [0067], and [0076] where an editor is opened when a node is selected. The editor is for inputting design parameters. A user input is being received here on the interface which it is inputted in and that input is related to at least one design/simulation parameter)
--display, responsive to the user input, an adjustment to the clinical trial design analysis flow across the plurality of instances of the graphical user interface in real-time, (see: paragraph [0061] where the clinical plan schema may be edited. Also see: paragraph [0040] where the graphic representations may be updated automatically and dynamically such that any user in any location may access and view the updated graphic representation. The adjustment to the schema is being shown (such as FIG. 2) across a plurality of instances of the interface in real-time in response to the updated user input) and
--display, on each of the plurality of instances of the graphical user interface, a second result of the at least one clinical trial design simulation engine based at least in part on the adjusted clinical trial design analysis flow (see: FIG. 14 and paragraph [0066] where there is display of predictive analytics (a result of a design simulation engine simulating the design) associated with the clinical trial metrics in the dashboard. Also see: paragraph [0061] where the clinical plan schema may be edited. Also see: paragraph [0040] where the graphic representations may be updated automatically and dynamically such that any user in any location may access and view the updated graphic representation. Thus, an update to the schema will cause an updated to the predictive analytics to be shown, a second result (updated predictive analytics) is being displayed on each instance for each user based on the adjusted analysis flow (updates to the schema)).
Harder et al. may not further, specifically teach:
1) --identify a role of a clinical trial development team user;
2) --configure a first instance of a plurality of instances of a graphical user interface for the role, and configuring the first instance of the graphical user interface comprises determining an interface view for the role;
3) --wherein the at least one simulation parameter is based at least in part on an expertise of the clinical trial development team user; and
4) --wherein each of the plurality of instances of the graphical user interface is configured for a different role.
Abou-Hawili et al. teaches:
1) --identify a role of a clinical trial development team user; (see: paragraph [0009] where role data is being received by a system. The user relating to a clinical trial development team role was already taught in the Harder et al. reference at paragraph [0038])
2) --configure a first instance of a plurality of instances of a graphical user interface for the role, (see: paragraph [0009] where a role-based interface is being generated. Also see: paragraph [0041] where there are different interface views based on the roles of the user. The first instance/view is being configured when a clinician logs in. There are a plurality of views/instances here depending on the role of a user) and configuring the first instance of the graphical user interface comprises determining an interface view for the role; (see: paragraph [0010] where the role-based user display is being generated and displayed. Also see: paragraph [0041] where there are different interface views based on the roles of the user. There are a plurality of views/instances here depending on the role of a user. There is a determination here of an interface view for the role when determining the screen (first instance of the graphical user interface) to show the user) and
4) --wherein each of the plurality of instances of the graphical user interface is configured for a different role (see: paragraph [0041] where there are views based on roles. Thus, each of the instances/views are for different roles as they are based on these roles).
One of ordinary skill before the effective filing date of the claimed invention would have found it obvious to 1) identify a role of a clinical trial development team user, 2) configure a first instance of a plurality of instances of a graphical user interface for the role, and configuring the first instance of the graphical user interface comprises determining an interface view for the role, and have 4) wherein each of the plurality of instances of the graphical user interface is configured for a different role as taught by Abou-Hawili et al. in the medium as taught by Harder et al. with the motivation(s) of improving care planning workflow and coordination/collaboration (see: paragraph [0004] of Abou-Hawili et al.).
Shu et al. teaches:
3) --wherein the at least one simulation parameter is based at least in part on an expertise of the clinical trial development team user (see: paragraph [0009] where there is a simulation using at least one parameter based in part on the expertise of the individual).
One of ordinary skill before the effective filing date of the claimed invention would have found it obvious to have 3) wherein the at least one simulation parameter is based at least in part on an expertise of the clinical trial development team user as taught by Shu et al. in the medium as taught by Harder et al. and Abou-Hawili et al. in combination with the motivation(s) of optimizing one or more parameters of a facility (see: paragraph [0001] of Shu et al.).
As per claim 14, Harder et al., Abou-Hawili et al., and Shu et al. in combination teaches the medium of claim 13, see discussion of claim 13. Abou-Hawili et al. further teaches wherein the interface view is a clinician interface view (see: paragraph [0042] where the interface view is a clinician’s interface view).
The motivations to combine the above-mentioned references are discussed in the rejection of claim 13, and incorporated herein.
As per claim 15, Harder et al., Abou-Hawili et al., and Shu et al. in combination teaches the medium of claim 13, see discussion of claim 13. Abou-Hawili et al. further teaches wherein to configure the first instance of the graphical user interface for the role comprises changing at least one of a feature or display of the first instance of the graphical user interface (see: paragraph [0040] where there is a change in the display based on the role, where different data is being provided to an engine to determine what is to be displayed on the display).
The motivations to combine the above-mentioned references are discussed in the rejection of claim 13, and incorporated herein.
As per claim 19, Harder et al. teaches a method comprising:
--wherein the clinical trial design application is structured to depict a configuration for a clinical trial design analysis flow, wherein the clinical trial design analysis flow comprises at least one clinical trial simulation model utilized by at least one clinical trial design simulation engine structured to simulate one or more clinical trial designs; (see: FIG. 2 and paragraph [0052] where there is an interface which depicts a configuration for a clinical trial design analysis flow. This depiction comprises a design simulation engine which simulated the design in the form of a flow)
--generating first interface data, wherein the first interface data is at least in part generated utilizing at least one simulation parameter of the at least one clinical trial simulation model; (see: FIG. 14 and paragraph [0066] where there is at least one clinical trial design simulation engine that generate a first result (predictive analytics) using at least one simulation parameter of a model (clinical trial metrics in the dashboard are part of a model))
--transmitting the first interface data; (see: FIG. 14 and paragraph [0066] where there is display of predictive analytics (a first result of a design simulation engine simulating the design) associated with the clinical trial metrics in the dashboard. A first interface data is being transmitted to the users which are viewing it)
--interpreting a second command value to adjust the clinical trial design analysis flow, wherein the second commend value is related to the at least one simulation parameter; (see: paragraph [0061] where the clinical plan schema may be edited. Also see: paragraphs [0057], [0067], and [0076] where an editor is opened when a node is selected. The editor is for inputting design parameters. A user input (second command value) is being received here on the interface which it is inputted in to adjust the plan (flow), and the input (second command) is related to the at least one simulation parameter (what is being inputted))
--generating, in response to the second command value, second interface data structured to display an adjustment to the clinical trial design analysis flow across the plurality of instances of the clinical trial design application in real-time; (see: paragraph [0061] where the clinical plan schema may be edited. Also see: paragraph [0040] where the graphic representations may be updated automatically and dynamically such that any user in any location may access and view the updated graphic representation. The adjustment to the schema is being shown (such as FIG. 2) across a plurality of instances of the interface in real-time in response to the updated user input. Second interface data (the graphical representation of the updated schema) is being generated upon editing the schema)
--transmitting the second interface data; (see: paragraph [0061] where the clinical plan schema may be edited. Also see: paragraph [0040] where the graphic representations may be updated automatically and dynamically such that any user in any location may access and view the updated graphic representation. The adjustment to the schema is being shown (such as FIG. 2) across a plurality of instances of the interface in real-time in response to the updated user input. The edit is being transmitted to the system in real-time for all users to see)
--generating third interface data structured to display, on each of the plurality of instances of the clinical trial design application, a second result of the at least one clinical trial design simulation engine based at least in part on the adjusted clinical trial design analysis flow; (see: FIG. 14 and paragraph [0066] where there is display of predictive analytics (a result of a design simulation engine simulating the design) associated with the clinical trial metrics in the dashboard. Also see: paragraph [0061] where the clinical plan schema may be edited. Also see: paragraph [0040] where the graphic representations may be updated automatically and dynamically such that any user in any location may access and view the updated graphic representation. Thus, an update to the schema will cause an updated to the predictive analytics to be shown, a second result (updated predictive analytics) is being displayed on each instance for each user based on the adjusted analysis flow (updates to the schema). This result is being generated before being sent) and
--transmitting the third interface data (see: FIG. 14 and paragraph [0066] where there is display of predictive analytics (a result of a design simulation engine simulating the design) associated with the clinical trial metrics in the dashboard. Also see: paragraph [0061] where the clinical plan schema may be edited. Also see: paragraph [0040] where the graphic representations may be updated automatically and dynamically such that any user in any location may access and view the updated graphic representation. Thus, an update to the schema will cause an updated to the predictive analytics to be shown, a second result (updated predictive analytics) is being displayed on each instance for each user based on the adjusted analysis flow (updates to the schema). This result is being sent to the devices of the users viewing it).
Harder et al. may not further, specifically teach:
1) --interpreting a first command value to generate an interface view for a first instance of a plurality of instances of a clinical trial design application;
2) --generating, in response to the first command value, first interface data structured to display the interface view on an electronic display, wherein the interface view is adapted to a trial development team clinician;
3) --wherein the at least one simulation parameter is based at least in part on an expertise of the trial development team clinician; and
4) --wherein each of the plurality of instances of the clinical trial design application is configured for a different role.
Abou-Hawili et al. teaches:
1) --interpreting a first command value to generate an interface view for a first instance of a plurality of instances of a clinical trial design application; (see: FIG. 4 where a user is logging onto their first interface view. A login command is being interpreted here to generate a particular screen for the user. The design application being one for clinical trial design was already taught in the Harder et al. reference)
2) --generating, in response to the first command value, first interface data structured to display the interface view on an electronic display, (see: paragraph [0009] where a role-based interface is being generated. Also see: paragraph [0041] where there are different interface views based on the roles of the user. The first instance/view is being configured when a clinician logs in. There are a plurality of views/instances here depending on the role of a user) wherein the interface view is adapted to a trial development team clinician; (see: paragraph [0042] where there is a role-based interface which is received and displayed to the caregiver. The interface here is based on the role of the user (clinician). The user relating to a trial development team clinician was already taught in the Harder et al. reference at paragraph [0038]) and
4) --wherein each of the plurality of instances of the clinical trial design application is configured for a different role (see: paragraph [0041] where there are views based on roles. Thus, each of the instances/views are for different roles as they are based on these roles. The design application being one for clinical trial design was already taught in the Harder et al. reference).
One of ordinary skill before the effective filing date of the claimed invention would have found it obvious to 1) interpret a first command value to generate an interface view for a first instance of a plurality of instances of a clinical trial design application, 2) generating, in response to the first command value, first interface data structured to display the interface view on an electronic display, wherein the interface view is adapted to a trial development team clinician, and have 4) wherein each of the plurality of instances of the clinical trial design application is configured for a different role as taught by Abou-Hawili et al. in the method as taught by Harder et al. with the motivation(s) of improving care planning workflow and coordination/collaboration (see: paragraph [0004] of Abou-Hawili et al.).
Shu et al. teaches:
3) --wherein the at least one simulation parameter is based at least in part on an expertise of the trial development team clinician (see: paragraph [0009] where there is a simulation using at least one parameter based in part on the expertise of the individual).
One of ordinary skill before the effective filing date of the claimed invention would have found it obvious to have 3) wherein the at least one simulation parameter is based at least in part on an expertise of the trial development team clinician as taught by Shu et al. in the method as taught by Harder et al. and Abou-Hawili et al. in combination with the motivation(s) of optimizing one or more parameters of a facility (see: paragraph [0001] of Shu et al.).
As per claim 20, Harder et al., Abou-Hawili et al., and Shu et al. in combination teaches the method of claim 19, see discussion of claim 19. Abou-Hawili et al. further teaches:
--interpreting the first interface data; (see: paragraph [0042] where the interface view is being received from the editor engine and then it is being displayed on a display. The interface data from the editor engine is therefore being interpreted by the display for displaying the interface) and
--displaying based at least in part on the first interface data, the interface view on the electronic display (see: 1808 of FIG. 18 and paragraph [0042] where an interface is generated on a display based on the data which is being received by it (the interface data including the interface view)).
The motivations to combine the above-mentioned references are discussed in the rejection of claim 19, and incorporated herein.
As per claim 21, Harder et al., Abou-Hawili et al., and Shu et al. in combination teaches the method of claim 20, see discussion of claim 20. Harder et al. further teaches wherein:
--the interface view depicts:
--the one or more clinical trial designs, (see: FIG. 22 where there are one or more clinical trial designs)
--a plurality of scenarios corresponding to the one or more clinical trial designs, (see: FIG. 22 where there are plurality of scenarios for the trial) and
--a result for each of the one or more clinical trial designs under each of the plurality of scenarios (see: FIG. 22 where there are results for each scenario).
Claims 4-5, 10-11, and 16-17 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. 2016/0239619 to Harder et al. in view of U.S. 2016/0239619 to Abou-Hawili et al. and further in view of U.S. 2016/0253463 to Shu et al. as applied to claims 1, 7, 13, and 19, and further in view of U.S. 2022/0283784 to Degen et al.
As per claim 4, Harder et al., Abou-Hawili et al., and Shu et al. in combination teaches the method of claim 1, see discussion of claim 1. The combination may not further, specifically teach wherein the interface view comprises a selectable list of scenarios and a list of designs with performance metrics for a selected scenario.
Degen et al. teaches:
--wherein the interface view comprises a selectable list of scenarios and a list of designs with performance metrics for a selected scenario (see: 301 of FIG. 3 and paragraph [0025] where there is a list of selectable scenarios in the form of sliders which define the scenario. There is also a list of designs with performance metrics (332, 334, and 335) which are provided in response to a selected parameter/scenario at 331).
One of ordinary skill before the effective filing date of the claimed invention would have found it obvious to have wherein the interface view comprises a selectable list of scenarios and a list of designs with performance metrics for a selected scenario as taught by Degen et al. in the method as taught by Harder et al., Abou-Hawili et al., and Shu et al. in combination with the motivation(s) of accelerating and optimizing simulation setup (see: paragraph [0003] of Degen et al.).
As per claim 5, Harder et al., Abou-Hawili et al., Shu et al., and Degen et al. in combination teaches the method of claim 4, see discussion of claim 4. Abou-Hawili et al. teaches an interface as a card interface (see: FIG. 8 where there is an interface which is displayed cards 804, 806, and 808).
The motivations to combine the above-mentioned references are discussed in the rejection of claim 1, and incorporated herein.
Degen et al. further teaches wherein the selectable list of scenarios is presented as an interface (see: 301 of FIG. 3 and paragraph [0025] where there is a list of selectable scenarios in the form of sliders which define the scenario).
The motivations to combine the above-mentioned references are discussed in the rejection of claim 4, and incorporated herein.
As per claim 10, Harder et al., Abou-Hawili et al., and Shu et al. in combination teaches the apparatus of claim 7, see discussion of claim 7. The combination may not further, specifically teach wherein the interface view comprises a selectable list of scenarios and a list of designs with performance metrics for a selected scenario.
Degen et al. teaches:
--wherein the interface view comprises a selectable list of scenarios and a list of designs with performance metrics for a selected scenario (see: 301 of FIG. 3 and paragraph [0025] where there is a list of selectable scenarios in the form of sliders which define the scenario. There is also a list of designs with performance metrics (332, 334, and 335) which are provided in response to a selected parameter/scenario at 331).
One of ordinary skill before the effective filing date of the claimed invention would have found it obvious to have wherein the interface view comprises a selectable list of scenarios and a list of designs with performance metrics for a selected scenario as taught by Degen et al. in the apparatus as taught by Harder et al., Abou-Hawili et al., and Shu et al. in combination with the motivation(s) of accelerating and optimizing simulation setup (see: paragraph [0003] of Degen et al.).
As per claim 11, Harder et al., Abou-Hawili et al., Shu et al., and Degen et al. in combination teaches the apparatus of claim 10, see discussion of claim 10. Abou-Hawili et al. teaches an interface as a card interface (see: FIG. 8 where there is an interface which is displayed cards 804, 806, and 808).
The motivations to combine the above-mentioned references are discussed in the rejection of claim 7, and incorporated herein.
Degen et al. further teaches wherein the selectable list of scenarios is presented as an interface (see: 301 of FIG. 3 and paragraph [0025] where there is a list of selectable scenarios in the form of sliders which define the scenario.).
The motivations to combine the above-mentioned references are discussed in the rejection of claim 10, and incorporated herein.
As per claim 16, Harder et al., Abou-Hawili et al., and Shu et al. in combination teaches the medium of claim 13, see discussion of claim 13. The combination may not further, specifically teach wherein the interface view comprises a selectable list of scenarios and a list of designs with performance metrics for a selected scenario.
Degen et al. teaches:
--wherein the interface view comprises a selectable list of scenarios and a list of designs with performance metrics for a selected scenario (see: 301 of FIG. 3 and paragraph [0025] where there is a list of selectable scenarios in the form of sliders which define the scenario. There is also a list of designs with performance metrics (332, 334, and 335) which are provided in response to a selected parameter/scenario at 331).
One of ordinary skill before the effective filing date of the claimed invention would have found it obvious to have wherein the interface view comprises a selectable list of scenarios and a list of designs with performance metrics for a selected scenario as taught by Degen et al. in the medium as taught by Harder et al., Abou-Hawili et al., and Shu et al. in combination with the motivation(s) of accelerating and optimizing simulation setup (see: paragraph [0003] of Degen et al.).
As per claim 17, Harder et al., Abou-Hawili et al., Shu et al., and Degen et al. in combination teaches the medium of claim 16, see discussion of claim 16. Abou-Hawili et al. teaches an interface as a card interface (see: FIG. 8 where there is an interface which is displayed cards 804, 806, and 808).
The motivations to combine the above-mentioned references are discussed in the rejection of claim 13, and incorporated herein.
Degen et al. further teaches wherein the selectable list of scenarios is presented as an interface (see: 301 of FIG. 3 and paragraph [0025] where there is a list of selectable scenarios in the form of sliders which define the scenario).
The motivations to combine the above-mentioned references are discussed in the rejection of claim 16, and incorporated herein.
Claims 6, 12, and 18 are rejected under 35 U.S.C. 103 as being unpatentable over U.S. 2016/0239619 to Harder et al. in view of U.S. 2016/0239619 to Abou-Hawili et al. further in view of U.S. 2016/0253463 to Shu et al. and further in view of U.S. 2022/0283784 to Degen et al. as applied to claims 4, 10, and 16, and further in view of U.S. 2020/0411141 to Foster et al.
As per claim 6, Harder et al., Abou-Hawili et al., Shu et al., and Degen et al. in combination teaches the method of claim 4, see discussion of claim 4. The combination may not further, specifically teach wherein the selectable list of scenarios includes a description of each scenario and wherein the description is automatically generated from configuration data associated with each scenario.
Foster et al. teaches:
--wherein the selectable list of scenarios includes a description of each scenario and wherein the description is automatically generated from configuration data associated with each scenario (see: paragraph [0077] where there is a brief description which is being displayed with a list of current case studies (scenarios). The description data is automatically shown for each case study).
One of ordinary skill before the effective filing date of the claimed invention would have found it obvious to have wherein the selectable list of scenarios includes a description of each scenario and wherein the description is automatically generated from configuration data associated with each scenario as taught by Foster et al. in the method as taught by Harder et al., Abou-Hawili et al., Shu et al., and Degen et al. in combination with the motivation(s) of improving data management and analytics (see: paragraph [0005] of Foster et al.).
As per claim 12, Harder et al., Abou-Hawili et al., Shu et al., and Degen et al. in combination teaches the apparatus of claim 10, see discussion of claim 10. The combination may not further, specifically teach wherein the selectable list of scenarios includes a description of each scenario and wherein the description is automatically generated from configuration data associated with each scenario.
Foster et al. teaches:
--wherein the selectable list of scenarios includes a description of each scenario and wherein the description is automatically generated from configuration data associated with each scenario (see: paragraph [0077] where there is a brief description which is being displayed with a list of current case studies (scenarios). The description data is automatically shown for each case study).
One of ordinary skill before the effective filing date of the claimed invention would have found it obvious to have wherein the selectable list of scenarios includes a description of each scenario and wherein the description is automatically generated from configuration data associated with each scenario as taught by Foster et al. in the apparatus as taught by Harder et al., Abou-Hawili et al., Shu et al., and Degen et al. in combination with the motivation(s) of improving data management and analytics (see: paragraph [0005] of Foster et al.).
As per claim 18, Harder et al., Abou-Hawili et al., Shu et al., and Degen et al. in combination teaches the medium of claim 16, see discussion of claim 16. The combination may not further, specifically teach wherein the selectable list of scenarios includes a description of each scenario and wherein the description is automatically generated from configuration data associated with each scenario.
Foster et al. teaches:
--wherein the selectable list of scenarios includes a description of each scenario and wherein the description is automatically generated from configuration data associated with each scenario (see: paragraph [0077] where there is a brief description which is being displayed with a list of current case studies (scenarios). The description data is automatically shown for each case study).
One of ordinary skill before the effective filing date of the claimed invention would have found it obvious to have wherein the selectable list of scenarios includes a description of each scenario and wherein the description is automatically generated from configuration data associated with each scenario as taught by Foster et al. in the medium as taught by Harder et al., Abou-Hawili et al., Shu et al., and Degen et al. in combination with the motivation(s) of improving data management and analytics (see: paragraph [0005] of Foster et al.).
Conclusion
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to Steven G.S. Sanghera whose telephone number is (571)272-6873. The examiner can normally be reached M-F 7:30-5:00 (alternating Fri).
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, Shahid Merchant can be reached on 571-270-1360. 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.
/STEVEN G.S. SANGHERA/Primary Examiner, Art Unit 3684