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 .
Status of Claims
This action is in reply to the restriction requirement filed on 08/08/25.
Claims 15-20 have been withdrawn by Applicant.
Claims 1-14 are currently pending and have been examined.
Election/Restrictions
Applicant’s election without traverse of Invention I, Claims 1-14 in the reply filed on 08/08/25 is acknowledged.
Examiner Request
The Applicant is requested to indicate where in the specification there is support for amendments to claims should Applicant amend. The purpose of this is to reduce potential 35 USC 112(a) issues that can arise when claims are amended without adequate support in the specification. The Examiner thanks the Applicant in advance.
Priority
This application claims Continuation-In-Part priority to U.S. Patent Application No.
16/953,800, filed 11/20/20.
Applicant’s claim for the benefit of a prior-filed application under 35 U.S.C. 119(e) or
under 35 U.S.C. 120, 121, 365(c), or 386(c) is acknowledged. Applicant has not complied with
one or more conditions for receiving the benefit of an earlier filing date under 35 U.S.C. 120 as
follows: the entirety of the as-claimed invention was not disclosed in 16/953,800, from which the
present application claims Continuation priority (see below for explanation). The later-filed
application must be an application for a patent for an invention which is also disclosed in the
prior application (the parent or original nonprovisional application or provisional application). The
disclosure of the invention in the parent application and the later-filed application must be
sufficient to comply with the requirements of 35 U.S.C. 112(a) or the first paragraph of pre-AIA
35 U.S.C. 112, except for the best mode requirement. See Transco Products, Inc. v.
Performance Contracting, Inc., 38F.3d 551, 32 USPQ2d 1077 (Fed. Cir. 1994).
The disclosure of the prior-filed application, Application No. 16/953,800, fails to provide
adequate support or enablement in the manner provided by 35 U.S.C. 112(a) or pre-AIA 35
U.S.C. 112, first paragraph for one or more claims of this application. Claims 1-20 are not fully
supported by the ‘800 application as follows:
In Claim 1 (and corresponding dependent claims), there does not appear to
be support for at least the following:
receiving, at a medical consent application of a client computing device, user credentials for providing a user with access to provider-specific functionality of the medical consent application, wherein the medical consent application provides functionality for multiple different medical providers; determining, based on the user credentials, a key value and a provider-specific identifier that are stored in association with the user credentials by the medical consent application or another device associated with the medical consent application; establishing, using the key value and the provider-specific identifier, a secure connection between the medical consent application and the separate computing device that provides access to a medical records database, wherein establishing the secure connection includes providing the key value and the provider-specific identifier to the separate computing device to cause the separate computing device to share a token value with the medical consent application; determining, by the medical consent application or another application, a format of a plurality of formats that the medical records database stores provider patient data for a patient of the user; generating, based on the format for the medical records database, patient resource schema data using the provider patient data, wherein the provider patient data is accessed during a token session between the medical consent application and the separate computing device, and wherein the patient resource schema data: is generated in a separate format from the format of the provider patient data, and includes a field with a value for an encrypted reference to the patient; determining, based on the provider patient data, that the patient is scheduled to undergo a medical procedure that can require consent from the patient, or an authorized representative of the patient, before the medical procedure is initiated by a provider or the user; accessing, by the medical consent application and based on the medical procedure, procedure schema data that is stored in the separate format, wherein various medical procedure schema data is accessible to the medical consent application to generate medical consent forms for multiple different medical procedures for the multiple different medical providers; generating, by the medical consent application and based on the procedure schema data, consent resource schema data to be generated in response to determining that the patient is scheduled to undergo the medical procedure that can require the consent, wherein the consent resource schema data: is generated in the separate format, identifies the medical procedure, and includes the encrypted reference to the patient or a different encrypted reference to the patient; causing, by the medical consent application, a patient consent form to be rendered at a display interface of the client computing device using the consent resource schema data, wherein the patient consent form includes natural language content embodied in fields of the procedure schema data and that describes the medical procedure; generating, by the medical consent application, updated consent resource schema data in response to determining that the patient consent form was signed, wherein the updated consent resource schema data includes another encrypted reference to the patient and indicates the patient consent form was signed; converting the updated consent resource schema data into formatted consent resource data, wherein converting the updated consent resource schema data includes changing the separate format of the updated consent resource data to the format of the medical records database; and providing, by the medical consent application, the formatted consent resource data to the separate computing device during the token session or a subsequent token session between the client computing device and the separate computing device.
In Claim 8 (and corresponding dependent claims), there does not appear to be support for at least the following: determining, by a medical consent application that is accessible via a client computing device, that a patient is to be presented with a consent form for consenting to a medical procedure, wherein the patient is identified in patient resource data that is stored in a medical provider computing device that is separate from the client computing device; causing, in response to determining that the patient is to be presented with the consent form, consent resource data to be generated, wherein the consent resource data identifies the medical procedure and includes an encrypted reference to the patient resource data that identifies the patient.
Therefore, an effective filing date of 08/29/23 has been given to Claims 1-14.
Claim Rejections - 35 USC § 112
The following is a quotation of the first paragraph of 35 U.S.C. 112(a):
The following is a quotation of 35 U.S.C. 112(b):
(b) CONCLUSION.—The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the inventor or a joint inventor regards as the invention.
The following is a quotation of 35 U.S.C. 112 (pre-AIA ), second paragraph:
The specification shall conclude with one or more claims particularly pointing out and distinctly claiming the subject matter which the applicant regards as his invention.
Claims 1-7 are rejected under 35 U.S.C. 112(b) or 35 U.S.C. 112 (pre-AIA ), second paragraph, as being indefinite for failing to particularly point out and distinctly claim the subject matter which the inventor or a joint inventor (or for applications subject to pre-AIA 35 U.S.C. 112, the applicant), regards as the invention.
Claim 1 recites the limitation "the separate computing device" in line 11. There is insufficient antecedent basis for this limitation in the claim. For purposes of examination, it is being interpreted as “a separate computing device”.
Claims 2-6 are subsequently rejected as they inherit the deficiencies of Claim 1.
Claim 9 recites the limitation "the medical records database" in line 3. There is insufficient antecedent basis for this limitation in the claim. For purposes of examination, it is being interpreted as “a medical records database”.
Claim 11 recites the limitation "the portion” (of the medical procedure) in line 4. There is insufficient antecedent basis for this limitation in the claim. For purposes of examination, it is being interpreted as “a portion”.
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-14 are rejected under 35 U.S.C.101 because the claimed invention is directed to a judicial exception (an abstract idea) without significantly more.
Step 1
Claims 1-14 are drawn to a method. Claims 1-14 are further directed to an abstract idea on the grounds set out in detail below.
Step 2A Prong 1
Claim 1 recites implementing the steps of:
receiving user credentials for providing a user to access provider-specific functions for generating medical consent forms, wherein functionality is provided for multiple different medical providers;
determining, based on the user credentials, a key value and a provider-specific identifier that are associated with the user credentials;
determining a format of a plurality of formats that the medical records maintain provider patient data for a patient of the user;
generating, based on the format for the medical records, patient resource data using the provider patient data, and wherein the patient resource data: is generated in a separate format from the format of the provider patient data, and includes a field with a value for an encrypted reference to the patient;
determining, based on the provider patient data, that the patient is scheduled to undergo a medical procedure that can require consent from the patient, or an authorized representative of the patient, before the medical procedure is initiated by a provider or the user;
accessing, based on the medical procedure, procedure data that is stored in the separate format, wherein various medical procedure data is accessible to generate medical consent forms for multiple different medical procedures for the multiple different medical providers;
generating, based on the procedure data, consent resource data to be generated in response to determining that the patient is scheduled to undergo the medical procedure that can require the consent, wherein the consent resource data: is generated in the separate format, identifies the medical procedure, and includes the encrypted reference to the patient or a different encrypted reference to the patient;
generating a patient consent form using the consent resource data, wherein the patient consent form includes natural language content embodied in fields of the procedure data and that describes the medical procedure;
determining that the patient, or the authorized representative of the patient, signed the patient consent form, wherein the patient consent form is signed via direct input and
generating updated consent resource data in response to determining that the patient consent form was signed, wherein the updated consent resource data includes another encrypted reference to the patient and indicates the patient consent form was signed;
converting the updated consent resource data into formatted consent resource data, wherein converting the updated consent resource data includes changing the separate format of the updated consent resource data to the format of the medical records.
These steps amount to managing personal behavior or relationships or interactions
between people and therefore recite certain methods of organizing human activity. Receiving user credentials to provider-specific functionalities for generating a medical consent form, determining a format of a patient’s medical record used by a provider, generating patient resource data in a separate format, determining a medical consent form should be given to a patient who will be undergoing a procedure, generating the medical consent form for the patient using procedure data, determining that consent from the patient/authorized representative has been provided via the form, generating updated consent data are personal behaviors that may be performed by a healthcare provider and converting the updated consent data to the format of the medical record are personal behaviors that may be performed by healthcare providers. Examiner prospectively submits that with regard to “format” and “converting”, the broadest reasonable interpretation is understood to include normalizing data or changing the way data fits into a field, and as such, is incorporated in the scope of the abstract idea.
Claim 8 recites implementing the steps of:
determining that a patient is to be presented with a consent form for consenting to a medical procedure, wherein the patient is identified in patient resource data
causing, in response to determining that the patient is to be presented with the consent form, consent resource data to be generated, wherein the consent resource data identifies the medical procedure and includes an encrypted reference to the patient resource data that identifies the patient;
determining that the patient, or an authorized representative of the patient, provided express consent for the medical procedure at the consent form, wherein the express consent is received from the patient, or the authorized representative of the patient, via direct user input to the consent form; and
causing updated consent resource data to be generated and stored at the medical provider computing device in response determining that the express consent for the medical procedure as received, wherein the updated consent resource data includes an indication that the patient, or the authorized representative of the patient, consented to receiving the medical procedure.
These steps amount to managing personal behavior or relationships or interactions
between people and therefore recite certain methods of organizing human activity. Determining a medical consent form should be given to a patient, generating the medical consent form for the patient, determining that consent from the patient/authorized representative has been provided via the form, and generating updated consent data are personal behaviors that may be performed by a healthcare provider.
The above claims are therefore directed to an abstract idea.
Step 2A Prong 2
This judicial exception is not integrated into a practical application because the additional
elements within the claims only amount to:
A. Instructions to Implement the Judicial Exception. MPEP 2106.05(f)
The independent claims additionally recite:
one or more processors as implementing the abstract idea (Claims 1 and 8)
a medical consent application / a medical consent application that is accessible via a client computing device as implementing steps of the abstract idea (Claims 1, 8)
establishing, using the key value and the provider-specific identifier, a secure connection between the medical consent application and the separate computing device that provides access to a medical records database, wherein establishing the secure connection includes providing the key value and the provider-specific identifier to the separate computing device to cause the separate computing device to share a token value with the medical consent application as a means of electronically sharing information (Claim 1)
display interface of a client computing device / client computing device as implementing the step of displaying/providing access to the consent form and obtaining patient consent input (Claims 1, 8)
(medical records) database as a means of storing medical records electronically (Claim 1)
various schema data (e.g., patient resource, medical procedure, consent resource) as a means of storing the various types of data (e.g., patient resource data) electronically (Claim 1)
wherein the provider patient data is accessed during a token session between the medical consent application and the separate computing device as a means of electronically accessing data (Claim 1)
The broad recitation of general purpose computing elements at a high level of generality only amounts to mere instructions to implement the abstract idea using computing components as tools. Regarding the one or more processors, per [0026], these are understood to be any general purpose processor functioning in its ordinary capacity to implement the steps of the abstract idea. Regarding the medical consent application accessible via a client computing device, this is understood to amount to an application on a general purpose computing device applying the abstract idea. No particulars of the application or computing device are provided. Per paras. [0065] and Fig. 2D, the client computing device is understood to be a general purpose computer, such as a tablet computer. Regarding database/schema, no particulars appear to be provided. Therefore, these elements are given their broadest reasonable interpretation as general purpose computing elements and subsequently amount to mere instructions to apply the abstract idea on a computer. Regarding the limitation establishing, using the key value and the provider-specific identifier, a secure connection between the medical consent application and the separate computing device that provides access to a medical records database…, this is understood to amount to sharing information electronically, e.g. using computers to communicate and access stored records, and therefore amounts to mere instructions to apply the abstract idea. Regarding the limitation wherein the provider patient data is accessed during a token session between the medical consent application and the separate computing device, no particulars of the token session are provided; therefore, this amounts to mere instructions to apply the abstract idea, e.g., accessing data electronically using a computing device.
B. Insignificant Extra-Solution Activity. MPEP 2106.05(g)
Claim 1 also recites:
providing the formatted consent resource data to the separate computing device during the token session or a subsequent token session between the client computing device and the separate computing device.
This element only amounts to insignificant application of the abstract idea, as it only amounts to outputting the results after performance of the abstract idea.
Claim 8 also recites:
storing data in a medical provider computing device that is separate from the client computing device;
storing updated consent resource data at the medical provider computing device
These elements amount to insignificant extra-solution activity. As explained above, Claim 8 is directed to an abstract idea in the form of determining a medical consent form should be given to a patient, generating the medical consent form for the patient, determining that consent from the patient/authorized representative has been provided via the form, and generating updated consent data. As stated in MPEP 2106.05(g), "[t]he term "extra-solution activity" can be understood as activities incidental to the primary process or product that are merely a nominal or tangential addition to the claim." In the present claim, the functions of storing data in a medical provider computing device that is separate from the client computing device and storing updated consent resource data at the medical provider computing device are only nominally or tangentially related to the process of determining a medical consent form should be given to a patient, generating the medical consent form for the patient, determining that consent from the patient/authorized representative has been provided via the form, and generating updated consent data, and accordingly constitutes insignificant extra-solution activity.
These elements are therefore not sufficient to integrate the abstract idea into a practical application. Looking at the limitations as an ordered combination adds nothing that is not already present when looking at the elements taken individually.
The above claims, as a whole, are therefore directed to an abstract idea.
Step 2B
The present claims do not include additional elements that are sufficient to amount to
more than the abstract idea because the additional elements or combination of elements amount to no more than a recitation of:
A. Instructions to Implement the Judicial Exception. MPEP 2106.05(f)
As explained above, claims 1 and 8 only recite the aforementioned computing elements as tools for performing the steps of the abstract idea, and mere instructions to perform the abstract idea using a computer is not sufficient to amount to significantly more than the abstract idea. MPEP 2106.05(f).
Thus, taken alone, the additional elements do not amount to significantly more than the
above-identified judicial exception. Looking at the limitations as an ordered combination adds
nothing that is not already present when looking at the elements taken individually. Their
collective functions merely provide conventional computer implementation.
B. Insignificant Extra-Solution Activity. MPEP 2106.05(g)
Likewise, as explained above, the step of providing the formatted consent resource data to the separate computing device during the token session or a subsequent token session between the client computing device and the separate computing device only amounts to insignificant application, e.g., outputting a result after performing the abstract idea.
Likewise, as explained above, the steps of storing data in a medical provider computing device that is separate from the client computing device and storing updated consent resource data at the medical provider computing device only amounts to insignificant extra-solution activity of the abstract idea.
C. Well-Understood, Routine and Conventional Activities. MPEP 2106.0S(d)
In addition to amounting to insignificant extra-solution activity the elements in Section B above constitute well-understood, routine and conventional activity.
The step of providing the formatted consent resource data to the separate computing device during the token session or a subsequent token session between the client computing device and the separate computing device only amounts to transmitting data over a network, which has been previously held to be well-understood, routine and conventional when claimed at a high level of generality or as insignificant extra-solution activity. See MPEP 2106.05(d)(II).
The steps of storing data in a medical provider computing device that is separate from the client computing device and storing updated consent resource data at the medical provider computing device only amounts to storing/retrieving information in memory, which has been previously held to be well-understood, routine and conventional when claimed at a high level of generality or as insignificant extra-solution activity. See MPEP 2106.05(d)(II).
Thus, taken alone, the additional elements do not amount to significantly more than the
above-identified judicial exception. Looking at the limitations as an ordered combination adds
nothing that is not already present when looking at the elements taken individually. Their
collective functions merely provide conventional computer implementation.
Depending Claims
Dependent claims recite additional subject matter which further narrows or defines the abstract idea embodied in the claims as discussed below:
Claim 2 recites limitations pertaining to further comprising: determining that the user or a medical services provider has caused a particular instance of procedure resource data to be generated, wherein determining that the patient is scheduled to undergo the medical procedure that can require consent from the patient, or the authorized representative of the patient, is performed in response to determining that the medical services provider has caused the particular instance of procedure resource data to be generated, which is also certain methods of organizing human activity as they are determination steps that may be performed by a healthcare provider.
These limitations are not sufficient to integrate the abstract idea into a practical application or amount to significantly more.
Claim 3 recites limitations pertaining to wherein the provider patient data is stored in the medical records database as one or more PDF, TIFF, JPEG, PNG, and/or BMP files, and the patient resource schema data is stored separately from the medical records database in a JSON, SQL, and/or XML format, which amount to insignificant extra-solution activity. As explained above, Claim 1 is directed to an abstract idea in the form of obtaining patient consent via a consent form. As stated in MPEP 2106.05(g), "[t]he term "extra-solution activity" can be understood as activities incidental to the primary process or product that are merely a nominal or tangential addition to the claim." The functions of Claim 3 are only nominally or tangentially related to the process of obtaining patient consent, and accordingly constitutes insignificant extra-solution activity. These steps only amounts to storing/retrieving information in memory, which has been previously held to be well-understood, routine and conventional when claimed at a high level of generality or as insignificant extra-solution activity. See MPEP 2106.05(d)(II).
These limitations are not sufficient to integrate the abstract idea into a practical application or amount to significantly more.
Claim 4 recites limitations pertaining to causing the consent resource data to include a consent field with a first consent value that indicates the patient has not consented to the medical procedure, wherein a second consent value is provided in another consent field in the updated consent resource data and the second consent value provides an indication that the patient, or the authorized representative of the patient, consented to the medical procedure, which are also certain methods of organizing human activity as a healthcare provider could format/record data in the way described by the claim (e.g., including a consent field with a first value with the consent resource data).
These limitations are not sufficient to integrate the abstract idea into a practical application or amount to significantly more.
Claim 5 recites limitations pertaining to wherein generating the consent resource data includes: causing the consent resource data to include a media field with a media value that provides a link to, and/or a description of, medical procedure information to be presented to the patient, or the authorized representative of the patient, which is also certain methods of organizing human activity including managing personal behaviors, as a healthcare provider generating consent resource data could include a procedure description to provide to the patient in a field of the consent form.
Claim 5 also recites the interface of the client computing device as providing the media field with a description of medical procedure information to be provided to the patient and “schema” data. As discussed above with respect to Claim 1, these is understood to be a general purpose computing element used in its ordinary capacity and/or amount to mere instructions to apply the abstract idea on a computer.
These limitations are not sufficient to integrate the abstract idea into a practical application or amount to significantly more.
Claim 6 recites limitations pertaining to wherein generating the consent resource data includes: causing the consent resource data to include a media acknowledgement field with a first acknowledgement value that indicates the medical procedure information has not been accessed, wherein a second acknowledgement value is provided in another media acknowledgement field in the updated consent resource data, and the second acknowledgement value indicates the medical procedure information was accessed, which is also certain methods of organizing human activity including managing personal behaviors, as a healthcare provider generating consent resource data could include a media acknowledgement field in consent resource data to indicate whether or not procedure information has been accessed.
Claim 6 also recites “schema” data. As discussed above with respect to Claim 1, this is understood to amount to mere instructions to apply the abstract idea on a general purpose computer.
These limitations are not sufficient to integrate the abstract idea into a practical application or amount to significantly more.
Claim 7 recites limitations pertaining to wherein the second acknowledgment value is embodied in the formatted consent resource data that is provided to the separate computing device, which only amounts to insignificant extra-solution activity in the form of insignificant application as it is only outputting the result after performance of the abstract idea. This only amounts to transmitting data over a network, which has been previously held to be well-understood, routine and conventional when claimed at a high level of generality or as insignificant extra-solution activity. See MPEP 2106.05(d)(II).
These limitations are not sufficient to integrate the abstract idea into a practical application or amount to significantly more.
Claim 9 recites limitations pertaining to wherein determining that the patient is to be presented with the consent form for consenting to the medical procedure includes: determining that the medical records includes medical procedure resource data, wherein the medical procedure resource data includes another encrypted reference to the patient resource data and identifies the medical procedure which is also certain methods of organizing human activity including managing personal behavior, as a healthcare provider could determine that medical records include medical procedure resource data includes an encrypted reference and identifies the medical procedure.
Claim 9 also recites “database”. This is understood to be a computer database functioning in its ordinary capacity to apply the abstract idea.
These limitations are not sufficient to integrate the abstract idea into a practical application or amount to significantly more.
Claim 10 recites limitations pertaining to wherein causing the consent resource data to be generated includes: determining a location of an image file and/or a video file that provides supplemental information describing the medical procedure, and causing the consent resource data to be generated with a link or an address for the image file and/or the video file, which amount to certain methods of organizing human activity as a healthcare provider could determine the location of a file and include the file address on a consent form. Claim 10 also recites wherein the image file and/or the video file are rendered at a graphical user interface (GUI) of the client computing device during or before the patient, or the authorized representative of the patient, providing the express consent at the consent form. This only amounts to mere instructions to apply the abstract idea, e.g., providing consent information electronically via image/video format using the GUI of a general purpose computing device. As discussed above with respect to the independent claims, the computing elements are understood to be general purpose computing components functioning in their ordinary capacities to implement the steps of the abstract idea.
These limitations are not sufficient to integrate the abstract idea into a practical application or amount to significantly more.
Claim 11 recites limitations pertaining to determining that the patient received the medical procedure subsequent to the express consent being provided at the consent form; and causing, based on determining that the user received the portion of the medical procedure, discharge consent resource data to be generated, wherein the discharge consent resource data identifies the medical procedure, and includes another encrypted reference to the patient resource data stored in the medical records, which is also certain methods of organizing human activity as a healthcare provider could determine a patient received the procedure after consent was provided via the form, generate discharge consent resource data which identifies the medical procedure and includes a reference to patient resource data stored in medical records.
Claim 11 also recites that the discharge consent resource data is accessible to the medical consent application. As discussed above with respect to Claim 8, recitation of the medical consent application only amounts to mere instructions to apply the abstract idea on a general purpose computer. Claim 11 also recites “database”. This is understood to be a computer database functioning in its ordinary capacity to apply the abstract idea.
These limitations are not sufficient to integrate the abstract idea into a practical application or amount to significantly more.
Claim 12 recites limitations pertaining to determining that the patient received the medical procedure subsequent to express consent being provided at the consent form; and causing, based on determining that the patient received the medical procedure, appointment resource data to be generated, wherein the appointment resource data: includes a reference to post-procedure information for the medical procedure, and specifies a time that a reminder will be communicated to a phone number and/or an email address of the patient or the authorized representative of the patient, which are also certain methods of organizing human activity as a healthcare provider could determine a patient received a procedure after consent was received, determine appointment data including a reference to post-procedure information and specify a time for a reminder to be sent to the patient.
Claim 12 also recites “a file embodying” the post procedure information. Using a file to provide or maintain post procedure information only amounts to applying the abstract idea on a computer, e.g., using an electronic file on a computer for providing the post procedure information.
These limitations are not sufficient to integrate the abstract idea into a practical application or amount to significantly more.
Claim 13 recites limitations pertaining to determining that the patient, or the authorized representative of the patient, provided an indication that a separate medical provider of the patient does not have an account stored at the medical provider computing device or is not associated with a network of the medical provider computing device; and causing, by the medical consent application, the updated consent resource data to be converted to a separate format and communicated to an electronic address of the separate medical provider.
Claim 13 also recites medical provider “computing device” which amounts to mere instructions to apply the abstract idea.
These limitations are not sufficient to integrate the abstract idea into a practical application or amount to significantly more.
Claim 14 recites limitations pertaining to wherein the separate format of the updated consent resource data includes a consolidated clinical document architecture (CCDA) format, which amounts to mere instructions to apply the abstract idea on a computer, e.g., using a known electronic format (CCDA) for maintaining data.
These limitations are not sufficient to integrate the abstract idea into a practical application or amount to significantly more.
The dependent claims have been given the full two-part analysis including analyzing the additional limitations both individually and in combination. The dependent claims, when analyzed individually, and in combination, are also held to be patent ineligible under 35 U.S.C. 101 as they include all of the limitations of claim 1 or claim 8 respectively. The additional recited limitations of the dependent claims fail to establish that the claims do not recite an abstract idea because the additional recited limitations of the dependent claims merely further narrow the abstract idea. Beyond the limitations which recite the abstract idea, the claims recite additional elements consistent with those identified above with respect to the independent claims which encompass adding the words “apply it” (or an equivalent) with the judicial exception, or mere instructions to implement an abstract idea on a computer, or merely uses a computer as a tool to perform an abstract idea - see MPEP 2106.05(f). Accordingly, these additional elements do not integrate the abstract idea into a practical application because it does not impose any meaningful limits on practicing the abstract idea.
Dependent claims 2-7, 9-14 recite additional subject matter which amounts to additional elements consistent with those identified in the analysis of Claim 1 and 8 above. As discussed above with respect to Claim 1 and 8 and integration of the abstract idea into a practical application, recitation of these additional elements only amounts to invoking computers as a tool to perform the abstract idea. 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.
Dependent claims 2-7, 9-14, when analyzed as a whole, are held to be patent ineligible under 35 U.S.C. 101 because the additional recited limitation(s) fail(s) to establish that the claim(s) is/are not directed to an abstract idea without significantly more. These claims fail to remedy the deficiencies of their parent claims above, and are therefore rejected for at least the same rationale as applied to their parent claims above, and incorporated herein.
For the reasons stated, Claims 1-14 fail the Subject Matter Eligibility Test and are consequently rejected under 35 U.S.C. 101.
Claim Rejections - 35 USC § 103
In the event the determination of the status of the application as subject to AIA 35 U.S.C. 102 and 103 (or as subject to pre-AIA 35 U.S.C. 102 and 103) is incorrect, any correction of the statutory basis (i.e., changing from AIA to pre-AIA ) for the rejection will not be considered a new ground of rejection if the prior art relied upon, and the rationale supporting the rejection, would be the same under either status.
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
The factual inquiries for establishing a background for determining obviousness under 35 U.S.C. 103 are summarized as follows:
1. Determining the scope and contents of the prior art.
2. Ascertaining the differences between the prior art and the claims at issue.
3. Resolving the level of ordinary skill in the pertinent art.
4. Considering objective evidence present in the application indicating obviousness or nonobviousness.
Claim(s) 8-10 is/are rejected under 35 U.S.C. 103 as being unpatentable over Wahl et. al. (US Publication 20150302536) in view of Zwinger et. al. (US Publication 20160283661A1).
Regarding Claim 8, Wahl discloses a method implemented by one or more processors, the method comprising ([0007], a virtual information presentation system may include a processor):
determining, by a medical consent application that is accessible via a client computing device, that a patient is to be presented with a consent form for consenting to a medical procedure ([0022], teaching on a virtual information presentation system which provides information to/receives information from a patient before undergoing a medical procedure to obtain patient consent to the procedure; per [0037] the client computing device may access the virtual information presentation application through the internet or web-based application or mobile app where client computing device is a laptop, tablet, smartphone, etc.; [0092] teaches on the user confirming the proposed medical procedure via the application, which is interpreted as determining that the patient should be presented with a consent form for consenting to the medical procedure, e.g., paras. [0093]-[0095], [0097], [0099] teach on generation of the consent presentation and information provided),
wherein the patient is identified in patient resource data that is stored in a medical provider computing device that is separate from the client computing device ([0036] teaches on the virtual information presentation application accessing files/information in databases and external servers; computing device 105 may be in communication with a health information system such as EMR, RIS< PACS, HIMS, etc. for storing information and records associated with the patient; [0037] teaches on a patient accessing the virtual information presentation system through a client computing device 125 configured to communicate with a computing device 105 through a network; per [0036]-[0037], the patient resource data is understood to be stored in a medical provider computing device that is separate from the client device (125); obtaining files, records, and information associated with the patient are interpreted as “patient resource data”; [0038], the patient may be provided access to the virtual information presentation system before undergoing a medical procedure)
causing, in response to determining that the patient is to be presented with the consent form, consent resource data to be generated, wherein the consent resource data identifies the medical procedure and includes patient resource data that identifies the patient ([0037] teaches on a patient accessing the virtual information presentation system through a client computing device configured to communicate with a computing device 105 through a network; [0038] teaches on providing the patient with access to the virtual information presentation system before undergoing a medical procedure; [0038] teaches on the system using information such as the patient’s name, age, gender, and medical information such as type of procedure to generate the information presentation process; [0061] teaches on generating a content-specific information presentation for a specific user; [0091]-[0095] teach on the process of providing the consent process to a user via the web-based application, e.g., [0092] the procedure is confirmed/determined the patient will undergo the medical procedure requiring consent, [0095] teaches on presenting risks, benefits, alternatives to the procedure, [0097] teaches on expectations such as scarring, pain, bleeding, etc.; [0099] teaches on providing expected results from the medical procedure, disclaimers, etc.);
determining that the patient, or an authorized representative of the patient, provided express consent for the medical procedure at the consent form ([0022] teaches on the system receiving a presentation response from a patient user which may include “an acknowledgement, indication of understanding, consent, user signature, permission, or other response from a user associated with the purpose of the information presentation process”; [0076] further teaches on the types of responses that constitute consent to the medical procedure; [0080] teaches on an information verification component which verifies that a patient user has provided an informed consent through the virtual information presentation system; [0082] teaches on patients signing/digitally signing the consent by speaking, signing with a stylus, making a selection with a mouse or touch screen gesture, or keyboard selection; patient may provide a verbal signature – all interpreted as “express consent”; [0083] teaches on consent including a valid signature by the patient or their guardian),
wherein the express consent is received from the patient, or the authorized representative of the patient, via direct user input to the client computing device that provides access to the consent form ([0076] teaches on the user input including a presentation response which may be “an acknowledgement, indication of understanding, consent, user signature, permission” which are all interpreted as “express consent”; [0080] teaches on an information verification component which verifies that a patient user has provided an informed consent through the virtual information presentation system, e.g., whether the user has adequately signed the consent; [0082] teaches on patients signing/digitally signing the consent by speaking, signing with a stylus, making a selection with a mouse or touch screen gesture, or keyboard selection; patient may provide a verbal signature – all interpreted as “express consent”); and
causing, by the medical consent application, updated consent resource data to be generated and stored at the medical provider computing device in response determining that the express consent for the medical procedure as received ([0080] teaches on the informed consent verification component determining that the user has adequately signed the consent; at the end of the information presentation process, the verification component may generate one or more reports which provide information about the patient’s information presentation process, such as whether the patient provided consent and a record of the actual consent; the report and information associated therewith, e.g., the record of actual consent, may be stored within the virtual information presentation system 100 or a data storage location accessible by it – the actual record of consent is interpreted as “updated consent resource data” which is generated; storing it at virtual information presentation system 100 or data storage location are interpreted as provider computing device as it is accessible through a doctor’s office computing device 105 per [0037]), wherein the updated consent resource data includes an indication that the patient, or the authorized representative of the patient, consented to receiving the medical procedure ([0080] teaches on storing the “actual record of consent” as “updated consent resource data” after the patient has given consent).
Wahl does not explicitly teach on an encrypted reference to the patient resource data that identifies the patient, however, Zwinger, which is directed to a method of truncating and encrypting patient data, teaches:
an encrypted reference to the patient resource data that identifies the patient ([0036] teaching on encrypting each EHR and patient identifier).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention, to modify Wahl with these teachings of Zwinger, to encrypt the reference to patient resource data identifying the patient with the motivation of protecting the identify and privacy of the patient, as encrypting data is a preferred way of maintaining data security (Zwinger [0002], [0036]).
Regarding Claim 9, Wahl/Zwinger teach the limitations of Claim 8. Wahl further discloses wherein determining that the patient is to be presented with the consent form for consenting to the medical procedure includes: determining that the medical records database includes medical procedure resource data ([0038] teaches on providing access to the virtual information presentation system before a patient undergoes a medical procedure; the application may initiation the information presentation process by generating appropriate background for the encounter, including objective and/or subject of the information process; system user information may include demographic information of the patient and medical information such as “type of procedure” – interpreted as medical procedure resource data; informed consent forms, documents, questionnaires, scripts, etc. may be stored in computing devices 105, 130, and/or databases 135); wherein the medical procedure resource data includes another reference to the patient resource data and identifies the medical procedure ([0038] as cited in preceding limitation teaches on using patient information such as name and medical information including type of procedure for generating an appropriate information presentation for a patient).
Wahl does not teach the following, but Zwinger further teaches an encrypted reference to the patient resource data ([0036] teaching on encrypting each EHR and patient identifier).
Therefore, it would have been obvious to one of ordinary skill in the art before the effective filing date of the