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 .
Status of the Claims
Claims 1-21 are currently pending.
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 February 20, 2026 has been entered.
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.
Step 1
Claims 1-21 are within the four statutory categories. Claims 1-21 are drawn to a system for tracking facility-issued dosages, which is within the four statutory categories (i.e. machine).
Prong 1 of Step 2A
Claim 1, which is representative of the inventive concept, recites: A system for providing a user selective access to a data analytics tool for processing a multidimensional data set corresponding to dose order records for use in providing data analytics to the user regarding a subset of the dose order records of the multidimensional data set, the system comprising:
a central server that is in operative communication with a plurality of local servers, each of the local servers being disposed at a corresponding respective facility that prepares doses corresponding to dose orders for administration to a patient, wherein the central server receives information regarding dose order records corresponding to the dose orders from the local servers;
a database at the central server that stores a data structure comprising a multidimensional data set including a plurality of dose order records received from the plurality of local servers, wherein each of the plurality of dose order records of the multidimensional data set comprises at least one indication of the facility from which the dose order record was received;
a server interface in operative communication with a user workstation, the server interface configured to receive, from the user workstation, user information including at least a customer ID corresponding to a given facility from which a user is accessing the server interface;
a data analytics tool in operative communication with the database for access to the multidimensional data set stored in the database to create a dynamically generated report regarding a subset of the multidimensional data set corresponding to the given facility based on the received user information indicative of the given facility, wherein the user information corresponding to the given facility from which the user is accessing the data analytics tool via the server interface restricts access to data other than the subset of the multidimensional data set by excluding the data other than the subset of the multidimensional data set that corresponds to other facilities for which data exclusion flags have been set for not matching the user information indicative of the given facility; and
a user interface for presenting to the user workstation the dynamically generated report regarding the subset of the multidimensional data set corresponding to the given facility.
The underlined limitations as shown above, given the broadest reasonable interpretation, cover the abstract idea of a certain method of organizing human activity because they recite managing personal behavior or relationships or interactions between people (i.e. social activities, teaching, and following rules or instructions – in this case, the steps of receiving dose order records, storing the multidimensional data set including the dose order records, receiving a customer ID corresponding to a facility, accessing only a subset of the multidimensional data set, creating the report from the accessed subset of the multidimensional data set which excludes data for other facilities, and presenting the report to a user recites at least filtering content and/or following rules or instructions to process data, generate a report from the processed data, and provide a user with the report), e.g. see MPEP 2106.04(a)(2). Any limitations not identified above as part of the abstract idea are deemed “additional elements,” and will be discussed in further detail below.
Dependent Claims 2-21 include other limitations, for example Claims 2-5 and 9-11 recite limitations defining the multidimensional data set via data cube class definitions, Claims 6-8 recite transcribing data from the dose order records into the multidimensional data set and types of dose order records, Claim 12 recites requiring a user to provide login authentication information to access the system, Claims 13-14 recite utilizing an authentication token to determine authorization to access data for a user, Claims 15-16 recite defining user roles, Claims 17-18 recite logging user activity, Claim 19 recites recording an identity associated with the report, Claim 20 recites recording whether or not the report includes protected health information (PHI), and Claim 21 recites data included in the multidimensional data set, but these only serve to further narrow the abstract idea, and a claim may not preempt abstract ideas, even if the judicial exception is narrow, e.g. see MPEP 2106.04, and/or do not further narrow the abstract idea and instead only recite additional elements, which will be further addressed below. Hence dependent Claims 2-21 are nonetheless directed towards fundamentally the same abstract idea as independent Claim 1.
Hence Claims 1-21 are directed towards the aforementioned abstract idea.
Prong 2 of Step 2A
Claims 1-21 are not integrated into a practical application because the additional elements (i.e. the non-underlined limitations above – in this case, the central server, the local servers, the database, the server interface, the user workstation, the data analytics tool, the user interface, and the step of presenting the report to the user) amount to no more than limitations which:
amount to mere instructions to apply an exception – for example, the recitation of the servers, the database, the interfaces, the user workstation, and the data analytics tool, which amounts to merely invoking computers as tools to perform the abstract idea, e.g. see pg. 7, lines 15-30, pg. 8, line 22 through pg. 9, line 19, and pg. 11, lines 7-18, of the as-filed Specification, and see MPEP 2106.05(f);
generally link the abstract idea to a particular technological environment or field of use – for example, the language claiming that the data processed is dose order records, which amounts to limiting the abstract idea to the field of healthcare, e.g. see MPEP 2106.05(h); and/or
add insignificant extra-solution activity to the abstract idea – for example, the recitation of presenting the generated report, which amounts to an insignificant application, e.g. see MPEP 2106.05(g).
Additionally, dependent Claims 2-21 include other limitations, but these limitations also amount to no more than mere instructions to apply an exception (e.g. the login operations and the authentication token regulating access recited in dependent Claims 12-14), generally linking the abstract idea to a particular technological environment or field of use (e.g. the specific types of data recited in dependent Claims 2-11 and 15-21), and/or do not include any additional elements beyond those already recited in independent Claim 1, and hence also do not integrate the aforementioned abstract idea into a practical application.
Hence Claims 1-21 do not include additional elements that integrate the judicial exception into a practical application.
Step 2B
Claims 1-21 do not include additional elements that are sufficient to amount to “significantly more” than the judicial exception because the additional elements (i.e. the non-underlined limitations above – in this case, the central server, the local servers, the database, the server interface, the user workstation, the data analytics tool, the user interface, and the step of presenting the report to the user), as stated above, are directed towards no more than limitations that amount to mere instructions to apply the exception, generally link the abstract idea to a particular technological environment or field of use, and/or add insignificant extra-solution activity to the abstract idea, wherein the additional elements comprise limitations which:
amount to elements that have been recognized as well-understood, routine, and conventional activity in particular fields, as demonstrated by:
The present Specification expressly disclosing that the structural additional elements are well-understood, routine, and conventional in nature:
Pg. 7, lines 15-30, pg. 8, line 22 through pg. 9, line 19, and pg. 11, lines 7-18 of the as-filed Specification discloses that the additional elements (i.e. the structural limitations of the central server, the local servers, the database, the server interface, the user workstation, the data analytics tool, and the user interface) comprise a plurality of different types of generic computing systems;
Relevant court decisions: The functional limitations interpreted as additional elements are analogized to the following examples of court decisions demonstrating well-understood, routine and conventional activities, e.g. see MPEP 2106.05(d)(II):
Receiving or transmitting data over a network, e.g. see Intellectual Ventures v. Symantec – similarly, the current invention receives dose order records, and transmits the dose order records to the central server over a network, for example the Internet, e.g. see pg. 11, lines 7-18 of the as-filed Specification;
Electronic recordkeeping, e.g. see Alice Corp v. CLS Bank – similarly, the current invention merely recites the storing of dose order records and the multidimensional data set on the database at the central server;
Storing and retrieving information in memory, e.g. see Versata Dev. Group, Inc. v. SAP Am., Inc. – similarly, the current invention recites storing dose order records and multidimensional data set in the database at the central server, and retrieving the multidimensional data set from storage in order to generate and display the dynamically generated report;
Dependent Claims 2-21 include other limitations, but none of these limitations are deemed significantly more than the abstract idea because the additional elements recited in the aforementioned dependent claims similarly amount to mere instructions to apply the exception (e.g. the login operations and the authentication token regulating access recited in dependent Claims 12-14), generally linking the abstract idea to a particular technological environment or field of use (e.g. the specific types of data recited in dependent Claims 2-11 and 15-21), receiving or transmitting data over a network (e.g. the transmission of the authentication information recited in dependent Claims 12-13), and/or the limitations recited by the dependent claims do not recite any additional elements not already recited in independent Claim 1, and hence do not amount to “significantly more” than the abstract idea.
Hence, Claims 1-21 do not include any additional elements that amount to “significantly more” than the judicial exception.
Thus, taken alone, the additional elements do not amount to significantly more than the abstract idea identified above. Furthermore, looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually, and there is no indication that the combination of elements improves the functioning of a computer or improves any other technology, and their collective functions merely provide conventional computer implementation.
Therefore, whether taken individually or as an ordered combination, Claims 1-21 are nonetheless 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 (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claim 1 is rejected under 35 U.S.C. 103 as being unpatentable over Tribble (US 2010/0094653) in view of Miller (US 2013/0310726), further in view of Imanaka (US 2002/0026384).
Regarding Claim 1, Tribble teaches the following: A system for providing a user selective access to a data analytics tool for processing a multidimensional data set corresponding to dose order records for use in providing data analytics to the user regarding a subset of the dose order records of the multidimensional data set, the system comprising:
a central server that is in operative communication with a plurality of local servers, each of the local servers being disposed at a corresponding respective facility that prepares doses corresponding to dose orders for administration to a patient (The system includes hospital or pharmacy (i.e. facilities that prepare doses) terminals that receive one or more medication orders, and transmit the medication orders to local servers, e.g. see Tribble [0034]-[0036].), wherein the central server receives information regarding dose order records corresponding to the dose orders from the local servers (The medication orders are sent from the hospital or pharmacy terminals to the local servers, e.g. see Tribble [0036], and further transmits the orders from the local servers to a central server, e.g. see Tribble [0099].);
a database at the central server that stores a data structure comprising a multidimensional data set including a plurality of dose order records received from the plurality of local servers (The central server includes an archive of data from each entity, e.g. see Tribble [0116], wherein the stored data includes a plurality of data elements (i.e. a multidimensional data set) such as a particular dose, a particular hospital, how many orders are generated each day, and/or who approved the orders, e.g. see Tribble [0125].), wherein each of the plurality of dose order records of the multidimensional data set comprises at least one indication of the facility from which the dose order record was received (The data stored at the archive of the central server includes dose related information including what hospital generated the dose (i.e. an indication of the facility from which the dose order was received), e.g. see Tribble [0125].);
a server interface in operative communication with a user workstation (The system includes computer terminals (i.e. user workstations) for hospitals and pharmacies that communicate with local servers and the central server, e.g. see Tribble [0034]-[0036], [0039], and [0099].), the server interface configured to receive, from the user workstation, user information (The system receives medication order streams from the hospital and/or pharmacy terminals, wherein the medication order streams contain a list of medication doses to prepare, and further include identifying data that identifies the source of the data stream which ensures that the medication dose is prepared by an authorized prescribing entity (i.e. user information), e.g. see Tribble [0040]-[0043].);
a data analytics tool in operative communication with the database for access to the multidimensional data set stored in the database to create a dynamically generated report regarding a subset of the multidimensional data set corresponding to the given facility based on the received user information indicative of the given facility (The central server generates reports regarding data received from the hospitals and pharmacies, for example identifying various metrics (i.e. multiple dimensions) such as a number of different drugs and a number of errors in producing a given dose, e.g. see Tribble [0127]-[0128].); and
a user interface for presenting to the user workstation the dynamically generated report regarding the subset of the multidimensional data set corresponding to the given facility (The reports are presented to customers, wherein the customers include an administrator for a hospital or pharmacy, e.g. see Tribble [0124]-[0125], and [0127]-[0128].).
But Tribble does not teach and Miller teaches the following:
wherein the user information includes at least a customer ID corresponding to a given facility from which a user is accessing the server interface (The system receives a username and password (i.e. customer ID) in order to access a website or portal containing treatment related data, e.g. see Miller [0157] and [0261]-[0263], Figs. 22-24.); and
wherein the user information corresponding to the given facility from which the user is accessing the data analytics tool via the server interface restricts access to data other than the subset of the multidimensional data set (The system restricts access to data based on the received username and password, wherein the data displayed may be for a particular clinic, e.g. see Miller [0157] and [0261]-[0263], Figs. 22-24.).
Furthermore, before the effective filing date, it would have been obvious to one ordinarily skilled in the art of healthcare to modify Tribble to incorporate the customer ID and restrict the data accessed based on the customer ID as taught by Miller in order to enhance the security of the system by ensuring that the user accessing the functions of the system is authenticated, e.g. see Miller [0154] and [0195].
But the combination of Tribble and Miller does not teach and Imanaka teaches the following:
wherein the restricting of access to data other than the subset of the multidimensional data set comprises excluding the data other than the subset of the multidimensional data set that corresponds to other facilities for which data exclusion flags have been set for not matching the user information indicative of the given facility (The system enables a customer to request the retrieval of (i.e. access to) a stored object or information by providing a customer identifier and an object/information identifier (i.e. data exclusion flags), e.g. see Imanaka [0297], wherein the customer identifier corresponds to a hospital (i.e. a facility), e.g. see Imanaka Figs. 4-5, and wherein the system retrieves the requested object/information in response to matching the customer identifier and the object/information identifier, e.g. see Imanaka [0301]. Furthermore, the retrieved data is only the records associated with the customer, for example Hospital A, e.g. see Imanaka [0406], Figs. 4-5. That is, the customer/facility identifier and the object/information identifier represent data flags that determine which data/information to exclude from/include in the retrieval operation.).
Furthermore, it would have been obvious to one ordinarily skilled in the art of healthcare to modify the combination of Tribble and Miller to incorporate excluding data for other facilities and only providing data for the specified facility as taught by Imanaka in order to ensure that only authenticated users have easy access to the specified data, e.g. see Imanaka [0052] and [0396].
Claims 2-5, 9, and 21 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Tribble, Miller, and Imanaka in view of Mansour (US 2009/0024414).
Regarding Claim 2, the combination of Tribble, Miller, and Imanaka teaches the limitations of Claim 1, but does not teach and Mansour teaches the following:
The system of claim 1, wherein the data analytics tool comprises a plurality of data cube class definitions applicable to the multidimensional data set to create the dynamically generated report (The system arranges the data stored in an analytics database (i.e. the multidimensional data set) into a plurality of multidimensional OLAP data cubes, wherein the OLAP cubs are defined by various data tables (i.e. data cube class definitions) that further define the generated report, e.g. see Mansour [0065], [0072], [0096], [0131], and [0168].).
Furthermore, before the effective filing date, it would have been obvious to one ordinarily skilled in the art of healthcare to modify the combination of Tribble, Miller, and Imanaka to incorporate the class definitions in generating the report as taught by Mansour in order to optimize the data for business intelligence reporting tools, e.g. see Mansour [0012].
Regarding Claim 3, the combination of Tribble, Miller, Imanaka, and Mansour teaches the limitations of Claim 2, and Mansour further teaches the following:
The system of claim 2, wherein the plurality of data cube class definitions comprises a base cube class definition from which all others of the plurality of data cube class definitions depend (A plurality of the OLAP cubes may depend from a single data table, for example the SANVisit fact table is used to construct the “Visit” and “Visit patients” OLAP cubes, e.g. see Mansour [0096].).
Furthermore, before the effective filing date, it would have been obvious to one ordinarily skilled in the art of healthcare to modify the combination of Tribble, Miller, and Imanaka to incorporate the base cube class definition as taught by Mansour in order to optimize the data for business intelligence reporting tools, e.g. see Mansour [0012].
Regarding Claim 4, the combination of Tribble, Miller, Imanaka, and Mansour teaches the limitations of Claim 3, and Tribble further teaches the following:
The system of claim 3, wherein the base cube class definition includes at least one data dimension related to the information indicative of the given facility (The system tracks the source of the prescription including the particular hospital or prescriber (i.e. data indicative of the given facility), e.g. see Tribble [0043] and [0125].).
Regarding Claim 5, the combination of Tribble, Miller, Imanaka, and Mansour teaches the limitations of Claim 4, and Mansour further teaches the following:
The system of claim 4, wherein the data analytics tool is further operative to perform at least one data transformation operation on the subset of the multidimensional data set, wherein the at least one data transformation operation is defined in the base cube class definition (The data tables include metadata tables that are used in the extraction of the subset of data, e.g. see paragraphs [0065] and [0084], wherein the metadata tables include executing two SQL Server Data Transformation Services (DTS) scripts to refresh the dimensions and the data cubes, e.g. see Mansour paragraph [0125].).
Furthermore, before the effective filing date, it would have been obvious to one ordinarily skilled in the art of healthcare to modify the combination of Tribble, Miller, and Imanaka to incorporate the data transformation operation as taught by Mansour in order to optimize the data for business intelligence reporting tools, e.g. see Mansour [0012].
Regarding Claim 9, the combination of Tribble, Miller, Imanaka, and Mansour teaches the limitations of Claim 5, and Mansour further teaches the following:
The system of claim 5, wherein the central server is further operative to invoke another of the data cube class definitions depending from the base cube class definition for application to the subset of the multidimensional data set corresponding to the given facility to create the dynamically generated report regarding the subset of the multidimensional data set (The system invokes the data cubes to extract data from the central database (i.e. a subset of the multidimensional data set), wherein the extracted data is used to create a report, e.g. see Mansour [0087], wherein the report may include data from a plurality of OLAP cubes, for example patient data and visit data, e.g. see Mansour [0096], Fig. 11.).
Furthermore, before the effective filing date, it would have been obvious to one ordinarily skilled in the art of healthcare to modify the combination of Tribble, Miller, and Imanaka to incorporate the data transformation operation as taught by Mansour in order to optimize the data for business intelligence reporting tools, e.g. see Mansour [0012].
Regarding Claim 21, the combination of Tribble, Miller, and Imanaka teaches the limitations of Claim 1, and Tribble further teaches the following:
The system of claim 1, wherein the multidimensional data set comprises data regarding an identity of doses corresponding to the plurality of dose order records (The data includes medication orders including which dose and an identification of the medication (i.e. the identity of the doses of medication), e.g. see Tribble [0034], [0056], [0072], and [0125]), data regarding the steps of preparing the doses (The data includes the prescribing doctor (i.e. the first step of preparing the dose is prescribing the dose), e.g. see Tribble [0040].), data regarding the timing of doses (The data includes a date the prescription was entered (i.e. a timing), e.g. see Tribble [0040].), data regarding drug usage (The data includes a total amount of work orders for each drug, e.g. see Tribble [0056].), data regarding drug therapies administered (The data includes an identification of the drugs, e.g. see Tribble [0034], [0056], [0072], and [0125].), data regarding errors that occurred during dose preparation (The data includes a number of errors in producing a given dose, e.g. see Tribble [0127].), and data regarding product waste (The data includes a number of re-dos (i.e. waste) for a given dose, e.g. see Tribble [0127].).
However, the combination of Tribble, Miller, and Imanaka does not teach but Mansour teaches the following:
wherein the multidimensional data set further comprises data regarding drug interactions (The system processes data regarding drug interactions, e.g. see Mansour paragraph [0096].), and data corresponding to alerts at a pharmacy workflow management application (The system processes data regarding alert data, e.g. see Mansour paragraphs [0071] and [0096].).
Furthermore, before the effective filing date, it would have been obvious to one ordinarily skilled in the art of healthcare to modify the combination of Tribble, Miller, and Imanaka to incorporate the types of data as taught by Mansour in order to optimize the data for business intelligence reporting tools, e.g. see Mansour [0012].
Claims 6-7 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Tribble, Miller, Imanaka, and Mansour in view of Suwalski (US 2007/0100662).
Regarding Claim 6, the combination of Tribble, Miller, Imanaka, and Mansour teaches the limitations of Claim 5, but does not teach and Suwalski teaches the following:
The system of claim 5, wherein the at least one data transformation operation comprises automatically transcribing a first data field for each given dose order record in the subset with a second data field of the respective ones of the dose order records of the subset (The system automatically populates (i.e. transcribe) data into a first data field utilizing data requested from another data field (i.e. a second data field), e.g. see Suwalski [0078]-[0079].).
Furthermore, before the effective filing date, it would have been obvious to one ordinarily skilled in the art of healthcare to modify the combination of Tribble, Miller, Imanaka, and Mansour to incorporate automatically populating data fields from data extracted from other data fields as taught by Suwalski in order to automatically track the processed data and errors, e.g. see Suwalski [0004]-[0007].
Regarding Claim 7, the combination of Tribble, Miller, Imanaka, Mansour, and Suwalski teaches the limitations of Claim 6, and Mansour further teaches the following:
The system of claim 6, wherein the at least one data transformation operation is applied only to a given type of the dose order records (The SQL Server Data Transformation Services (DTS) scripts are only applied to data cubes that need to be updated (i.e. a given type of dose order record), e.g. see Mansour [0125].).
Furthermore, before the effective filing date, it would have been obvious to one ordinarily skilled in the art of healthcare to modify the combination of Tribble, Miller, Imanaka, and Mansour to incorporate the data transformation operation as taught by Mansour in order to optimize the data for business intelligence reporting tools, e.g. see Mansour [0012].
Claim 8 rejected under 35 U.S.C. 103 as being unpatentable over the combination of Tribble, Miller, Imanaka, Mansour, and Suwalski in view of Carosso (US 2007/0100660).
Regarding Claim 8, the combination of Tribble, Miller, Imanaka, Mansour, and Suwalski teaches the limitations of Claim 7, and Mansour further teaches the following:
The system of claim 7, wherein the first data field comprises a dose description field, and the second field comprises a drug name field for the given dose (The order information includes dose units (i.e. a dose description) and an identification of the prescription medications (i.e. drug name) ordered for the patient, e.g. see Mansour paragraphs [0060] and [0070].)
Furthermore, before the effective filing date, it would have been obvious to one ordinarily skilled in the art of healthcare to modify the combination of Tribble, Miller, Imanaka, and Suwalski to incorporate the data fields as taught by Mansour in order to optimize the data for business intelligence reporting tools, e.g. see Mansour [0012].
But the combination of Tribble, Miller, Imanaka, Mansour, and Suwalski does not teach and Carosso teaches the following:
wherein the given type of the dose order records include total parenteral nutrition (TPN) doses (The system tracks orders, wherein the orders may include a TPN order, e.g. see Carosso [0052],).
Furthermore, before the effective filing date, it would have been obvious to one ordinarily skilled in the art of healthcare to modify the combination of Tribble, Miller, Imanaka, Mansour, and Suwalski to incorporate the TPN order type as taught by Carosso in order to overcome inefficiencies and shortcomings of conventional order systems, e.g. see Carosso paragraphs [0008]-[0010].
Claims 10-11 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Tribble, Miller, Imanaka, and Mansour in view of Ramraj (US 2005/0065823).
Regarding Claim 10, the combination of Tribble, Miller, Imanaka, and Mansour teaches the limitations of Claim 9, but does not teach and Ramraj teaches the following:
The system of claim 9, wherein the plurality of data cube class definitions includes a parameter indicative of whether data cubes built using the data cube class definitions include protected health information (“PHI”) (The system generates an answer (i.e. parameter) to the determination of whether or not data contains protected health information (PHI), e.g. see Ramraj [0032]-[0034], Fig. 3.).
Furthermore, before the effective filing date, it would have been obvious to one ordinarily skilled in the art of healthcare to modify the combination of Tribble, Miller, Imanaka, and Mansour to incorporate generating the “yes” or “no” parameter regarding the presence of PHI as taught by Ramraj in order to comply with the requirements of the Health Insurance Portability and Accountability Act (HIPAA), e.g. see Ramraj paragraphs [0002]-[0004].
Regarding Claim 11, the combination of Tribble, Miller, Imanaka, Mansour, and Ramraj teaches the limitations of Claim 10, and Ramraj further teaches the following:
The system of claim 10, wherein the parameter is dynamically generated based on at least one dimension of the data cube class definition (The “yes” or “no” element (i.e. parameter) is generated in response to the query of “does the data include PHI?” (i.e. at least one dimension of the data cube class definition), e.g. see Ramraj [0032]-[0034], Fig. 3.).
Furthermore, before the effective filing date, it would have been obvious to one ordinarily skilled in the art of healthcare to modify the combination of Tribble, Miller, Imanaka, and Mansour to incorporate generating the “yes” or “no” parameter regarding the presence of PHI as taught by Ramraj in order to comply with the requirements of the Health Insurance Portability and Accountability Act (HIPAA), e.g. see Ramraj paragraphs [0002]-[0004].
Claims 12 and 15 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Tribble, Miller, and Imanaka in view of Sathe (US 2014/0067407).
Regarding Claim 12, the combination of Tribble, Miller, and Imanaka teaches the limitations of Claim 1, but does not teach and Sathe teaches the following:
The system of claim 1, wherein the user workstation is operative to receive login information from the user accessing the data analytics tool to initiate a user session, wherein the user workstation is operative to communicate with the central server to authenticate the user to the central server based on the login information received at the user workstation, and wherein the central server is operative to populate a session variable related to the user session based on authenticated user login information, the session variable comprising the user information indicative of the user workstation (The system receives login credentials (i.e. login information to authenticate the user) from a user to determine the access privileges (i.e. populate the session based on the user login information), e.g. see Sathe [0028]-[0029] and [0037]-[0038].).
Furthermore, before the effective filing date, it would have been obvious to one ordinarily skilled in the art of healthcare to modify the combination of Tribble, Miller, and Imanaka to incorporate the user login information as taught by Sathe in order to ensure that confidential data is not viewed by unauthenticated users, e.g. see Sathe paragraph [0029].
Regarding Claim 15, the combination of Tribble, Miller, Imanaka, and Sathe teaches the limitations of Claim 12, and Sathe further teaches the following:
The system of claim 12, wherein the session variable includes a role definition for the user generated based at least in part on the login information (The system receives login credentials (i.e. login information) from a user to determine the user role and access privileges, e.g. see paragraphs [0028]-[0029], [0031], and [0037]-[0038].).
Furthermore, before the effective filing date, it would have been obvious to one ordinarily skilled in the art of healthcare to modify the combination of Tribble, Miller, and Imanaka to incorporate the user login information as taught by Sathe in order to ensure that confidential data is not viewed by unauthenticated users, e.g. see Sathe paragraph [0029].
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over the combination of Tribble, Miller, Imanaka, and Sathe in view of Felsher (US 2002/0010679).
Regarding Claim 13, the combination of Tribble, Miller, Imanaka, and Sathe teaches the limitations of Claim 12, but does not teach and Felsher teaches the following:
The system of claim 12, wherein the data analytics tool further comprises a cryptographic service that is operative to receive a token from a user attempting to access the central server, wherein the token is at least partially based on the session variable populated by the central sever, and wherein the cryptographic service is operative to compare the token to available tokens at the central sever to determine if the user is to be granted access to the data analytics tool (The system receives a user entered RSASecurID code (i.e. a token), wherein a security server compares the user-provided code to a stored code to determine if the user should be authenticated (i.e. granted access), e.g. see Felsher [0342]-[0343] and [0354].).
Furthermore, before the effective filing date, it would have been obvious to one ordinarily skilled in the art of healthcare to modify the combination of Tribble, Miller, Imanaka, and Sathe to incorporate the RSASecurID code as taught by Felsher in order to ensure that confidential data is not viewed by unauthorized users, e.g. see Felsher [0342].
Claim 14 is rejected under 35 U.S.C. 103 as being unpatentable over the combination of Tribble, Miller, Imanaka, Sathe, and Felsher in view of Fee (US 2014/0325627).
Regarding Claim 14, the combination of Tribble, Miller, Imanaka, Sathe, and Felsher teaches the limitations of Claim 13, but does not teach and Fee teaches the following:
The system of claim 13, wherein upon matching the token to one of the available tokens, the token is issued to the user and the corresponding available token is removed from the central server (The system includes a server system comprising an authentication system including a database (i.e. a central server) that stores a plurality of authentication tokens, e.g. see Fee [0041]-[0042], and user devices that request access to data stored on the server system, e.g. see Fee [0024]. Furthermore, the server system utilizes the authentication tokens to determine that the user is authorized to access the requested data, provides the authentication tokens to the users, and further removes the authentication tokens from the server system, e.g. see Fee [0024], [0059]-[0063], and [0068].).
Furthermore, before the effective filing date, it would have been obvious to one ordinarily skilled in the art of data management to modify the combination of Tribble, Miller, Imanaka, Sathe, and Felsher to incorporate the removal of the authentication tokens from the server as taught by Fee in order to prevent unauthorized access to the server system, e.g. see Fee [0061] and [0068].
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over the combination of Tribble, Miller, Imanaka, and Sathe in view of Vivalda (US 8,719,217).
Regarding Claim 16, the combination of Tribble, Miller, Imanaka, and Sathe teaches the limitations of Claim 15, but does not teach and Vivalda teaches the following:
The system of claim 15, wherein the role definition includes indications as to an ability of the user in relation to viewing reports, editing reports, viewing cube class definitions, editing cube class definitions, viewing pivot tables, editing pivot tables, viewing dashboards, and editing dashboards (The system sets permissions (i.e. indications as to the ability of the user) for users, for example limiting the user’s ability to view of edit data processed by the system, e.g. see col. 24, lines 21-45, wherein the data includes a source application (i.e. cube class definitions), e.g. see col. 24, lines 42-45, reports including a pivot table, e.g. see col. 13, lines 28-43, and dashboards, e.g. see col. 24, lines 21-25.).
Furthermore, before the effective filing date, it would have been obvious to one ordinarily skilled in the art of healthcare to modify the combination of Tribble, Miller, Imanaka, and Sathe to incorporate the user view/edit permissions as taught by Vivalda in order to facilitate the unification of various data sets in such a way that allows for the creation of new collaboration tools that permit greater collaboration between users, e.g. see Vivalda col. 6, lines 11-15.
Claims 17-19 are rejected under 35 U.S.C. 103 as being unpatentable over the combination of Tribble, Miller, and Imanaka in view of Shabot (US 2003/0182164).
Regarding Claim 17, the combination of Tribble, Miller, and Imanaka teaches the limitations of Claim 1, but does not teach and Shabot teaches the following:
The system of claim 1, further comprising a logging module operative to log user activity in relation to the use of the data analytics tool by the user (The system receives a user selection (i.e. activity) for various reporting tools (i.e. data analytics tools), wherein the system logs the user’s selection, e.g. see Shabot [0029], [0035], and [0043].).
Furthermore, before the effective filing date, it would have been obvious to one ordinarily skilled in the art of healthcare to the combination of Tribble, Miller, and Imanaka to incorporate logging the user activity as taught by Shabot for security purposes, e.g. see Shabot [0043].
Regarding Claim 18, the combination Tribble, Miller, Imanaka, and Shabot teaches the limitations of Claim 17, and Shabot further teaches the following:
The system of claim 17, wherein the logging comprises recording information regarding the user and the usage of the data analytics tool by the user (The system logs the user selection of a reporting tool (i.e. information regarding the user and the usage of the data analytics tool), e.g. see Shabot [0029], [0035], and [0043].).
Furthermore, before the effective filing date, it would have been obvious to one ordinarily skilled in the art of healthcare to the combination of Tribble, Miller, and Imanaka to incorporate logging the user activity as taught by Shabot for security purposes, e.g. see Shabot [0043].
Regarding Claim 19, the combination of Tribble, Miller, Imanaka, and Shabot teaches the limitations of Claim 18, and Shabot further teaches the following:
The system of claim 18, wherein the logging comprises recording the identity of the dynamically generated report presented to the user (The system logs the user selection of a reporting tool and report type (i.e. the identity of the dynamically generated report), e.g. see Shabot paragraphs [0029], [0035], and [0043].).
Furthermore, before the effective filing date, it would have been obvious to one ordinarily skilled in the art of healthcare to modify the combination of Tribble and Miller to incorporate logging data pertaining to the report as taught by Shabot for security purposes, e.g. see Shabot [0043].
Claim 20 is rejected under 35 U.S.C. 103 as being unpatentable over the combination of Tribble, Miller, Imanaka, and Shabot in view of Ramraj.
Regarding Claim 20, the combination of Tribble, Miller, Imanaka, and Shabot teaches the limitations of Claim 19, but does not teach and Ramraj teaches the following:
The system of claim 19, wherein the logging comprises recording whether the dynamically generated report presented to the user contained protected health information (“PHI”) (The system generates an answer (i.e. parameter) to the determination of whether or not data contains protected health information (PHI), e.g. see Ramraj [0032]-[0034], Fig. 3.).
Furthermore, before the effective filing date, it would have been obvious to one ordinarily skilled in the art of healthcare to modify the combination of Tribble, Miller, Imanaka, and Shabot to incorporate generating the “yes” or “no” parameter regarding the presence of PHI as taught by Ramraj in order to comply with the requirements of the Health Insurance Portability and Accountability Act (HIPAA), e.g. see Ramraj paragraphs [0002]-[0004].
Response to Arguments
Applicant’s arguments, see Remarks, filed February 20, 2026, with respect to the rejections of Claims 1-21 under 35 U.S.C. 101 have been fully considered but are not persuasive.
Applicants allege that the claimed invention is patent eligible because the claimed invention recites a technology-based solution that represents significantly more than the abstract idea, specifically because the claim limitations restrict user access to dose order record data based on a facility from which a user is requiring access and hence achieve improvements similar to those disclosed in Bascom and Desjardins, e.g. see pgs. 9-10 of Remarks – Examiner disagrees.
Regarding Bascom, the claimed invention is eminently distinguished from the invention of Bascom. The invention of Bascom was directed towards the installation of an Internet content filtering tool at a specific location remote from end-users, with customizable features to each end-user, which improved the system by making it less susceptible to hacking less dependent on local hardware and software, and by making it no longer confined to an inflexible one-size-fits-all scheme. In contrast, the present invention does not recite any limitations which operate any differently whether considered as an order combination or individually. That is, the additional elements (i.e. the central server, the local servers, the database, the server interface, the user workstation, the data analytics tool, and the user interface) are generic computer elements, wherein each of the additional elements merely perform well-understood, routine, and conventional functions expected of each of the elements (i.e. receiving data, storing data, processing data, and presenting the results of the processing). Additionally, even assuming, arguendo, that the claimed limitations achieve the improvement of increased patient privacy and/or an improvement of increased compliance with regulations such as HIPAA, these improvements represent improvements to the abstract idea of a certain method of organizing human activities, and an improvement in the abstract idea itself is not an improvement in technology, e.g. see MPEP 2106.05(a)(II). Furthermore, the problems of maintaining patient privacy and compliance with laws and/or regulations are problems that have existed since long before the advent of any type of computer technology, hence the claimed limitations do not address technological problems.
Regarding Desjardins, the invention of Desjardins recited a specific process for training a machine learning model to learn new tasks while protecting knowledge about previous tasks to overcome the problem of “catastrophic forgetting” encountered in continual learning systems, and hence provided improvements as to how the machine learning model itself operates. In contrast, as stated above, the claimed invention recites limitations that restrict the display of data based on a facility. That is, the claimed limitations address privacy and/or regulatory concerns which have existed since long before the advent of any type of computer technology, and hence are not technological problems. Additionally, even assuming, arguendo, that the claimed limitations achieve the improvement of increased patient privacy and/or an improvement of increased compliance with regulations such as HIPAA, these represent improvements to the abstract idea of a certain method of organizing human activities, and an improvement in the abstract idea itself is not an improvement in technology, e.g. see MPEP 2106.05(a)(II).
Hence, the claimed invention and its associated improvements and the problems it addresses are eminently distinguished from and not properly analogized to Bascom and/or Desjardins.
For the aforementioned reasons, Claims 1-21 are rejected under 35 U.S.C. 101.
Applicant’s arguments, see Remarks, filed February 20, 2026, regarding the rejections of Claims 1-21 under 35 U.S.C. 103 have been considered but are moot because the arguments do not apply to any of the references being used in the current rejection. As stated above, the newly amended claim limitations of Claim 1 have necessitated the new grounds of rejection, and Imanaka is now cited to address the newly amended claim limitations.
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure is as follows:
Mazar (US 2015/0302539) – teaches a user interface that restricts the data displayed to a user based on a user log-in, wherein the user may be a specific doctor in charge of hospital administrative duties, and/or other users may be doctors responsible for distinct sets of patients.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JOHN P GO whose telephone number is (703)756-1965. The examiner can normally be reached Monday-Friday 9am-6pm Pacific.
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, PETER H CHOI can be reached at (469)295-9171. 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.
/JOHN P GO/Primary Examiner, Art Unit 3681
Prosecution Insights